External keyboard, "Right" keyboard binding breaks
gskerry opened this issue · comments
Hello,
Couldn't seem to find another issue with same behavior.
Have quicktile installed with default configurations.
All key bindings work on the built-in laptop keyboard. All bindings also work on an external bluetooth keyboard, except "right"
Cannot determine why only 1 binding would fail on the external keyboard, or how best to troubleshoot.
Any help appreciated!
Linux Mint 20.1
HP 15t
Logitech K400r
(On laptop the actual key combo is Ctrl + Alt + number-pad #)
(On logitech the combo is Ctrl + Fn + Alt + number-row#)
A twist...
Ctrl + Alt (right-hand side of space bar) (+Fn) + 6 works on external keyboard
Same combo using Ctrl + Alt on lefthand side of space bar does not.
Also,
The order of pressing the keys has to actually be Alt + Ctrl (+Fn) + 6
If Ctrl is pressed before Alt, the binding does not work.
This same constraint actually manifests on built-in keyboard as well
Ctrl + Alt + numpad# does not work
Alt + Ctrl + numpad# does work
A bit baffled. Thanks in advance.
Please copy-paste the KeyPress and KeyRelease blocks emitted in a terminal by xev when you press the working and non-working variants of the same shortcut.
Hello,
Example-1:
- External monitor
- K400r keyboard
- Alt + Fn + Ctrl + 1 (Lower Left)
- (Working)
KeyPress event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 58806703, (440,-118), root:(1400,406),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 58806866, (440,-118), root:(1400,406),
state 0x8, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
...
KeyRelease event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 58807993, (1400,-118), root:(1400,406),
state 0xc, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 58808001, (1400,-118), root:(1400,406),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
(Full xev output with other event emitters attached).
Example-2:
- External monitor
- K400r keyboard
- Alt + Fn + Ctrl + 6 (Right)
- (Not working)
KeyPress event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59240940, (168,-11), root:(598,513),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59241698, (168,-11), root:(598,513),
state 0x8, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59245516, (168,-11), root:(598,513),
state 0xc, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 39, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59245532, (168,-11), root:(598,513),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Example-3:
- External monitor
- K400r keyboard
- Ctrl + Alt + Fn + 1 (Lower Left)
- (Not working)
KeyPress event, serial 38, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59587314, (20,-18), root:(881,436),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x8200001,
root 0x7a4, subw 0x0, time 59589415, (20,-18), root:(881,436),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
(Full xev output with other event emitters attached).
Example 2 is the 1-off anomaly specific to the right-side binding. Have not found a workaround.
Example 3 is more an FYI anomaly about the key order. Using "Alt + Ctrl + Fn + #" is a sufficient workaround in my case.
Sorry for the delayed response. I'm in the middle of reinstalling my PC.
Could you quit QuickTile and then post xev dumps that include the output from the KeyPress events for the 1 and 6 keys themselves? All I'm seeing are the events for pressing and releasing the modifiers.
(If you still don't get KeyPress events in xev for the one that doesn't work after quitting QuickTile, then something is swallowing them before QuickTile can see them. Otherwise, I'd like to look for differences in what QuickTile sees.)
Hello,
Sorry about falling off this. Here are xev events for just 1 and 6 keys
KeyPress event, serial 38, synthetic NO, window 0x6a00001,
root 0x7ba, subw 0x0, time 590452, (161,-9), root:(1250,82),
state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XmbLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x6a00001,
root 0x7ba, subw 0x0, time 590579, (161,-9), root:(1250,82),
state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
XLookupString gives 1 bytes: (31) "1"
XFilterEvent returns: False
KeyPress event, serial 38, synthetic NO, window 0x6a00001,
root 0x7ba, subw 0x0, time 592467, (161,-9), root:(1250,82),
state 0x0, keycode 15 (keysym 0x36, 6), same_screen YES,
XLookupString gives 1 bytes: (36) "6"
XmbLookupString gives 1 bytes: (36) "6"
XFilterEvent returns: False
KeyRelease event, serial 38, synthetic NO, window 0x6a00001,
root 0x7ba, subw 0x0, time 592581, (161,-9), root:(1250,82),
state 0x0, keycode 15 (keysym 0x36, 6), same_screen YES,
XLookupString gives 1 bytes: (36) "6"
XFilterEvent returns: False
Many thanks.
Sorry for the delayed response. Busy few days.
I should have been more clear that I wanted you to quit QuickTile and then try pressing the key combos it doesn't recognize under xev, to try to generate a log like your old one, but with those KeyPress and KeyRelease events included.
(i.e. Not just the pressing those keys in isolation.)
If you still don't receive those events through xev with QuickTile stopped, then it's out-of-scope because something else is eating them before QuickTile can see them.
If you do get them, I need to see what things like the state field look like *when you press them as part of the key combo. The intent being to get a good picture of what QuickTile is seeing and not reacting to properly.
Understood. There aren't keypress events for the number (6), or for the function key.
However, the same is true for KP3 (neither number 3 or fn keypress events show up), but it is working.
Agree with the logic, but don't know what to make of the fact that neither log the events, but one still works.
I'll try to take a look at the logs tomorrow, but what I can say is that, if neither log the events through xev when it's the active window but one still works, that suggests that they're getting intercepted through different means.
(QuickTile uses an API that's near the top of the pecking order, but not at the very top because going any higher requires receiving the entire stream of input events and then manually filtering it.)
...well, that and the API QuickTile uses (XGrabKey) is "first come, first served" so it'll also lose out to anything else that gets started earlier.
Got it. Will gladly disable or de-prioritize anything jumping in front of it.
The problem is that it could technically be anything that's running which is responsible for the problem.
I don't have time to try to replicate your desktop in a VM to try to help track down the culprit, and I'm unaware of any diagnostic tool which would easily indicate where the keypress event is ending up.
Given that your experience would suggest two different applications grabbing those keys two different ways, the best suggestion I can make is to try killing running processes one-by-one and using xev to see if one or both of them suddenly becomes visible after doing so.
(It may not be possible to conclusively identify both that way, because it may be that one of them is being grabbed by the same process that holds your X session open, but, if you rule out all the others, that at least hints where to look in the control panel for a fix.)
If you were on KDE, I'd suggest seeing what KDE's "disable/enable global hotkeys" button does, since that'd let you narrow it down to whether you need to look in the control panel for kglobalaccel for a solution.
Did you ever figure out anything else about this?
Given that you say it only appear on your Bluetooth keyboard but nor your internal one, I don't think it'd be productive for me to attempt to replicate it, just to try to prove that this bug is something I'm capable of fixing on my end.