You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gesture begin detected
Gesture information:
Fingers: 3
Type: PINCH
Direction: OUT
Gesture performed on app: UXTerm
Action configured for this gesture
Starting action
Gesture update detected (7%)
Gesture update detected (9%)
Gesture update detected (12%)
Gesture update detected (16%)
Gesture update detected (19%)
Gesture update detected (20%)
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 132 (XTEST)
Minor opcode of failed request: 2 (X_XTestFakeInput)
Value in failed request: 0x0
Serial number of failed request: 24
Current serial number in output stream: 26
Cause
The problem does not seem to be that the keysym is unknown or unsupported, since that causes different behaviour (See #392). Instead, the problem seems to be that touchegg uses the XTestFakeInput request, which can fake keycodes, not keysyms. In this case, the keysym I'm using is not mapped (xmodmap -pk|grep ZoomIn), so I guess there's no way for touchegg to fake that keysym.
This is confirmed by running xmodmap -e 'keycode any=XF86ZoomIn' to map the symbol, after which the gesture works as expected.
Expected behavior
Rather than crashing, touchegg should probably show an error message (similar to #392). In this case, the error message should probably not be given at startup (or maybe only a warning), since the user might have some custom xmodmap in their startup script that could run after touchegg is started.
It might be even more friendly if touchegg would just take care of mapping any keys that have not been mapped to a free keycode, like the xmodmap command above.
Your environment
Version of Touchégg: 2.0.3
Operating System: Ubuntu
Desktop Environment: Gnome
The text was updated successfully, but these errors were encountered:
Note PR #394, which documents the limitation of only being able to use mapped keysyms (but this issue stays relevant for actually handling unmapped keysyms more elegantly, or even removing this limitation entirely).
Hm, looking again: Maybe it would be better to say "Unknown or unmapped key" to make it more explicit that the mapping might be problematic? Or even better, show a different message in both situations so people know they might have made a typo (or did not make a typo when the key is known but unmapped)?
I'd rather prefer to keep the message simple and understandable for not advanced users. Everyone knows what's a shortcut, but keysyms and keycodes are a little bit more advanced topics.
The natural step is to double check for typos or go to the docs, where you added detailed instructions of how to solve this problems 😄
Describe the bug
When using the following gesture, I get "X Error of failed request: BadValue"
The output is:
Cause
The problem does not seem to be that the keysym is unknown or unsupported, since that causes different behaviour (See #392). Instead, the problem seems to be that touchegg uses the XTestFakeInput request, which can fake keycodes, not keysyms. In this case, the keysym I'm using is not mapped (
xmodmap -pk|grep ZoomIn
), so I guess there's no way for touchegg to fake that keysym.This is confirmed by running
xmodmap -e 'keycode any=XF86ZoomIn'
to map the symbol, after which the gesture works as expected.Expected behavior
Rather than crashing, touchegg should probably show an error message (similar to #392). In this case, the error message should probably not be given at startup (or maybe only a warning), since the user might have some custom
xmodmap
in their startup script that could run after touchegg is started.It might be even more friendly if touchegg would just take care of mapping any keys that have not been mapped to a free keycode, like the
xmodmap
command above.Your environment
The text was updated successfully, but these errors were encountered: