Instead of special-casing modesets, we can just cut the wrapper
and directly call drm_crtc_page_flip(). drm_connector_test() should
already have the checks previously done in drm_connector_set_mode(),
all we need to do is update enabled/mode after a successful atomic
commit.
This field becomes stale too easily: for instance, see 6adca4089c
("backend/drm: don't unconditionally set desired_enabled").
Additionally, drm_connector_alloc_crtc() needs to do some weird
dance, restoring its previous value.
Instead, add a connector arg to realloc_crtcs() to indicate a new
connector we want to enable.
We were unconditonally setting desired_enabled = true for all
connected connectors. This makes realloc_crtcs() always keep a CRTC
active for these, even if the user doesn't want to enable them.
When starting up, the compositor might call wlr_output_set_mode()
with a mode which is already the current one. wlroots will detect
this and make the wlr_output_set_mode() call a no-op. During the
next wlr_output_commit() call, wlroots will perform an atomic
commit without the ALLOW_MODESET flag.
This is an issue, because some drivers need ALLOW_MODESET even if
the mode is the same. For instance, if the FB stride or modifier
changed, some drivers require a modeset.
Add a new flag "allow_artifacts" which is set when the compositor
calls mode-setting functions. Use this flag to figure out whether
we want to perform atomic commits with ALLOW_MODESET.
(The name "allow_artifacts" is picked because ALLOW_MODESET is a
misnomer, see [1].)
[1]: https://patchwork.freedesktop.org/patch/505107/
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
Stack trace:
#0 0x00007f17081f5b99 in wl_list_insert (list=list@entry=0x2d8, elm=elm@entry=0x7ffe7f7e85d0)
at ../wayland-1.21.0/src/wayland-util.c:48
#1 0x00007f17081f5f2e in wl_signal_emit_mutable (signal=signal@entry=0x2d8, data=data@entry=0x7ffe7f7e8660)
at ../wayland-1.21.0/src/wayland-server.c:2167
#2 0x00007f170815a971 in handle_switch_toggle (wlr_switch=0x2a0, event=0x55d5ba13dc00)
at ../backend/libinput/switch.c:50
#3 handle_libinput_event (event=0x55d5ba13dc00, backend=0x55d5b975d740) at ../backend/libinput/events.c:234
#4 handle_libinput_readable (fd=<optimized out>, mask=<optimized out>, _backend=<optimized out>)
at ../backend/libinput/backend.c:58
#5 handle_libinput_readable (fd=fd@entry=34, mask=mask@entry=1, _backend=_backend@entry=0x55d5b975d740)
at ../backend/libinput/backend.c:48
#6 0x00007f170815c110 in backend_start (wlr_backend=0x55d5b975d740) at ../backend/libinput/backend.c:109
#7 0x00007f1708160996 in multi_backend_start (wlr_backend=0x55d5b97583d0) at ../backend/multi/backend.c:32
All we can do to influence adaptive sync on the X11 backend is set the
_VARIABLE_REFRESH window property like mesa automatically does. We don't
have any control beyond that, so we set the state to enabled on creating
the output and never allow changing it (just like the Wayland backend).
Adaptive sync is effectively always enabled when using the Wayland
backend. This is not something we have control over, so we set the
state to enabled on creating the output and never allow changing it.
Previously, adaptive sync was just a hint and wouldn't make any
atomic commit fail if the backend didn't support it. The main reason
is wlr_output_test wasn't supported at the time.
Now that we have a way for compositors to test whether a change can
work, let's remove the exception for adaptive sync and convert it to
a regular output state field.
We were firing the new_input signal on backend initialization,
before the compositor had the chance to add a listener for it.
Mimick what's done for wl_keyboard: if the backend hasn't been
started, delay wl_touch initialization.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3473
On newer versions of libinput, the event LIBINPUT_EVENT_POINTER_AXIS
has been deprecated in favour of LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS.
Where new events are provided by the backend, ignore
LIBINPUT_EVENT_POINTER_AXIS, receive high-resolution scroll events from
libinput and emit the appropiate wlr_pointer signal.
Currently, the "wlr_event_pointer_axis" event stores low-resolution
values in its "delta_discrete" field. Low-resolution values are always
multiples of one, i.e., 1 for one wheel detent, 2 for two wheel
detents, etc.
In order to simplify internal handling of events, always transform in
the backend from the low-resolution value into the high-resolution
value.
The transformation is performed by multiplying by 120. The 120 magic
number is used by the kernel and it is exposed to clients in the
"WLR_POINTER_AXIS_DISCRETE_STEP" constant.
Starting with Linux Kernel v5.0 two new axes are available for
mice that support high-resolution wheel scrolling: REL_WHEEL_HI_RES and
REL_HWHEEL_HI_RES.
Both axes send data in fractions of 120 where each multiple of 120
amounts to one logical scroll event. Fractions of 120 indicate a wheel
movement less than one detent.
Three new events are now available on libinput:
LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER, and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS.
These events replace the LIBINPUT_EVENT_POINTER_AXIS event, so new
clients should simply ignore that event.
Also, two new APIs are available to access the high-resolution data:
libinput_event_pointer_get_scroll_value() and
libinput_event_pointer_get_scroll_value_v120().
Add a project argument (LIBINPUT_HAS_SCROLL_VALUE120) to allow
building against old versions of libinput or, where high-resolution
scroll is available, support it.
"max bpc" is a maximum value, the driver is free to choose a
smaller value depending on the bandwidth available.
Some faulty monitors misbehave with higher bpc values. We'll add
a workaround if users get hit by these in practice.
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/612
The EDID 1.4 spec says that the serial number is optional:
> If this field is not used, then enter “00h, 00h, 00h, 00h”.
Leave the wlr_output.serial field NULL in that case, and hide it
from the output description.
CTA-861-G says that "graphics" is used to indicate non-analog (ie,
digital) content. With that bit set, the sink should turn off analog
reconstruction and other related filtering.
Some output commits (changing e.g. the output scale or transform)
don't require any change in the KMS state. Instead of going through
a KMS commit, return early. Blocking KMS commits can be expensive.
The wlr_output API requires compositors to wait for wlr_output.frame
before submitting a new buffer. However, compositors can perform a
commit which doesn't involve a buffer anytime.
If the commit is a modeset, we set DRM_MODE_ATOMIC_ALLOW_MODESET and
block until the commit is done. If it isn't, we currently always
perform a non-blocking commit. This is an issue because a previous
page-flip might still be in flight kernel-side, returning EBUSY.
Fix this by using blocking commits when a buffer isn't submitted by
the compositor.
Closes: https://github.com/swaywm/sway/issues/6962
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2239
This allows the make/model/serial to be NULL when unset, and allows
them to be longer than the hardcoded array length.
This is a breaking change: compositors need to handle the new NULL
case, and we stop setting make/model to useless "headless" or
"wayland" strings.
Prior to [1], if an entry in a DRM format set was different than a
single LINEAR modifier, implicit modifiers were always allowed. This
has changed and now implicit modifiers are only allowed if INVALID
is in the list of modifiers.
So now we can safely enable explicit modifiers for cross-GPU imports,
without risking receiving buffers with an implicit modifier. This
should improve perf a bit on setups where two GPUs from the same vendor
are used.
This fixes the first bullet point from [2].
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3231
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3331
Maintaining our internal table up-to-date is tedious: one needs to
manually go through the PnP ID registry [1] and check whether we're
missing any entry.
udev_hwdb already has an API to fetch a manufacturer name from its
PnP ID. Use that instead.
[1]: https://uefi.org/pnp_id_list
