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 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>
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>
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>
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>
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>
Zoom is a neat trick, but in its current form it's very hard to test
and maintain.
It also causes output damage to scale outside of the output's boundaries,
which leads to an extra clipping step that's only necessary when zoom
is enabled.
Remove it to simplify desktop-shell and compositor.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Transforming the scanout damage by the zoom will result in rectangles
outside of the display, and some with negative co-ordinates. This makes
at least some drivers unhappy (tested on vmware), and the page flip fails,
and weston hangs indefinitely.
Clip the damage to the output so we don't fall down.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Walking the format/modifier list to try to find out if our FB is
compatible with the plane is surprisingly expensive. Since the plane's
capabilities are static over the lifetime of the KMS device, cache the
set of planes for which the FB is theoretically
format/modifier-compatible when it's created, and use that to do an
early cull of the set of acceptable planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In commit "libweston: add initial dma-buf feedback implementation" we've
added initial support to dma-buf feedback, but it was not using the
feedback from DRM-backend to add useful per-surface feedback.
In this patch we add this. The scanout tranche of the per-surface
feedback is based on the union of formats/modifiers of the primary and
overlay planes available. These are intersected with the
formats/modifiers supported by the renderer device.
Also, it's important to mention that the scene can change a lot and we
can't predict much. So this patch also adds hysteresis to the dma-buf
feedback. We wait a few seconds to be sure that we reached stability
before adding or removing the scanout tranche from dma-buf feedback and
resending them. This help us to avoid spamming clients and leading to
unnecessary buffer reallocations on their end.
Here's an example of what we want to avoid:
1. We detect that a view was not placed in a plane only because its
format is not supported by the plane, so we add the scanout tranche
to the feedback and send the events.
2. A few milliseconds after, the view gets occluded. So now the view
can't be placed in a plane anymore. We need to remove the scanout
tranche and resend the feedback with formats/modifiers optimal for
the renderer device. The client will then reallocate its buffers.
3. A few milliseconds after, the view that was causing the occlusion
gets minimized. So we got back to the first situation, in which the
format of the view is not compatible with the plane. Then we need to
add a scanout tranche and resend the feedback...
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Some graphics drivers (currently at least VMware and AMD) will give a 0
timestamp for the atomic mode flip completion event when turning off
the display. This causes us to trip an assertion in
weston_output_frame_finish() because the clock jumps backwards, which
isn't a condition the presentation feedback code should be dealing with.
This is a good assertion and we'd like to keep it. And there's some
expectation that this is buggy behaviour in the graphics drivers that will
be fixed at some point.
Pragmatically speaking though, there's nothing productive we can do with a
correct timestamp for the display shutdown. So let's just flag the
event sent for DPMS off as invalid so presentation feedback doesn't have
to worry about it, and the assert doesn't fire.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes a minor leak due to launcher-libseatd:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f15664e5037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7f156305c59f in zalloc ../include/libweston/zalloc.h:38
#2 0x7f156305c99b in seat_open_device ../libweston/launcher-libseat.c:114
#3 0x7f1563056341 in weston_launcher_open ../libweston/launcher-util.c:79
#4 0x7f156302f1e2 in drm_device_is_kms ../libweston/backend-drm/drm.c:2616
#5 0x7f156302f751 in find_primary_gpu ../libweston/backend-drm/drm.c:2715
#6 0x7f15630309a5 in drm_backend_create ../libweston/backend-drm/drm.c:2970
#7 0x7f15630317ab in weston_backend_init ../libweston/backend-drm/drm.c:3162
#8 0x7f1566025b61 in weston_compositor_load_backend ../libweston/compositor.c:8201
#9 0x7f156640cb9e in load_drm_backend ../compositor/main.c:2596
#10 0x7f156641193c in load_backend ../compositor/main.c:3079
#11 0x7f1566413cc3 in wet_main ../compositor/main.c:3356
#12 0x562ba484b179 in main ../compositor/executable.c:33
#13 0x7f156624fcc9 in __libc_start_main ../csu/libc-start.c:308
But also use the launcher interface to actually close the DRM fd, in
mirror to what weston_launcher_open() does.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.
However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.
To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Remove all the backend code to support drivers without universal planes.
From[1]:
"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."
And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.
[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
From now on, when we can't know the modifiers supported for a certain
format, we add DRM_FORMAT_MOD_INVALID to its modifier set.
There is some parts where nothing is being added an others where
DRM_FORMAT_MOD_LINEAR is being added, so fix them.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
Also, unit tests for this API have been added in commit "tests: add unit
tests for struct weston_drm_format".
Start to use this API in the DRM-backend, as it enhances the code by
avoiding repetition and ensuring correctness.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the absence of universal planes support,
drm_output_find_special_plane() sets the plane format to zero as a
placeholder. Then in drm_output_init_planes() it sets the format to
output->gbm_format.
As output->gbm_format is already set by the time we call
drm_output_find_special_plane(), simply set the plane format to it
directly in this function. This makes the code clearer, as there is no
reason to use the placeholder.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Tearing down the drm-backend when there are no input devices, would call
for the gbm device destruction before compositor shutdown. The latter
would call into the renderer detroy function and assume that the
EGLDisplay, which was created using the before-mentioned gbm device, is
still available. This patch re-orders the gbm destruction after the
compositor shutdown when no one would make use of it.
Fixes: #314
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
This header is for sharing fallback definitions for drm_fourcc.h. A new
test in tests/yuv-buffer-test.c is going to be needing XYUV8888 format,
and more new formats will be expected with HDR supports.
Share these fallback definitions in one place instead of copying them
all over.
All users of drm_fourcc.h are converted to include weston-drm-fourcc.h
instead for consistency: have the same definitions available everywhere.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The renderer must be called for any pending screen capture to complete.
Previously this was guaranteed by weston_screenshooter_shoot() forcing
full output damage, so damage was never empty. If the future,
screenshooting stops inflicting damage, and the damage on the primary
plane even after disabling hardware planes may be empty.
This patch ensures that screenshots do not get stuck until damage
occurs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Without this patch, the DRM-backend would rewrite the 'require-input',
core section option given by the user.
This removes 'continue_without_input' DRM-backend option and takes into
consideration the cmd line option only if that was passed (Pekka Paalanen).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Rework some functions in `drm.c` to reuse the `drmModeRes` and
reduce the usage of `drmModeGetResources` and `drmModeGetResources`.
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Recognize writeback connectors and add 'struct drm_writeback'
objects in order to store them.
These objects are created and stored in a list by the time
that DRM-backend is initialized. This list is updated if a
writeback connector dynamically appears or is disconnected.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of directly creating heads for the connectors in functions
drm_backend_create_heads() and drm_backend_update_connectors(),
add drm_backend_add_connector() that will handle this.
This split makes the code look better and will also make our lives
easier when we introduce writeback connectors.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Add helper function resources_has_connector(), what makes
the function drm_backend_update_connectors() look better.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
To deal with appearing/disappearing connectors we have the
function drm_backend_update_heads(). Rename it to
drm_backend_update_connectors(), as it is more in line with
what it does.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In case of success, drm_head_create() and drm_head_update_info()
take ownership of a connector. As this is an important
information, update the description of these functions
to include this.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The function drm_connector_assign_connector_info() should
not be calling functions to handle drm_head, as connectors
and heads are not the same thing after patch "drm-backend:
move connector data from struct drm_head to struct drm_connector".
Move drm_head specific calls to drm_head_update_info(). This
is more in line with the hierarchy of the objects and also
allow us to drop drm_head pointer from drm_connector.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of calling drmModeGetConnector() in drm_head_create()
and drm_head_update_info(), it is better to call it in
drm_backend_create_heads() and drm_backend_update_heads().
Then we can pass the drmModeConnector object as parameter.
This does not change the behavior of the code, but help us
to avoid unnecessarily calling drmModeGetConnector().
Besides that, in the future we will have support for writeback
connectors. And so drm_backend_create_heads() will be reworked
to also populate a list of writeback connectors. To make this
work, we are going to need to know if a connector is of the
writeback type or not, to know if we should call drm_head_create()
or drm_writeback_create(). We can only tell the type of connector
if we have the drmModeConnector object.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of calling drmModeObjectGetProperties() each time that we need
the connector properties, it is better to keep a reference for it in
struct drm_connector. This reference is only updated when is necessary.
E.g. hotplug events.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This is the first step in order to add support for writeback
connector in Weston. We don't want writeback connectors data
to be stored in 'struct drm_head' objects, as these objects are
used to output content and we should not use writeback connectors
for this purpose.
The writeback connectors will be stored in a new 'struct
drm_writeback', but the connector data is common between
'struct drm_head' and 'struct drm_writeback'.
So move connector data from 'struct drm_head' to 'struct
drm_connector'. This helps to avoid code duplication and makes
the code clearer.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit c1e89ba2 "compositor-drm: move connector fields into
drm_head" the function drm_head_assign_connector_info() was
introduced. By that time it was being used only at drm_head
creation, and not to handle connector changes.
In d2e6242e "compositor-drm: create heads for all connectors"
it started to be used also to handle connector changes. In
this scenario we replace old connector props with newer data.
Before doing this, free the old connector data to avoid memory
leak.
Note that as drm_property_info_free() is safe to be called on
a zero-initialized struct, we can call it even in the case where
the head is being created and there are no props yet.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Commit "drm-backend: move code to init/deinit planes to specific
functions" lost a chunk of drm_output_deinit() when moving code into
drm_output_deinit_planes(). Reinstate the missing chunk.
This fixes an endless loop over weston_compositor::plane_list when you
start with three monitors connected, unplug and re-plug one.
Fixes: 3be23eff99
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
After commit "drm-backend: move code to init/deinit planes to specific
functions" we have a specific function to init planes. As this function
does not set output->crtc, it should not set it to NULL in case of
failure. This is caller's responsibility.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some places where we can make some cosmetic changes
to make code simpler and easier to read. Make these cosmetic
changes. Note that they do not change the code behavior.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The code to init/deinit scanout and cursor planes was in
drm_output_init() and drm_output_deinit(). Move this code
to specific functions drm_output_init_planes() and
drm_output_deinit_planes(), as it makes the code clearer
and easier to maintain.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Now that we have a CRTC list in the DRM-backend, we can
iterate through it and look for the CRTCs that do not have
assigned outputs in order to find unused CRTCS.
So we can drop unused_crtcs from struct drm_backend and also
drop the functions drm_backend_update_unused_outputs() and
wl_array_remove_uint32().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are no 'struct drm_output' for CRTCs that are not active.
Also, CRTC data lives in 'struct drm_output'. This is causing
us some trouble, as the DRM-backend needs to program those
unnactive CRTCs to be off.
If the DRM-backend had the reference for every CRTC (being
active or not), it would make certain functions (e.g.
drm_pending_state_apply_atomic()) more simple and efficient.
Move CRTC data from 'struct drm_output' to 'struct drm_crtc',
as this is the first step to allow the DRM-backend to have
references for every CRTC.
Also, add list of CRTCs to DRM-backend object. Now the
DRM-backend is responsible for allocating/deallocating the CRTC
objects. The outputs will only reference, init and fini the CRTCs
in this list.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
