Skip to content

Conversation

@faklapant23
Copy link

@faklapant23
Copy link
Author

Associated pull request:
QubesOS/qubes-core-admin-client#388

@faklapant23
Copy link
Author

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:
#115

@marmarek
Copy link
Member

marmarek commented Oct 9, 2025

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...

…n locker exit. When the sceeen locker is triggered while a window is grabbed, then the grabbed window is losing the focus and the focus is set to return to None after the screen locker exit.
@faklapant23
Copy link
Author

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.

Example title name for the garbbed window, where Ctrl+Control_R is the key sequence to grab/ungrab a keyboard:
Keyboard grabbed Ctrl+Control_R [disp1234] Terminal - user@disp1234:~
@faklapant23
Copy link
Author

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.

@faklapant23
Copy link
Author

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.

@faklapant23 faklapant23 marked this pull request as draft October 16, 2025 00:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow temporary VM keyboard capture with user consent

2 participants