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>
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>
Specifically log if there were no suitable planes for us to use, or if
we tried to place it on a plane but were told no by the kernel.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There's no real reason for these to be separate now that the eligibility
checks have been moved up so we don't call them unless it makes sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We just copy the SHM buffer straight into a separately-allocated GBM BO,
so no need to take a reference on the buffer itself or keep it from
being released.
All drm_output_try_view_on_plane really does at this point is to call
the prepare_*_view function for the requisite plane type, and take a ref
on the weston_buffer from the client. Given that we don't need to keep
the client buffer alive, we can short-circuit
drm_output_try_view_on_plane, and instead just call
drm_output_prepare_cursor_view directly when we have a cursor plane.
This also makes it easier to just remove drm_output_try_view_on_plane in
following patches when we merge the overlay/scanout plane path into one.
Doing so gives us two clearly-separated paths: one for copying a SHM
client buffer into a cursor, and another for directly scanning out
client content.
Signed-off-by: Daniel Stone <daniels@collabora.com>
At some point this got hobbled, such that NO_PLANES and
NO_PLANES_ACCEPTED became the same thing, so we can just check if the
returned plane_state is NULL or not.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For views which cover the entire output, we always attempt to place them
on the primary plane, to avoid a situation where we place a fullscreen
view into an overlay plane and then have to disable the primary plane,
which doesn't always work.
Move this check earlier, so we don't consider overlay planes to be
candidates for fullscreen views. This check should be changed in future
to only filter for opaque views, but that's for another time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We shouldn't get down into trying to place a view on a cursor plane if
these checks are not met, so change them to asserts rather than early
returns.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we introduced support for variable zpos, we did so by filtering the
list of acceptable planes and then creating a separate zpos-ordered
list. Now that the planes are already zpos-sorted in the backend list,
and we have more early filtering, we can replace this with a single
plane-list walk.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For better or worse, cursor planes can only be used by uploaded SHM
buffers right now, so ignore them when we're calculating the acceptable
plane mask for client dmabufs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we're in renderer-only mode, we can only use the renderer and the
cursor plane. Don't even try to import client buffers as it makes no
sense.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have a SHM buffer, it can only go into a cursor plane - and only
then if it's of the right format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Each output is hardcoded to the use of a single 'special' (primary or
cursor) plane; make sure we don't try to steal them from other outputs
which might not be happy to discover that we've taken it off them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
GBM is how we import all our client content into DRM FBs, so don't try
anything other than renderer-only without it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It's possible to write this with a few less twisty special cases. Tested
manually with a randomly-distributed input tree as well as manually
trying to hit special cases around first/last entries.
Signed-off-by: Daniel Stone <daniels@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>
When EGL initialization fails (failure to create a GLES3 or GLES2
context) we will end up calling gbm_device_destroy() twice, once
in init_egl() and once in the drm_backend_create() error path.
Given that we should also take care of properly destroying the gbm
device when we don't have any inputs for instance, mark the gbm device
as NULL to avoid calling gbm_device_destroy() once more when destroying
the DRM-backend.
Signed-off-by: Marius Vlad <marius.vlad@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>
When we first create a drm_fb from a weston_buffer, cache it and keep it
alive as long as the buffer lives. This allows us to reuse the gbm_bo
and kernel-side DRM framebuffer, rather than constantly creating and
destroying them at every repaint. The overhead of doing so (e.g. MMU
updates) can be significant on some platforms.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently each drm_fb takes a reference on a client buffer it wraps.
This prevents us from being able to reuse a drm_fb in multiple places
(e.g. two views of the same client buffer) simultaneously, or even back
to back.
Move the buffer reference to the plane state, as preparation for
allowing drm_fb to be cached inside the weston_buffer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently we take a reference on the underlying client buffer every time
we materialise a drm_fb from a view, and release it when the drm_fb is
destroyed. This means that we need to create and destroy a drm_fb every
time we want to use it, which is pathologically unperformant on some
platforms.
To start working towards being able to cache drm_fb, only take the
reference when we apply it to a plane state.
Signed-off-by: Daniel Stone <daniels@collabora.com>
No sense walking the plane list every frame if we can't use it because
it's neither a SHM buffer nor a client buffer we can directly import as
a framebuffer.
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>
Add enum try_view_on_plane_failure_reasons to help us to keep track of
the reason why promoting view to a plane failed. We also add a variable
to struct weston_paint_node so that we can update this information in
each output repaint.
This will be used in the next commits, in which we add proper surface
dma-buf feedback support.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reported in !179 adding weston_output_repaint_failed resets the output
Co-authored-by: Daniel Stone
Co-authored-by: Julius Krah
Signed-off-by: n3rdopolis <bluescreen_avenger@verizon.net>
The API expects uintptr_t (good!), but we're passing an unsigned long
here. Make the conversion explicit.
Signed-off-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>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@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>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If sprites_are_broken, then we will only ever arrive in renderer_only
mode, so this case will be caught by the checks above.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Weston internals and Wayland clients assume that output presentation
clock cannot go backwards. Therefore require unconditionally that KMS
uses the monotonic clock.
The kernel unconditionally supports DRM_CAP_TIMESTAMP_MONOTONIC. See:
commit 25e1a79874eb3821d93310c908cc0a81b47af060
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Oct 11 17:20:13 2017 +0200
drm: vblank: remove drm_timestamp_monotonic parameter
That one removed the final possibility of DRM_CAP_TIMESTAMP_MONOTONIC
being false, by removing the module option. But even before that, all
drivers have been supporting monotonic, since
commit c61eef726a78ae77b6ce223d01ea2130f465fe5c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Oct 23 18:53:26 2012 +0000
drm: add support for monotonic vblank timestamps
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
fb->format is *pixel_format_info, whereas fb->format->format is the
actual DRM/wl_shm format code we want to see here. Fix the drm_debug()
call accordingly.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
In drm_fb_get_from_dmabuf() we have some compile time array copies, and
multiple static_assert() calls are needed (for safety). This makes the
code unpleasant to read.
Add ARRAY_COPY macro, to simplify the code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: do not import dmabuf buffers with no modifiers
to KMS" we've stopped to import dmabuf with no modifiers to KMS.
In this patch we document why we can still import wl_drm buffers with no
modifiers to KMS.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We can't tell the layout of a buffer that has been allocated with no
modifiers. Although usually drivers use linear layouts to allocate in
these cases, it is not a rule. It can use a tiling layout, for instance,
under the hood.
So it is not safe to import a buffer with no modifiers to KMS, as it
can't tell the buffer layout and this may result in garbage being
displayed. In this patch we start to require explicit modifiers to
import buffers to KMS.
In most cases things just work as expected, but just because both sides
(display and render driver) usually end up using the linear layout when
modifiers are not exposed. It also works on systems where the display
and render devices are tied (desktops with Intel or AMD, for instance),
as there's only one driver and it knows the layout of the buffer (no
need to guess).
But in SoC's where the display and render device are split, things can
go wrong. It is better to lose performance and not break things. To
solve the problem, drivers should be updated to expose modifiers (even
if only DRM_FORMAT_MOD_LINEAR), as the concept of implicit modifiers is
the root of the problem.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: add DRM_FORMAT_MOD_INVALID to modifier sets when
no modifiers are supported" we've changed the code that iterates through
the IN_FORMATS blob property. Now it adds DRM_FORMAT_MOD_INVALID for
formats exposed without modifiers.
But the thing is that there shouldn't be formats in the IN_FORMATS blob
exposed without modifiers, as the blob has been added after the
introduction of the explicit modifiers API in the kernel. For now,
there's nothing in the kernel to ensure this correct behavior. So
instead of adding DRM_FORMAT_MOD_INVALID in this case, ignore these
formats, as userspace can't do much in this case.
In the future this may be fixed by the kernel. Or maybe the following MR
in libdrm, which adds an iterator API for the IN_FORMATS blob:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/146
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.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 create_gbm_surface() we may allocate with no modifiers in the
following situations:
1. old GBM version, so HAVE_GBM_MODIFIERS is false;
2. the KMS driver does not support modifiers;
3. if allocating with modifiers failed, what can happen when the KMS
display device supports modifiers but the GBM driver does not, e.g.
the old i915 Mesa driver.
The comment was only stating the third situation, so add the other two.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The function drm_output_init_egl() is too big, so move the code to
create the gbm surface to a separate function: create_gbm_surface().
Also made some minor style changes to the code that has been moved, in
order to improve readability.
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 drm_output_prepare_plane_view() we iterate the list of planes and add
them as candidates to promote the view to one of them.
Cursor planes do not support buffers other than wl_shm (at least for
now). So when we have a dmabuf or an EGL buffer in the view, the
function drm_output_plane_cursor_has_valid_format() returns false and
the cursor plane is not added to the candidate list.
In this patch we move the responsibility of doing this from
drm_output_plane_cursor_has_valid_format() to
drm_output_prepare_plane_view() itself, as the incompatibility between
other types of buffers and cursor planes is different from the
incompatibility between formats. This makes the code easier to read
and also documents the current incompatibility between cursor planes
and buffers that are not created through wl_shm.
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>
In some situations, like positioning a sub-surface that exceeds the
output's dimensions we would adjust the plane state dimensions to some
lower values to that of the buffer. That would ultimately trip the cursor
update function because the buffer itself actually exceeds the maximum
size/dimension of the cursor.
The plane state destination co-ordinates is the area of the view which
is visible on the output, which in some situations, would actually be
smaller than the original buffer dimensions (making it so that it will
pass the cropping/scaling check), but depending on of
how large is the surface buffer, it would tripping the assert wrt to
cursor width/height dimensions.
This hasn't been seen so far due to the fact that until recently we had
a cursor surface that always reached the cursor plane and that was
already being set-up by default (with desktop-shell, which is no longer
the case), and also because kiosk-shell, which doesn't set-up a cursor
surface, was not available.
This adds a check to skip placing the view in the cursor plane if the
buffer dimensions exceed the cursor permitted width/height.
(Suggested-by Daniel Stone).
Signed-off-by: Marius Vlad <marius.vlad@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>
MOD_INVALID came with libdrm 2.4.83 and MOD_LINEAR came with libdrm
2.4.82. libweston unconditionally depends on libdrm >= 2.4.95, so the
fallback is not necessary.
Since linux-dmabuf.h itself has no use for these and also forgets to
include drm_fourcc.h, .c files including drm_fourcc.h after this header
would trigger compiler warnings.
linux-dmabuf.c does need these, so add the proper include.
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>
gbm-drm.c includes gl-renderer.h. When EGL is enabled, that in turns
includes egl.h. As such, dependencies for drm should include EGL if
it is available.
This condition is modelled after a similar one in libweston/meson.build
Reported-by: Gary Bisson <gary.bisson@boundarydevices.com>
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Refik Tuzakli <tuzakli.refik@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.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>
96bef0517e "drm-backend: add support for
writeback connectors" started using DRM_MODE_CONNECTOR_WRITEBACK and
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS. These were introduced in libdrm
2.4.95.
According to
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/311
Ubunut Xenial is the only mentioned distribution that does not provide a
libdrm new enough. I think that is fine to drop now, 2016 was a good
while ago.
Libdrm 2.4.95 also introduced DRM_CLIENT_CAP_ASPECT_RATIO,
DRM_MODE_PICTURE_ASPECT_64_27, DRM_MODE_PICTURE_ASPECT_256_135.
The fallback definitions for the above are dropped.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.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>
Try to make drm_output_state_propose a little more clear by reducing
divergence between plane and renderer modes towards the end, removing
a possibly-surprising conditional continue.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reduce the scope of surface_overlap to where it's actually used, which
is only in the per-view loop, where it gets initialised and destroyed
every time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Previously we assumed that cursor planes occluded nothing and would
always be blended, but overlay and scanout planes would always occlude
what's behind them. This is not actually true, as we can support alpha
blending on any kind of plane type now.
Remove the special case, which might hopefully fix some weird display
issues along the way. (Noticed by inspection.)
Signed-off-by: Daniel Stone <daniels@collabora.com>
We used to use planes_region for the output regions which were being
displayed on hardware planes; before we grew zpos awareness, we couldn't
have any planes overlapping with each other, since the ordering would be
undefined.
Since the zpos awareness though, this region is unused, so we can just
remove it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Initially finish_frame() was never called in drm_output_update_complete() for
'dpms_off_pending = true'. This is wrong for repaint_status ==
REPAINT_AWAITING_COMPLETION and that was fixed in
68d49d772c ("compositor-drm: run finish_frame when
dpms is turned off in update_complete").
However finish_frame() may now be called for repaint_status !=
REPAINT_AWAITING_COMPLETION, which is not allowed and results in a failed
assertion.
Fix this by checking dpms and repaint_status unconditionally.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
It seem that we skipped to put back in TEXT mode the tty, in case a DRM
device node wasn't present at that time, or it isn't present at all. This
orders the destroy part correctly as to handle that case as well.
As a side effect, as the tty will still be set to GRAPHICS mode we will
require a manual change of the tty number, which might be not possible
on all systems. Properly putting back the tty to TEXT mode should avoid
that, and allows to re-use the same tty no in case the DRM device has
been created at a later point in time.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Allow to disable GBM modifiers at runtime using the environment variable
WESTON_DISABLE_GBM_MODIFIERS.
This can be useful for debugging or when modifiers cause issues, e.g. in
case modifiers use higher memory bandwidth and hence impose a lower
resolution limit as it is the case with Intel Kaby Lake graphics.
Related to: https://gitlab.freedesktop.org/wayland/weston/-/issues/404
Signed-off-by: Stefan Agner <stefan@agner.ch>
The pipewire plugin uses this API as well, not just the remoting plugin. So
enable it if either is enabled.
And disable pipewire in the no-gl-renderer CI build. The virtual outputs don't
work without it.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface is not visible, then is does not matter if the view is on multiple
outputs. It will be skipped anyways when the output is rendered.
So check first if the surface is acually visible on the output before doing any
checks that might force rendering. This avoids unnecessary rendering.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
When dissociating a universal plane from a crtc, we currently don't
reset the current state of the plane (plane->state_cur). When attempting
to use this plane in the future, we can run into invalid memory accesses
due to left over associations with potentially freed drm backend
objects. This commit resets the state of the scanout and cursor
universal planes associated with a crtc.
The following scenario exhibits the problem:
1. Start a (fullscreen) client that is suitable for and assigned to
the scanout plane. The plane's state_cur->output value is set.
2. Unplug the monitor: the scanout plane is "released" but still
maintains the state_cur->output association.
3. Replug the monitor: the plane is deemed unavailable due to an
existing, albeit invalid, state_cur->output value. Note the memory
errors trying to access the drm_output which was freed at step (2).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
There's a log that advertises support for universal planes. That
can make users think there's something wrong with Weston or their
systems when universal planes are not supported, but that's not
the case. Remove this log from the code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This moves the creation of the blob to be earlier, to when the damage is
calculated. It replaces the damage tracked inside of the plane state
with the blob id itself.
This should stop creating new blob ids for TEST_ONLY commits, and them
being leaked in general, as the blob ids are now freed with the plane
state.
The FB_DAMAGE_CLIPS property is now always set if it's supported, and
will be 0 in the case that we have no damage information, which
signifies full damage to the kernel.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
In the test suite we may want to run a DRM-backend test on a
non-default seat, which may not have a input device associated.
Weston's default behavior is to not open if input devices are
not found, as it may cause troubles. For instance, Weston can
open but if no input device is set than the user can not
interact or leave it.
Add flag --continue-without-input to DRM-backend so we can run
these types of tests with no input. Notice that this won't force
the compositor to skip opening a input device if it finds it on
the non-default seat.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Without universal plane, the weston crashes with null pointer access in
set_gbm_format function because that function called before output
enable function. By changing timing to set color format for primary
plane in this case, this issue fixes.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
pixman_renderer_output_create currently takes a flags enum bitmask for
its options. Switch this to using a structure, so we can introduce other
non-boolean options.
Signed-off-by: Daniel Stone <daniels@collabora.com>
gl_rendererer's output_window_create has a lot of arguments now. Add a
structure for the options to make it more clear what is what.
This is in preparation for adding bare-integer arguments which are ripe
for confusion when passing positional arguments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
gl_rendererer's output_create has a lot of arguments now. Add a
structure for the options to make it more clear what is what.
This is in preparation for adding bare-integer arguments which are ripe
for confusion when passing positional arguments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The renderer buffer size is usually the same size as the current mode,
so we were taking the dimensions from the currently-set mode. However,
using current_mode is quite confusing in places when it comes to scale,
and it also hampers our ability to do mode switches, as well as to
introduce a future option which will let the renderer use a smaller
buffer than the output and display scaled.
Simply take the dimensions of the renderer's output buffer from the
buffer itself.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This condition inside drm_output_render() checks if we can reuse the
existing renderer buffer for the primary plane; this occurs in
mixed-mode composition where a client buffer promoted to a plane has
changed, but the primary plane is unchanged.
We accomplish this by checking if there is no damage on the
primary/renderer plane, and then if there is already a renderer buffer
active on the primary plane: in that case, we can reuse the buffer we
already have.
There was a further condition checking if the width and height were
identical. This was designed to prevent against issues on mode changes.
However, runtime mode changes are already quite broken, and a mode
change will also cause damage on the full plane. We can simply remove
this condition.
Signed-off-by: Daniel Stone <daniels@collabora.com>
