Input holding: Implement libinput evdev device holding on SDL and Wayland backends.

[davidawesome02-backup]

Added command line options to allow users to disable default window input processing, and enable mouse and keyboard processing via evdev paths. When using disabled mouse on window, and using passed through mouse, gamescope mouse compositing is enabled, to allow users to see the mouse pointer.

Intended to allow client isolation, and what is essentially a continuation of multiseating in a subcompositor rather than as a standalone compositor. Doing this separation and device holding in a subcompositor allows for actions including single GPU and monitor gaming with multiple people.

As stated in my original issue #1771 , this would essentially be a continuation and introduction into the wayland space of a process that was able to be used previously in the xephyr project, back when it had a evdev / libinput backend.

These changes currently only work on the X11 backend (SDL) and Wayland backend, with the libinput changes allowing VR to specify devices to hold, although this is untested and seems to be unhelpful in that area.

These changes may also help in the development of split screen gaming on linux in a more complete fashion, in projects similar to and including partydeck

Feel free to ask for any changes that may be required to merge, this is my first contribution to this project, or really any outside of personal ones, so let me know if any changes are required.

--libinput-hold-dev is used by passing --libinput-hold-dev /dev/input/by-id/USB-...,/dev/input/by-id/... or in multiple arguments, while the options --backend-disable-keyboard and --backend-disable-mouse are passed with no arguments, and simply disable the backend's keyboard and mouse processors.

[wunnr]

The software cursor seems to not render in certain instances. PrismLauncher for Minecraft does show a cursor in the launcher, but not in-game. Left 4 Dead 2 does properly display the cursor. Will have to test with more games/applications, but my initial guess is that it may have something to do with the game's rendering API? (Minecraft is OpenGL while L4D2 was run in Vulkan with -gamepadui)

[wunnr]

Also, when starting through terminal, if you specify --libinput-hold-dev with the specific keyboard that hit Enter to run the command, the Enter key gets stuck until the gamescope window that is holding it is closed; this causes the terminal to spam the Enter command. This may be fixed by putting a small delay before grabbing keyboards?

[davidawesome02-backup]

Also, when starting through terminal, if you specify --libinput-hold-dev with the specific keyboard that hit Enter to run the command, the Enter key gets stuck until the gamescope window that is holding it is closed; this causes the terminal to spam the Enter command. This may be fixed by putting a small delay before grabbing keyboards?

Gamescope is generally assumed to be used from an automated sense, and adding a timeout would be difficult, as there is no way to know when the person releases the enter key, and thus is safe to grab. We could do some checks before we bind to it, but it may be over complicated for no real reason. Do you have any other ideas for it, because I don't think a timeout would work well for this part of the program, if we are doing cmdline testing for this, you can use a sleep 1s; gamescope or similar to avoid the issue, but I am not sure how to resolve it in a decent way without undue delay in the starting of gamescope.

[davidawesome02-backup]

Sorry, just realized when changing some typos I forgot to add the submodules to my gitignore. I force-pushed a change that removed the glm update that vscode did automatically (did it during push for some reason, so I didn't catch it).

[xamionex]

Tested in games: Chivalry 2, Magicka 2, Terraria, Helldivers 2
Caused no issues and worked exactly as david described it would

Edit: Holding a mouse in prismlauncher doesn't show any cursor but it does work upon specifying --backend-disable-mouse
Then it works perfectly as described

Edit 2:
I tested some more: Battlebit Remastered, Darkwood, Garry's Mod
with and without holding mouse/keyboard and --backend-disable-mouse and all the games I listed work without issue

[Wlnfr]

Tested with just minecraft(prismlauncher), works great, however, if gamescope is started with --expose-wayland, mouse jumps between middle, top middle, top left and middle left of the window, flickering the window slightly, and when right/left clicked, gamescope segfaults. The keyboard just doesn't work, segfaults when pressed. The reason for using that option is to get rid of flickering, as per this comment in #495. Just in case this information is useful for reproduction, I'm on NixOS 25.05, gamescope 3.16.17, Wayland Plasma 6.3.6, Kernel 6.12.48, Nvidia 580.65 proprietary
Edit: strikethrough text not related to this PR

[xamionex]

Tested with just minecraft(prismlauncher), works great, however, if gamescope is started with --expose-wayland, mouse jumps between middle, top middle, top left and middle left of the window, flickering the window slightly, and when right/left clicked, gamescope segfaults. The keyboard just doesn't work, segfaults when pressed. The reason for using that option is to get rid of flickering, as per this comment in #495. Just in case this information is useful for reproduction, I'm on NixOS 25.05, gamescope 3.16.17, Wayland Plasma 6.3.6, Kernel 6.12.48, Nvidia 580.65 proprietary

I believe this to be unrelated to input holding as it happens with gamescope without it

[Wlnfr]

I believe this to be unrelated to input holding as it happens with gamescope without it

Okay, sorry, it seems I have done too little testing with --expose-wayland before reporting here,as I was able to segfault it without input holding

[davidawesome02-backup]

Hey, happy to see more comments on this!

While it is not ready for merging currently in my testing branch, I have a few new changes I was wondering if I should add to this branch, mainly that being of toggling keyboard / mouse grab when a key is pressed. Currently, keyboard grabbing is done instantly on running gamescope (with this patch), but I was thinking of following the (somewhat) convention of the Win/Super+G Grab keybind to grab / ungrab devices.

Now, I am asking because I see it implemented in the SDL backend (just telling SDL to grab it) and being entirely faked in the WAYLAND backend, just changing the window title to (grabbed) <title> without actually doing anything? (source)

Also, to allow this to work, and to allow expansion, or possible implementation of other keybinds, I used a static std::bitset<KEY_MAX+1> held_keys; inside the backend... dose anyone know a better way, or is this how you guys would want it to be implemented?

Code I changed to add this, and another feature to my testing branch; would not be committed as is, just showing as to get opinions on these types changes: davidawesome02-backup@a9bd04c

@wunnr Would you be interested in this? I implemented it in my version of your project, and if I push this into this version up here, the default would change, requiring --grab to be issued along side the --libinput-hold-dev to instantly grab the device, unless anyone here believes that --libinput-hold-dev should imply --grab, and thus require a --no-grab option, but I think this is overly complex.

[Wlnfr]

Replying to #1897 (comment)

Unfortunately, I can't help you with the code, but I do believe Win/Super+G keybind will be nice to have. About --grab option, while I personally believe it should be implied, I would be fine with having to include it manually. And as long as it's documented(in --help) that it should be included as an option to automatically grab input devices, I don't see it being a problem. The --no-grab option, however, feels unnecessary for me, if --libinput-hold-dev would imply --grab.