Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All other keys are masked while shotcut key is held under X11 #41

Open
anthonybilinski opened this issue Jul 6, 2020 · 3 comments
Open

Comments

@anthonybilinski
Copy link

I'm using Qt 5.12.8, on Ubuntu 20.04 under X.

Using the HotkeyTest app, if I register a hotkey, e.g. a I understand that that key will be consumed, but it seems that all other keys are consumed as well between when a is pressed and when it's released.

Repro steps:

  1. Bind a as Hotkey 1 in the test app, activate the hotkey
  2. In another windows, hold a, then type sdf
  3. Release a, then type g.

Observed behaviour:

  1. QHotkey::activated is fired.
  2. QHotkey::released is fired.
  3. g is entered into the underlying application.

Can this be avoided? This seems quite intrusive for e.g. games where a user might want to hold a push to talk button and keep entering other keys at the same time.

I've done a bit of investigation and

  1. If I immediately return false in QHotkeyPrivateX11::nativeEventFilter, the behaviour doesn't change. Returning false there looks correct to avoid eating the key per Qt docs: https://doc.qt.io/qt-5/qabstractnativeeventfilter.html#nativeEventFilter

    In your reimplementation of this function, if you want to filter the message out, i.e. stop it being handled further, return true; otherwise return false.

  2. XGrabKey's registration uses True, which from docs

    Specifies a Boolean value that indicates whether the keyboard events are to be reported as usual.

So I don't understand why the keys are being masked at all. Based on docs it seems like not even the shortcut key should be masked? But I'm more interested if still getting the non-shortcut keys while the shortcut is held.

@Skycoder42
Copy link
Owner

This is definitly a valid issue, but at this point I have no clue why this happens. It's probably simply how X handles key events - but further investigation would be needed to figure this one out. I currently don't have much freetime to work on such deep problems, so if you want to, feel free to further investigate this.

My first ideas on what is happening:

  • X is just eating the keys, nothing we can do
  • while being pressed, all key events are redirected to the grabbing application by design - this would need more event logging prove
  • It's some kind of misconfiguration and can be fixed by using the APIs differently

@anthonybilinski
Copy link
Author

It looks like it is just how XGrabKey behaves: https://stackoverflow.com/questions/15270420/why-xgrabkey-generates-extra-focus-out-and-focus-in-events

XRecord seems to offer an alternative that doesn't grab focus, but it then reports all keys and has you filter them rather than you registering a hotkey with it. https://www.x.org/releases/X11R7.6/doc/libXtst/recordlib.html#enable_context

For example, this is done in libuiohook here: https://github.com/kwhat/libuiohook/blob/1.1/src/x11/input_hook.c#L857

Looks like it would be a pretty major change to resolve, unfortunately.

@Skycoder42
Copy link
Owner

Thats unfortunate. I will mark this issue as out of scope for now, but if someone wants to give it a try, feel free to do so. However, I would prefer to not add any extra non standard libraries or testing libraries to the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants