Using values from the color representation protocol. Only supported for
YCbCr formats in KMS drivers for now.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
`EGL_YUV_COLOR_SPACE_HINT_EXT` and `EGL_SAMPLE_RANGE_HINT_EXT` have
to be set at image import, which again happens on wl_buffer creation.
This is problematic because in Wayland (and Vulkan) those values are
surface attributes and thus only known once the buffer gets attached
to a particular surface.
We solve that by first importing the dmabuf with default values and,
when attaching a buffer to a surface, creating additional EGLImages
as needed.
Note that we ignore `EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT` and
`EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT` for now, which are neither
required by the Wayland color-representation protocol nor supported by
Mesa shaders (as of 25.3).
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Unlike EGL image import, texture creation and binding is quite fast and
cheap. Thus, instead of doing it as early as possible in various places,
do it right before we actually need it in prepare_textured_draw().
This will follow-up changes easier and includes some preparations for
them.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Add matrix-coefficients and range tracking to more gl-renderer structures
and get the relevant values from the color-representation implementation
instead of hard-coding them in the shader.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
For now limited to coefficients and ranges that are typically
supported by KMS drivers. We notably leave out alpha modes and
chroma locations for now.
The protocol initialization is guarded by the WESTON_CAP_COLOR_REP
backend capability and thus not enabled anywhere yet.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Doesn't yet deal with work area (monitor area excluding panels etc), or
reconstraining while moving, but it's a start.
It's more or less based on the mutter implementation. While the mutter
implementation is GPL, it was authored by me, thus grant permission to
relicense to MIT.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Introduce support for the commit-timing protocol to allow applications
to attach a presentation time to a content update.
We use the repaint timer to schedule content updates in advance of
the frame time when they should be displayed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Currently this shouldn't result in any change, since the times we pass in
are real presentation times.
Later when commit-timing lets applications pass in arbitrary times, it
will be more interesting.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Validate repaint_msec so it's not longer than a refresh interval.
Negative repaint windows will cause problems for frame scheduling in the
future, so remove them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we add timed transactions, we'll want to feed them through the repaint
timer, so share it to allow this in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the near future commit-timing + VRR combined will want to have better
than the 1ms precision we're allowed now.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
After moving the drm-backend's scene graph dump, it now always occurs when
repaint_status is REPAINT_AWAITING_COMPLETION, which loses useful timing
information we used to have.
Add timing information for the REPAINT_AWAITING_COMPLETION state, and also
add the expected presentation time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we need to use VRR, we'll miss a potential frame deadline, fail to
deliver a frame, then stop the repaint loop. When a late frame comes
in, we deliver it immediately at the start of a new repaint loop.
The only time we really need to deliver a frame immediately is at
the start of the loop, otherwise we can use the same repaint window
behaviour as any other time.
This still leaves some room for improvement, as we still don't try
to avoid Vactive.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Move some code around so we only derive the next repaint from the next
presentation time and the repaint window once at the end of the function.
In many cases we now subtract the repaint_msec value from "now", but that's
ok because any time earlier than "now" will still result in firing the timer
at the same time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
These are used to determine if the previous frame was displayed with
tearing, which is useful in determining when the next frame time should
be.
Store these as a step towards breaking the frame time calculations out
of output_finish_frame into a separate function.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
For the upcoming commit-timing protocol, we're interested in when a
scheduled repaint will be displayed, so let's keep track of both the
repaint time and the anticipated presentation time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
At first we always used this workaround, and then we stopped using it when
VRR was in use.
Turns out it also hurts presentation times when starting the repaint loop,
which makes the commit-timing protocol difficult to implement.
Completely avoid the workaround on any kernel newer than 4.12, based on a
capability check for DRM_CAP_CRTC_IN_VBLANK_EVENT, and log a warning at
startup.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This fixes a bug in version 1 where we should've been giving a 0 refresh
for VRR, and introduces version 2 where we're allowed to give a compositor
chosen rate for VRR.
We currently chose the mode's native refresh rate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
GCC 14.2 with debugoptimized build complained:
../../git/weston/libweston/input.c: In function ‘weston_pointer_set_focus’:
../../git/weston/libweston/input.c:1988:29: error: ‘sx’ may be used uninitialized [-Werror=maybe-uninitialized]
1988 | pointer->sx = sx;
| ~~~~~~~~~~~~^~~~
../../git/weston/libweston/input.c:1913:20: note: ‘sx’ was declared here
1913 | wl_fixed_t sx, sy;
| ^~
../../git/weston/libweston/input.c:1989:29: error: ‘sy’ may be used uninitialized [-Werror=maybe-uninitialized]
1989 | pointer->sy = sy;
| ~~~~~~~~~~~~^~~~
../../git/weston/libweston/input.c:1913:24: note: ‘sy’ was declared here
1913 | wl_fixed_t sx, sy;
| ^~
Initialize with an arbitrary value to avoid the warning. This value
should never make it outside of this function.
The debug build did not complain.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we don't clamp the input before updating the pointer surface coords,
we'll trigger the "surface jumped beneath us" logic later when the clamp
really happens. That leads to spurious pointer leave/enter events.
Add clamping to weston_pointer_send_motion() to fix this.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Pull the clamping out and expose an internal pre-clamped function, which
will be used elsewhere in a later commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
when the hint_is_pending is true, it should assign the hint_pending to the hint and set the hint_is_pending to false, but the hint_is_pending set to true again after setting to false.
remove the redundant line to fix this.
Signed-off-by: Vorlune Zhang <Vorlune.Zhang@gmail.com>
If we're in a steady state, doing nothing but flipping buffers, we can
try to avoid going through our full routine of brute-forcing an
acceptable plane state, by instead just reusing the old state and
changing only the FB it refers to.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Keeping track of what mode we prepared the state in will be useful
for printing debug information later, when we have a way to reuse
old state.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're going to add a way to reuse state, but we don't currently have a way
to represent invalid state - such as before we've ever commit any state
at all.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
These have the same form, and we're about to add a few more with the same
form again, so make a helper function.
This sweeps up the one weird one that printed [view] while failing [state].
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This will be handy later when trying to determine when it's ok to reuse
output state, as changing this would invalidate previous state.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
On some aarch64 platforms with GCC13 we're seeing:
../../../weston-14-new/libweston/backend-drm/fb.c:152:15: warning: 'bo_fd' may be used uninitialized [-Wmaybe-uninitialized]
152 | ret = drmPrimeFDToHandle(fb->fd, bo_fd, &handle);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../weston-14-new/libweston/backend-drm/fb.c: In function 'drm_fb_addfb':
../../../weston-14-new/libweston/backend-drm/fb.c:117:13: note: 'bo_fd' was declared here
117 | int bo_fd;
Just initialize it to avoid trigger the warning.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
It looks like FALSE is only used in a few files in Weston, whereas false is much
more commonly used. Presumably FALSE comes from some library not included in
the headless backend (at least in my case).
FAILED: [code=1] libweston/backend-headless/headless-backend.so.p/headless.c.o
gcc -Ilibweston/backend-headless/headless-backend.so.p -Ilibweston/backend-headless -I../../home/qyliss/src/weston/libweston/backend-headless -I. -I../../home/qyliss/src/weston -Iinclude -I../../home/qyliss/src/weston/include -Ilibweston -I../../home/qyliss/src/weston/libweston -Iprotocol -I/nix/store/mvhj7fm6bkmz6ismdp8vcmwn34w94b8n-libglvnd-1.7.0-dev/include -I/nix/store/v7jn3cy1wjaf9pm60ix9y6dfma0bj4a3-wayland-1.24.0-dev/include -I/nix/store/xi04j07bl6bbckky5n8a1k06spxxfg9i-pixman-0.46.4/include/pixman-1 -I/nix/store/xvzhnfwxvl480qpjxm83wwhd287b3lgm-libxkbcommon-1.11.0-dev/include -I/nix/store/22qgb8p593613861117ay4gzmf9b7rns-libdrm-2.4.125-dev/include -I/nix/store/22qgb8p593613861117ay4gzmf9b7rns-libdrm-2.4.125-dev/include/libdrm -I/nix/store/zl58kqaf677skihj840rf05svsmrhmmc-cairo-1.18.4-dev/include/cairo -I/nix/store/6sscd9xxffhjrci2xbw9yv8inc2rc0ry-freetype-2.13.3-dev/include/freetype2 -I/nix/store/6sscd9xxffhjrci2xbw9yv8inc2rc0ry-freetype-2.13.3-dev/include -I/nix/store/z88mxig65mxgyn1yxsz92m4w1rn51aci-libpng-apng-1.6.50-dev/include/libpng16 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -std=gnu11 -O0 -g -Wmissing-prototypes -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef -fvisibility=hidden -Wmissing-prototypes -Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef -fvisibility=hidden -fPIC -MD -MQ libweston/backend-headless/headless-backend.so.p/headless.c.o -MF libweston/backend-headless/headless-backend.so.p/headless.c.o.d -o libweston/backend-headless/headless-backend.so.p/headless.c.o -c ../../home/qyliss/src/weston/libweston/backend-headless/headless.c
../../home/qyliss/src/weston/libweston/backend-headless/headless.c: In function ‘config_init_to_defaults’:
../../home/qyliss/src/weston/libweston/backend-headless/headless.c:788:29: error: ‘FALSE’ undeclared (first use in this function)
788 | config->fake_seat = FALSE;
| ^~~~~
../../home/qyliss/src/weston/libweston/backend-headless/headless.c:788:29: note: each undeclared identifier is reported only once for each function it appears in
Fixes: 0126a5b4 ("backend-headless: Add an option to enable a fake seat")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
The helpful error message with the hint to set -Dbackend-vnc=false was
unreachable, because libpam would either be found, or the default, less
helpful error message for a missing library would be shown.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
When running headless, weston will not expose a wl_seat.
This was removed with commit a1046adc ("compositor-headless: do not
create a seat").
However, some applications, namely GTK3 based, will log a warning when
there is no wl_seat:
| gdk_seat_get_keyboard assertion GDK_IS_SEAT(seat) failed
While this is arguably a bug in GTK3 which should not complain with a
legit setup, that breaks the CI of those projects when using Weston,
while most of the other Wayland compositors will create a fake seat when
running headless, making weston the odd ball there.
This changes adds a new option "--fake-seat" that will instruct weston
to create a seat when running headless. The default remains not to
create a seat though, so backward compatibility is preserved.
This partially reverts commit a1046adc66.
See-also: https://gitlab.freedesktop.org/ofourdan/xwayland-run/-/issues/12
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Add support for the fifo protocol, which allows an application to submit
a content update that can only be applied after the previous content
update has been active for a display refresh.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have surface-state application streamlined, it's fairly easy to
add a framework for deferring content updates.
This will be used soon for fifo and commit timing. For now, the
weston_surface_state_ready() call that makes any of this do something
will always return true.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If a surface isn't visible, there's no point in performing a repaint when
its state changes. However, we don't know if a surface is visible until
we perform the scene graph updates at repaint.
Use our new visibility tracking API to check whether we need to perform
a repaint, or if we can just skip it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Keep track of whether a view has any unoccluded pixels on an output,
use this information to add a weston_surface_visibility_mask() function
that we'll use later.
Since the visibility information is calculated at repaint, and invalidated
by some (but not all) state updates, we'll keep track of when the previous
repaint's status is still valid by watching surface status bits.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Seems like it makes sense to have it there, and this cleans up a bunch of
paths where we return status bits so a caller can do this.
We can also drop the explicit setting of view_list_needs_rebuild, as it's
going to happen automatically when applying subsurface order.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Latch is the moment when the compositor considers updates for an upcoming
redraw. Nothing that takes place after an output latches for repaint can
change what will be repainted.
This needs a more explicit treatment now that upcoming transactional
protocols require things to happen immediately after the latch (ie:
when it's too late to change the upcoming render).
Add an explicit latch point, a signal to tap for testing, and some asserts
to make sure nothing can violate the inevitability of the current render
state.
Note that currently latch is tied to repaint such that we only claim to
have latched when a repaint will happen. In a future commit this will lead
to forcing the repaint loop to fire without damage when the fifo protocol
needs something to happen after a latch. This could be an area for
future improvement.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're going to be adding protocols (commit-timing, fifo, syncobj) that
allow deferred surface content updates.
It makes sense to start the perfetto flow ids from the surface state so
we can track a flow from creation (ie:commit) to presentation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was discussed in wayland-protocols MR 273, and clarified in wayland
MR 379 - presentation feedback applies to content updates, not buffers.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This ensures (an unlikely) cases where get_label might be called and the
callback itself would makes use committted_private to retrieve callback
data. Just make sure to set it prior.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Implement media white point scaling according to ICC.1:2022 (profile
v4.4), section 6.3.2.2 "Translation between media-relative colorimetric
data and ICC-absolute colorimetric data".
This is a lot of code for something that, under the current
circumstances, is a no-change. However, realizing that chromatic
adaptation and media white point scaling are two separate adjustments
was a revelation to me. I want to document in code how they work, even
if the net result is no-op.
The PCS white point is taken from ICC, it does not matter what non-zero
point it is, the result will be the same.
I did skip a bit the media white point scaling. One should first scale
from in to PCS, and then from PCS to out. The code is mathematically
equivalent. If some new operation needs to be done in between, this step
than be split in two, just like I split the chromatic adaptation step in
two in this patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
