wayland: Add multi-seat support #12626
Merged
+1,805
−1,403
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
from
01e7666 to
c91efa9
Compare
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
2 times, most recently
from
002be63 to
99db823
Compare
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
3 times, most recently
from
b77e974 to
5182f4e
Compare
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
4 times, most recently
from
4afdf19 to
b65f3c4
Compare
|
This should be good to go at this point. Going to go over it once again tomorrow for final review and testing. Things can still get a little weird in the multi-seat case if two different windows both have input focus from different seats at the same time, but I plan on looking into that separately. The overwhelmingly common single-seat case still works as it did before, with no noticeable difference. |
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
3 times, most recently
from
096e0eb to
77a6133
Compare
Wayland environments can expose more than one seat for multiple collections of input devices, which can include multiple, simultaneously active, desktop pointers and keyboards with independent layouts. The Wayland input backend previously presumed that only one seat could exist, which caused broken behavior if the compositor exposed more than one, which is possible on wlroots based compositors such as Sway. This introduces support for handling multiple seats, including proper handling of dynamically added and removed seats and capabilities at run time. The SDL Wayland input system was accreted over time, and the assumption that only one seat will ever exist resulted in state and related objects not always being tied to their most appropriate owner in a multi-seat scenario, so refactoring was required to manage several bits of state per-seat, instead of per-window or globally. As Wayland keyboards can have per-seat layouts, fast keymap switching is required when multiplexing input from multiple seats to the global SDL keyboard device. A parameter was added to the keymap creation function to specify if the keymap lifetime should be externally managed to facilitate keymap reuse, and some layout info was moved from the global keyboard state to the keymap state to avoid unnecessarily redetermining it whenever a reused keymap is bound. This reduces the overhead of switching keymaps to setting a single pointer. Multiple seats also means that multiple windows can have keyboard and/or mouse focus at the same time on some compositors, but this is not currently a well-handled case in SDL, and will require more work to support, if necessary.
Kontrabant
force-pushed
the
wl_multi_seat_final
branch
from
77a6133 to
d620f1a
Compare
|
I've been testing and going over this for the last couple of days, and aside from one minor bug (missed NULL check) and a couple of tweaks, I haven't seen any regressions, or other major work needed. This should be good-to-go, and I'll be standing by to quickly address any missed bugs or regressions that shake-out. |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wayland environments can expose more than one seat for multiple collections of input devices, which can include multiple, simultaneously active, desktop pointers and keyboards with independent layouts. The Wayland input backend previously presumed that only one seat could exist, which caused broken behavior if the compositor exposed more than one, which is possible on wlroots based compositors such as Sway. This introduces support for handling multiple seats, including proper handling of dynamically adding and removing seats and capabilities at run time.
The SDL Wayland input system was accreted over time, and the assumption that only one seat will ever exist resulted in state and related objects not always being tied to their most appropriate owner in a multi-seat scenario, so refactoring was required to manage several bits of state per-seat instead of per-window or globally.
As Wayland keyboards can have per-seat layouts, fast keymap switching is required when multiplexing input from multiple seats to the global SDL keyboard device. A parameter was added to the keymap creation function to specify if the keymap lifetime should be externally managed to facilitte reuse, and some layout info was moved from the global keyboard state to the keymap state to avoid unnecessarily redetermining it whenever a reused keymap is subsequently bound. This reduces the overhead of switching keymaps to setting a single pointer.
This was tested in Sway with two mouse/keyboard sets split across two seats, including each keyboard having a different language layout. testmanymouse and Woodeneye-008 are now usable on Wayland with the appropriate input configuration, and testime can accept input from both keyboards at once, with each delivering the appropriate layout-specific text.
Multi-seat in Wayland can even support multiple windows having simultaneous mouse/keyboard focus, however, the SDL core assumes that only one of the app's windows at a time can have focus, so proper support for this would require changes to the video/input core, which can come later.
@icculus, if you have a moment, could you test the tablet changes in this branch? The changes on the tablet side are minimal, but I don't have the hardware to check it properly myself.