wayland: Add multi-seat support #12626
Conversation
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. |
|
Ive been running a multiseat setup with https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2230 |
|
IIUC, "seat" in Wayland and "seat" in systemd-logind are different concepts. A Wayland compositor uses a logind seat, and it may split the devices in the logind seat into multiple Wayland seats. There's some information about Wayland seats: https://wayland-book.com/seat.html |
|
Aren't they made for the same purpose though? To split the user input and output into multiple seats. Latter one requiring less assumptions from client's perspective. The only limitation that I currently see with logind seats is that each seat requires a GPU to function. While each GPU port is marked as master, only the GPU itself can be made master. I'd love to see some efforts to make this process cheaper and letting the compositors take over individual GPU ports and using their "parent" GPU for rendering. |
Me too, but I don't know if DRM API can work in this way. That should be off-topic for this PR. |
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.