There is not any pointer emulation for tablet tool input. This means
that only clients implementing the tablet-v2 protocol will be able to
process tablet tool input.
Tablet pad support is TODO
It seems to be a bit too early to drop support for this legacy protocol.
Xwayland apparently still relies on it for hardware acceleration as do
fairly recent mesa versions still in widespread use.
wlroots will now load xcursor themes at the correct scale automatically
based on the scale of the outputs where ther cursors are displayed.
Also make the error handling a bit more robust.
wl_drm is a legacy interface superseded by the linux-dmabuf
protocol. All clients should migrate.
This commit drops support for the protocol which should help find
whatever problematic clients are left in the wild.
If it turns out that this is too soon we can easily keep supporting
wl_drm for a little while longer as wlroots has not yet dropped support
for it.
These new functions allow testing commits without messing up the
pending state of the output and needing to rollback. The new apply()
function also makes the code considerably more concise.
It was forgotten to destroy the callback server side object when sending
the destructor event. With the new zig-wayland version, this cannot be
forgotten.
This fixes the return type of Foo.fromWlrSurface() functions which can
in fact return null in the edge case that the role matches but the
corresponding object has already been destroyed.
e.g. `riverctl map -layout 0 normal Super Y spawn foot`
When this mapping is checked against a pressed key, layout 0 will be used to translate the pressed key instead of the currently active layout.
The number denotes to an index of the layouts set with
`XKB_DEFAULT_LAYOUT`.
Currently wlroots sends use the drag destroy event before sending the
wl_data_device.leave event to the client, which makes things a bit
awkward. My patch fixing this has been merged to wlroots master so we
can remove this when upgrading to wlroots 0.15, but until then this
workaround will fix the issue.
Currently the implementation treats the x/y coordinates of
View.State.box as layout coordinates instead of output-relative. This
causes issues when using an output not at 0,0.
