It's unclear if this is technically a violation of the protocol or not,
but it makes little sense to do this and many clients in the wild crash
if wl_keyboard.enter is sent before wl_keyboard.keymap.
If our current approch without xkbcommon translation does not match any
mapping on a key event attempt to match the translated keysym as well.
This makes e.g. the keypad number keys (e.g. KP_1) work intuitively as
they may require translation with numlock active.
The reason we stopped doing this in I7c02ebcbc was due to layout where
e.g. Super+Shift+Space is translated as Space with the Shift modifier
consumed, thereby conflicting with a separate mapping for Super+Space.
This should not be a issue anymore though as we now only run a maximum
of one mapping per key event and we attemt to match mappings without
xkbcommon translation before attempting with translation.
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.
When `focus-follows-cursor` is set and the cursor moves onto an output
where no views are present on the currently visible tags, focus the
output itself instead of an individual view.
This is useful e.g. when you want to spawn a terminal on your empty
monitor or switch it to a different tag. Previously such changes would
happen to the monitor on which you previous focus was, despite the
cursor being somewhere else.
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.
Previously new keyboards would not be added to already existing
keyboard groups on (re-)connect. Only during the creation of
the groups themselves were devices added to them. This meant
that only keyboards connected during startup - before the init
is executed - would work with groups in a typical river session.
This code could allows the view to be focused and urgent at the
same time if the request to activate the view is received just after
the pending focus has been set but before the transaction completes.
This commit leverages the new wlr_scene helper to send custom feedback
per surface rather than using the same default feedback for every
surface. This should allow direct scanout to work more reliably with
multiple outputs for example.
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.
The protocol states that we must send enter and leave to all text input
objects if the client has created multiple.
Only one text input is allowed to be activated by the client per seat
however.
Currently wlr-output-management config application is broken since the
pre 0.17 code relied on the (now removed) output enable/disable event to
be emitted as part of the state application.
The old code was pretty smelly and hard to understand, I'm glad the
upstream improvements pushed river's code in this directions.
Thanks to tiosgz for prompting me to look at this more closely.
There doesn't seem to be any compelling reason to use the
wlr_scene_output_layout helper, it's simpler to just make the two
necessary SceneOutput.setPosition() calls manually. This will hopefully
be refactored down to a single call eventually as well.
This logic that looked pointless to me while doing the wlroots 0.17
upgrade is in fact important as tiosgz helpfully pointed out.
It was added back in bc610c8b to address an issue. Hopefully the new
comments stop me from trying to break it again :)
The previous commit ended up clamping the accumulated f64 offset to an
integer every frame, losing any sub-pixel cursor motions. This has been
known to cause problems with high polling rate mice in the past.
Return to the same approve the move cursor mode uses to solve this and
accumulate a separate sub-pixel delta.
Currently resizing a window allows moving the invisible "internal"
cursor infinitely far off screen despite the fact that the window is
bounded by the size constraints of the client and by the output
dimensions. This means that attempting to resize past these bounds in
one dimension will result in the "internal" cursor being far out of
bounds and will require an equal movement in the opposite direction in
order to continue resizing.
Exposing this implementation detail of an invisible "internal" cursor
separate from the rendered cursor is of course bad, so clamp it to the
bounds of the resize.
Currently views which are mapped while no outputs are available can
never actually get rendered because they have 0 tags and are stuck in
the hidden stack.
This commit fixes this and they should now be restored when a new output
becomes available.
