Instead of having a pending_fb field on the struct wlr_drm_plane,
move it to struct wlr_drm_connector_state. That way, there's no
risk having a stale pending FB around: the state doesn't survive
across tests and commits.
The cursor is a special case because it's disconnected from the
atomic state: the wlr_backend_impl.set_cursor hook sets the cursor
for the next commit. Move the field to
wlr_drm_connector.cursor_pending_fb.
We'll move the pending primary FB into the connector state in the
next commit, dropping wlr_drm_plane.pending_fb in the process.
Introduce a dedicated field for the cursor, which has to be managed
in a special way due to our set_cursor API.
This avoids re-building the whole project when switching one
Meson option. This shrinks down the compiler invocation command
line, making it more readable and making it easier to inspect
which flags are passed in (the generated file can be opened).
Additionally this is more consistent with our external feature
handling, which uses <wlr/config.h> already.
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 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.
"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
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.
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
All the code logic related to the pointer has been moved to its own file.
The seat is responsible for the lifetime of its wlr_wl_pointer(s), and assigning
them to the relevant wlr_wl_output. The wlr_wl_pointer becomes a simple helper
to manager the wlr_pointer associated to the seat's wl_pointer and its lifetime.
The destroy callback in wlr_tablet_tool_impl has been removed. The function
`wlr_tablet_tool_finish` has been introduced to clean up the resources owned by
a wlr_tablet_tool.
`wlr_input_device_destroy` no longer destroys the wlr_tablet_tool, attempting to
destroy a wlr_tablet_tool will result in a no-op.
The field `name` has been added to the wlr_tablet_tool_impl to be able to
identify a given wlr_tablet_tool device.
The destroy callback in wlr_tablet_pad_impl has been removed. The function
`wlr_tablet_pad_finish` has been introduced to clean up the resources owned by a
wlr_tablet_pad.
`wlr_input_device_destroy` no longer destroys the wlr_tablet_pad, attempting to
destroy a wlr_tablet_pad will result in a no-op.
The field `name` has been added to the wlr_tablet_pad_impl to be able to identify
a given wlr_tablet_pad device.
Sometimes the headless backend is used standalone with the Pixman
renderer, sometimes it's used together with another backend which
has already picked a DRM FD. In both of these cases it doesn't make
sense to pick a DRM FD.
Broadly speaking the headless backend doesn't really care which DRM
device is used for the buffers it receives. So it doesn't really
make sense to tie it to a particular DRM device.
Let the backend users (e.g. wlr_renderer_autocreate) open an arbitrary
DRM FD as needed instead.
