We can clear this via drm_plane_state_put_back() at the end of
drm_output_propose_state(). We need to set it back to the minimum zpos
when rendering.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Update users of the old coordinate space conversion functions that take
x, y pairs to the new weston_coord versions.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Clean up the code a little by dropping the now unnecessary switch case
in drm_output_init_pixman(). As a side effect, this enables all formats
that have a pixman_format entry in the pixel format table:
- rgb565
- xrgb8888
- argb8888
- xbgr8888
- abgr8888
- rgbx8888
- rgba8888
- bgrx8888
- bgra8888
- xrgb2101010
- argb2101010
- xbgr2101010
- abgr2101010
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Use const struct pixel_format_info *format instead of uint32_t
gbm_format for backend and output pixel format.
Since create_gbm_surface() is never called without output->format being
set, drop the unnecessary error message.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Use struct pixel_format_info pointers instead of uint32_t drm fourcc
values at the API surface for output and image creation.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Use struct pixel_format_info pointers instead of pixman_format_code_t
values at the API surface for output and image creation.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add weston_renderbuffer_ref/unref() functions and use them to
eventually destroy the weston_renderbuffer. Drop the explicit
renderbuffer_destroy vfunc from the pixman renderer interface.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Stop calling pixman_renderer_init() from backends directly.
Call it via weston_compositor_init_renderer() instead.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a damage region to struct weston_renderbuffer and use it to replace
the previous_damage tracking in the drm backend.
Keep renderbuffers on a list in struct pixman_output_state and use it
to accumulate damage on all renderbuffers during repaint_output.
Now renderbuffers have to be created when pixman output state already
exists.
Reorder renderer output state and renderbuffer creation accordingly.
With this, pixman_renderer_output_set_hw_extra_damage() can be removed.
This can not yet replace the external damage tracking in the VNC
backend, which needsto know the accumulated damage that is not returned
from repaint_output.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a struct weston_renderbuffer parameter to repaint_output and make
backends set the pixman image renderbuffer through this parameter
instead of using pixman_renderer_output_set_buffer()
Turn pixman_renderer_output_set_buffer() static.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a create_image_from_ptr vfunc to struct pixman_renderer_interface,
which wraps weston_renderbuffer creation for the pixman renderer via
pixman_image_create_bits(), as well as a renderbuffer_destroy vfunc
to dispose of the pixman image renderbuffer.
Also add create_image_no_clear using pixman_image_create_bits_no_clear()
instead.
Make the backends create and destroy their pixman image renderbuffers
through this interface.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a struct pixman_renderer_interface with output_create and
output_destroy vfuncs and store a pointer to it in struct
weston_renderer.
Make all backends access the pixman_renderer_output_create/destroy
functions through this interface and turn them static.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Move the struct gl_renderer_interface pointer from the backends into
the weston_renderer structure. The interface struct only contains
function pointers that never change, so make it const.
Load and initialize the GL renderer in libweston instead of in the
backends, using the new weston_compositor_init_renderer() function.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
We can save a bit of work by using the output_to_buffer_matrix we've
already calculated for the paint node to transform the destination
rectangle, instead of starting over from global regions and doing
individual steps.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We should never hit this because drm_view_transform_supported() filters
out any transforms where it would occur.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
To avoid retrieving the backend from the compositor all the time, store
a pointer to the drm backend on its drm_output structures.
This will be useful once the compositor contains more than one backend.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Passing the backend as a parameter to the weston_backend function
pointers seems more natural and will be very useful once there can be
more than one backend.
Since all backends already store a pointer to the compositor instance,
replace the compositor parameter with the backend in all functions.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
We are assuming that CRTC_CTM is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that CRTC_DEGAMMA_LUT is pass-through, so better ensure
it really is pass-through rather than whatever the previous KMS client
left there.
This too falls under deprecated_gamma_is_set check, because the legacy
gamma could use either GAMMA or DEGAMMA.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that gamma LUT is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Unfortunately the legacy ioctl does not offer any way to reset the LUT
without actually crafting an identity LUT.
If the legacy gamma libdrm function indicates the feature is not
supported, do not try to use it again. This avoids hammering the legacy
gamma every frame when deprecated drm_output_set_gamma() is not used.
drm_output_set_gamma() is not updated to check/set this flag in order to
maintain its old behavior.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are assuming that CRTC_GAMMA_LUT is pass-through, so better ensure it
really is pass-through rather than whatever the previous KMS client left
there.
Unfortunately, we have old drm_output_set_gamma() API that cms-static
and cms-colord plugins are using. To avoid trampling over them, do not
touch gamma after they did. Those plugins are deprecated, so there is no
reason to make set_gamma work through atomic.
drm_output_set_gamma() is called from weston_compositor_add_output()
through the output_created_signal. This is after drm_output_enable() and
before any KMS modeset or atomic commit on the CRTC. Therefore it is not
possible that there would be any KMS action in flight when
drm_output_set_gamma() is called, and so setting deprecated_gamma_is_set
should be non-racy - like setting CRTC_GAMMA_LUT itself.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move the debug printing before the bail-out if the property does not
exist. This means that trying to set a missing property will be logged,
and it can be identified by the property id being 0.
We are starting to program more KMS properties, and if KMS state
building fails, this gives better chances to figure out what happened.
For example, if we accidentally assume that some property always exists
when it doesn't.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We've passed the paint node deeply enough that we can now use the cached
matrix in it to save some calculations.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Rename it as well.
By passing the paint node we'll have access to the cached buffer to output
matrix later.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Make sure dep_egl is always a valid dependency object, even if not
found. Ensure it is not found when not wanted, to avoid linking when
found but not wanted.
Using a not-found dependency in Meson is defined to be a safe no-op, so
use that to simplify the backend dependencies.
libweston/meson.build already errors out if renderer-gl is enabled and
EGL is not found, so the same checks can be removed from the backends.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Compositor code can use opaque pointer comparison to determine whether
a head belongs to a given backend. Store a backend pointer in struct
weston_head to enable the compositor to select the correct backend
specific output configuration code.
This also allows to use the backend pointer instead of the opaque
backend_id pointer to check whether a head belongs to a backend, so
replace the checks in all to_xyz_head() functions and drop backend_id.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Now that the renderer type is stored in struct weston_renderer,
use that instead of use_pixman to determine the renderer type.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This implements the basics of the new screenshooting protocol. The
actual pixel operations will be implemented separately in the renderers
and DRM-backend.
See the previous commit "protocol: new screenshooter protocol" for why.
If DRM-backend needs more from weston_capture_task when it implements
writeback screenshooting, it will be easy to add user_data or expose
weston_capture_task::link for the backend to use. Those were not added
yet because it is uncertain what is actually needed.
The DRM-backend no-damage optimization requires special handling here as
well. See also 7f1a113c89 .
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Instead of bailing based on our loosely tracked matrix "type" (that won't
recognize when an operation is reversed by its inverse) use the new
weston_matrix_to_transform to determine if the matrix reasonably matches.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Before this patch, when a new head is found its information is printed
first as "updated" and then as "found" in the log.
The reason is that drm_head_create() calls drm_head_update_info() which
printed the head as "changed". Then drm_head_create() itself prints it
as "found".
This fixes it to print only once as "found".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Some monitors expose a selector for the kind of content that will get
displayed, allowing them to optimise their settings for this particular
content type.
I got access to such a monitor, sadly even setting it to game mode
didn’t lower its atrocious latency, but drm_info[1] reports it to be set
correctly so hopefully it’ll work better with other monitors.
[1] https://github.com/ascent12/drm_info
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
This changes the GL-renderer interface to pass the initial framebuffer
size and compositing area explicitly. All backends are changed to
provide the correct parameters.
GL-renderer mostly does not yet use these values, but later patches
will. The pbuffer path uses it already, because they replaced the
existing fields.
All this is to make GL-renderer aware of the different sizes, so it can
implement the future revision of the screenshooting API.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
In a journey to decouple renderer from weston_output, pass the initial
framebuffer size to Pixman-renderer explicitly.
Now Pixman-renderer will never look into weston_output::current_mode.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Except the module dir path, they're one and the same. This change
warrants a libweston version bump, if it hasn't been done already.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Replace all uses of weston_transform_region with
weston_matrix_transform_region, then remove the function completely.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
As things are, even when mode=current is specified on the .ini file,
a full modeset is needed (and done), which causes a very noticeable
screen blinking. That is because setting the max_bpc on a connector
needs full modesetting.
The idea here is that if mode=current on the .ini, no modesetting
should be done, so the current max_bpc is programmed into the
connector.
But if a custom max-bpc=... is specified, that will be used instead,
even if mode=current on the .ini
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/660
Signed-off-by: vanfanel <redwindwanderer@gmail.com>
The planes in the plane_list must be sorted from largest zpos_max to smallest.
Currently the plane order is only correct when the planes are already ordered
and added starting with the smallest zpos_max. This works accidentally in most
cases because the primary plane is usually first and there is often only one
overlay plane or the zpos is sufficiantly configurable.
To fix this, insert a new plane before the first plane with a smaller zpos_max.
And if none is found, insert it at the end of the list.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Changing the mode will destoy the GBM surface for the output. As a result all
corresponding BOs are deleted regardless of the drm_fb refcount.
While a commit is pending, the last_state may contain a reference to such a BO.
So delay the mode switch until the commit is finished and the reference is
release.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
When an atomic commit fails then the output will be stuck in
REPAINT_AWAITING_COMPLETION state. It is waiting for a vblank event that was
never scheduled.
If the error is EBUSY then it can be expected to be a transient error. So
propagate the error and schedule a new repaint in the core compositor.
This is necessary because there are some circumstances when the commit can fail
unexpectedly:
- With 'state_invalid == true' one commit will disable all planes. If another
commit for a different output is triggered immediately afterwards, then this
commit can temporarily fail with EBUSY because it tries to use the same
planes.
- At least with i915, if one commit enables an output then a second commit for a
different output immediately afterwards can temporarily fail with EBUSY. This
is probably caused by some hardware interdependency.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
It is only enabled by a debug key binding, currently not tested at all,
and is seems it doesn't really work, so let's remove it. This also
removes it from the man page.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since b38b735e20, 'backend-drm: Remove Pixman conditional
for keep_buffer' the Pixman renderer keeps its own reference to buffers
when attached to surfaces, rather than flipping keep_buffer variable for
the surface. Problem is that when switching from the Pixman render to
the GL would not work and could result in a crash upon first repaint.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When an output is destroyed then the output state is freed immediately. In this
case, the plane state is only partially destroyed because it is the currently
active state. This includes the buffer reference.
Without the output, the plane will not be updated any more until it is used by a
different output (if possible) or the output returns and the plane is used
again.
As a result, the buffer reference is kept for a long time. This will cause some
applications to stall because weston now keeps two buffers (the one here and
another one for a different output where the application is now displayed).
To avoid this, do a synchronous commit that disables the output. The output
needs to be disabled anyways and this way the current state contains no
buffers that would remain.
`device->state_invalid = true` in drm_output_detach_crtc() is no longer
needed, because drm_output_detach_crtc() is called only when initialization
failed and the crtc was not yet used or in drm_output_deinit() when the
crtc was already disabled with the new synchronous commit.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This was introduced in a partial MR, where the later commits in the new
multi-GPU MR fully fix it, but the initially cherry-picked ones don't.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This is another followup to ffc011d6a3
("backend-drm: check that outputs and heads are in fact ours") which missed
some places.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
There is missing dependency on linux-dmabuf-unstable-v1-server-protocol.h
header file in backend-headless, backend-drm and backend-x11. That files
do not depend on that header, in fact. But by this moment they've had
that implicit dependency due to linux-dmabuf.h header.
With specific set of meson configure options the protocol header is not
generated at the right time, what causes build error in 100% cases using
small amount of building threads (from -j1 to -j8).
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
This is a followup to ffc011d6a3
("backend-drm: check that outputs and heads are in fact ours") which missed
some places.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This uses the legacy DRM API it incomplete and no longer works anyways.
At this point, weston is no longer DRM master, so these calls fail with
"Permission denied".
So just remove the corresponding code.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
"max bpc" property is meant for working around faulty sink hardware.
Normally it should be set to the maximum possible value so that the
kernel driver has full freedom to choose the link bpc without being
artificially forced to lower color precision.
The default value is 16 because that is a nice round number and more
than any link technology I've heard is using today which would be 12.
Also offer an API set the value, so that weston.ini could be used in the
next patch for sink workaround purposes.
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/612
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As a first step towards heterogeneous outputs, ignore other backends'
heads and outputs. This is done by checking the destroy callbacks for
heads and outputs.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Stop plugins from overwriting the struct weston_output::destroy vfunc,
as that will be used by backends to recognize their outputs.
Instead, pass a plugin-specific destroy callback when creating the
virtual output.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This reverts commit 6914064066.
This is a follow-up change of b623fd2a ("drm-backend: stop parsing IN_FORMATS
blobs, use libdrm instead"). Weston now has a hard-requirement on libdrm
2.4.108, clean up remaining and unnecessary conditional code. Change 69140640
("backend-drm: add HDR_OUTPUT_METADATA definitions") is no longer needed
and stop including libdrm-updates.h from kms-color.c.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Before this change the drm-backend in Weston did the work of parsing DRM
blobs in order to query IN_FORMATS data, if available. This is also the
case for other DRM/KMS clients that use IN_FORMATS (i.e. X).
libdrm 2.4.108 with e641e2a6 ("xf86drm: add iterator API for DRM/KMS
IN_FORMATS blobs") introduced a dedicated API for querying IN_FORMATS data.
Bump the minimum required version to 2.4.108, stop parsing IN_FORMATS in
Weston and start using DRM iterators. In addition, remove fallback code for
libdrm <2.4.107.
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
The drm_device is initialized as a side effect of the (badly named)
drm_device_is_kms function. Explicitly pass the drm_device to be able to
initialize kms devices that are not the main drm device of the drm backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
If we have multiple drm devices, we cannot use the drm device from the backend,
because we would only get the primary device and not the device of the output.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
If Weston receives a hotplug event, it has to check if the hotplug device
actually belongs to the drm device before updating the heads of the device. The
hotplug event should only remove heads that belong to the device and must not
change heads of other devices.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The compositor lists the heads from all devices, but we must only disable the
connectors that belong to the current device. Therefore, other heads must be
ignored.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The outputs, heads, crtcs, and connectors are specific to a drm device and not
the backend in general.
Link them to the device that they belong to to be able to retrieve the
respective device.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The commits happen per device instead of per backend. The pending state is
therefore per device as well. Allow to retrieve the device from the pending
state.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The scanout format for the dma-buf feedback are specific to the kms device that
is used for scanout. Therefore, we have to pass the device of the output when
retrieving the scanout formats.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The fbs are specific to the device on which they will be displayed. Therefore,
we have to tell which device shall be used when we are creating the fb.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The atomic commit is device specific. If we have multiple kms devices, we need
to know which device was used for the atomic commit.
Pass the device instead of the backend through the atomic commit.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Extract the kms device from the backend to allow a better separation of the
backend and the kms device. This will allow to handle multiple kms devices with
a single drm backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Get the backend at the beginning of the function instead of retrieving it from
another object in the debug statement. This simplifies refactoring, as the debug
statement is not affected by changes how the backend is retrieved.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The gbm_format is the same as the drm format used by the pixel format.
Print the format name using the pixel format in the error message to make the
error message easier to understand for humans.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The fb already contains a DRM fd for later use. So just use that one instead of
fetching it from the backend.
This is necessary if the fbs are allocated on different devices, since otherwise
the wrong device might be used to get the fd of the passed fb.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Looks like we missed this one during the conversion to
weston_signal_emit_mutable.
Found by running weston under valgrind and running/killing
weston-simple-dmabuf-egl
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
And use it to get a feedback event for when adding scanout tranche.
With this change, I get back a feedback event for dmabuf-feedback
on VC4:
���� tranche: target device /dev/dri/card0, scanout
� ���� format ABGR2101010, modifier LINEAR (0x0)
� ���� format XBGR2101010, modifier LINEAR (0x0)
� ���� format ARGB8888, modifier LINEAR (0x0)
� ���� format ABGR8888, modifier LINEAR (0x0)
� ���� format XRGB8888, modifier LINEAR (0x0)
� ���� format XBGR8888, modifier LINEAR (0x0)
� ���� format RGB565, modifier LINEAR (0x0)
� ���� format YUV420, modifier LINEAR (0x0)
� ���� format YUV422, modifier LINEAR (0x0)
� ���� format YVU420, modifier LINEAR (0x0)
� ���� format YVU422, modifier LINEAR (0x0)
� ���� format NV12, modifier LINEAR (0x0)
� ���� format NV12, modifier BROADCOM_SAND128 (0x700000000000004)
� ���� format NV16, modifier LINEAR (0x0)
� ���� end of tranche
Besides that, it can place a fullscreen state of simple-egl on the
primary plane, which without this change wasn't possible.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As we could have situations where dmabuf import failed when attempting
to figure it the framebuffer is scanout-capable, make sure we also have
a way to store that information. Otherwise, we could end up
NULL-dereferencing, as we don't provide a valid storage for it.
Further more, with this, we also print out the reason why it failed, to
aid in further debugging.
Observed on platforms where GBM_BO_HANDLE failed + in combination w/
direct-display proto extension.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Output color profile may be changed in flight. Output basic color
characteristics and EOTF mode cannot yet be changed in flight, but it is
reasonable to assume they could in the future. Therefore the color
outcome data may change in flight as well, which is the basis for HDR
metadata, which needs to be updated as well.
Track the changes to color outcome data with a serial number.
DRM-backend checks the serial number to see if it needs to re-create the
HDR metadata blob. This allows the changes to propagate all the way to
KMS.
The code added here is more of a reminder of what should happen than a
tested path.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Forward the HDR Static Metadata Type 1 to the video sink. This makes the
sink aware of our video content parameters and may be able to produce a
better picture. This type of metadata is used only with the ST 2084 HDR
mode a.k.a PQ.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates a new file for KMS related color code, to avoid making
drm.c even longer.
The moved code was just added in 5151f9fe9e
so the new file copyrights are written based on that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
'depth' isn't actually used to determine the bit depth of meaningful
components generally, but specifically to determine whether we can use
the legacy drmModeAddFB (pre-AddFB2) with those formats.
Rename the member to make it more clear what it's used for.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Trying to do HDR with XRGB8888 is a bit like using RGB565 on SDR: you
get visible color quantization and banding in gradients (without dithering
which Weston does not implement yet, and might not work too well for HDR
anyway).
Therefore, on any HDR mode, default output framebuffer format to 10 bpc
instead of 8 bpc.
Ideally we'd also optionally try 16F or 16 bpc formats, but automatic
fallbacks for those are more complicated to arrange. You can still
configure 16F or 16 bpc manually.
This patch also moves the default format setting from
drm_output_set_gbm_format() to drm_output_enable(), because setting the
default now requires eotf_mode. Frontends may call set_gbm_format()
first and set eotf_mode next. This does create an awkward situation for
outputs that a frontend disables and re-enables. This patch here makes
sure that the old output configuration remains, but changing eotf_mode
may not change the default format. One needs to call
set_gbm_format(NULL) to re-evaluate the default format. Resetting the
format on drm_output_deinit() would lose the current setting.
DRM_FORMAT_INVALID was introduced in libdrm 2.4.95 which we already
hard-depend on.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Program the connector property HDR_OUTPUT_METADATA based on the EOTF
mode of the output.
For now, this changes only the EOTF. The colorimetry and luminance are
left undefined, to be filled in by later patches. This should still be
enough to put a video sink into HDR mode, albeit the response is
probably unknown.
drm_output keeps track of the currently existing blob id. If the blob
contents need to be re-created, this blob would be destroyed and the
field set to zero. In this patch, there is no provision for runtime
changing of HDR metadata, so there is no code doing that.
Destroying the blob at arbitrary times is not a problem, because the
kernel keeps a reference to the data as long as the blob id remains with
KMS.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Check whether HDR_OUTPUT_METADATA property exists on a KMS connector. If
yes, pretend that EDID claims support for all EOTF modes and update the
head supported EOTFs mask accordingly. If not, then only SDR is
possible.
Parsing EDID to take monitor capabilities into account is left for
later.
HDR mode cannot be set without HDR_OUTPUT_METADATA.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These are fallback definitions in case libdrm is not new enough.
They are copied from libdrm 2.4.107.
struct hdr_output_metadata defines the contents of the blob to be used
with the connector property "HDR_OUTPUT_METADATA".
This is needed for programming a HDR mode in KMS.
This headers need to be excluded from Doxygen, because Doxygen chokes on
the kerneldoc markup.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When we're checking to see if a view is suitable to go on a plane, check
for (and reject) solid-colour buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The Pixman renderer keeps its own reference to buffers when attached to
surfaces, through its surface state: just use that instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a mode argument to weston_buffer_reference which indicates whether a
buffer's storage may/will be accessed, or whether the underlying storage
will no longer be accessed, e.g. because it has been copied. This will
be used to retain a pointer to the weston_buffer whilst being able to
send a release event to the client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than calling accessors (wl_shm_buffer_get etc) to figure out
which type our buffer is, just look in the structure.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In 913d7c15f7 stricter error checking was
introduced to the strtol call, which broke reading backlight values.
Since every sysfs backlight file ends with a newline.
As noted in a comment in the previous MR to prevent damaged pointers
after calling asprintf, replace every asprintf call with str_printf.
Previous-MR: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/543
Signed-off-by: Sören Meier <soerenmeier@livgood.ch>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The pending_state is already stored in the backend and can be directly retrieved
from there.
This avoids involving the compositor in passing state between the repaint
phases for a single backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
This doesn't work with any of the launchers we've kept. Remove the option
and all the bits that handle it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Moving forward we're going to be supporting libseat and logind as our
only launchers. We're doing this to reduce our maintenance burden,
and security impact.
Libseat supports all our existing use cases, and seatd can replace
weston-launch so we no longer have to carry a setuid-root program.
This patch removes weston-launch, and launcher-direct, leaving only
libseat and logind.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
