Add VM keyboard capture feature
Fixes: https://github.com/QubesOS/qubes-issues/issues/9785
Associated pull request: https://github.com/QubesOS/qubes-core-admin-client/pull/388
The XGrabKeyboard is used here to grab the keyboard and the downside is that some shortcuts that are handled on a low level using input device directly (keyboard layout change, Ctrl+Alt+Fx, etc) are still passed to dom0. I think it should be possible to grab all the keyboard events using XIGrabDevice on Virtual core keyboard with deviceid=3 from xinput2. But I think it's better to use it when the gui-daemon will be changed to use xinput: https://github.com/QubesOS/qubes-gui-daemon/pull/115
It's a bit late to add this into R4.3... but since it's relatively simple, maybe we can make an exception. But then, IMO such feature should be disabled by default. And when active, there must be visual indicator when the keyboard is grabbed. Maybe something added to window title(s) of that qube? With information how to disable it. This will interfere with alt-tab or similar, but that's kinda the point of it. You added automatic disabling it on focus out, which is good. This should handle the case of some prompt showing up (like for file copy). Or some password prompt (wifi?). This needs to be tested.
But another potentially problematic case is screenlocker. This must not interfere with it. I haven't checked, but AFAIR normally keyboard grab does prevent locking the screen...
But then, IMO such feature should be disabled by default.
Fixed.
And when active, there must be visual indicator when the keyboard is grabbed. Maybe something added to window title(s) of that qube? With information how to disable it.
Do you think something like this should be good?
Keyboard captured, release w/ Ctrl+Control_R [disp1234] Terminal - user@disp1234:~
Looks too long for me though. But something shorter like this:
KBRD LOCK Ctrl+Control_R [disp1234] Terminal - user@disp1234:~
Could be hard to understand. I'll think some more about how to make the indication better.
You added automatic disabling it on focus out, which is good. This should handle the case of some prompt showing up (like for file copy). Or some password prompt (wifi?). This needs to be tested.
Tested both file copy and window spawning from a qube - both work fine: keyboard is ungrabbed and the focus is in the new window.
But another potentially problematic case is screenlocker. This must not interfere with it. I haven't checked, but AFAIR normally keyboard grab does prevent locking the screen...
Tested this and it works fine as well, the FocusOut event is sent before the screen locker tries to grab the keyboard (maybe it's sent when the screen locker window is created). There was a problem that when the screen locker is triggered while a window is grabbed, then the grabbed window was losing the focus and the focus is set to return to None after the screen locker exit. I had to use a hack to focus back on the previously grabbed window after the screen locker exit.
Keyboard grab indication works fine for XFCE. I'll work on it for other WMs (i3/awesomewm). And I'll also need to test this feature in other WMs.
The screen locker in KDE is not generating a FocusOut event when it's trying to lock the screen. Maybe it checks if the keyboard is grabbed before creating a new screen lock window. It seems that I'll have to use the XIGrabDevice from xinput2 instead of the XGrabKeyboard.