request: add RedirectKey action about libxkbcommon

[nariox]

Hi, I'm in the same situation. My chromebook doesn't have Home/End/etc. Once Wayland becomes a little bit more mature, I'd like to continue to use the same solution.

I believe this will help many users as many small laptops/tablet keyboards/etc don't have a full keyboard, but rather a keyboard with a subset of keys.

[dhead666]

@pedronariyoshi In fact Wayland is pretty mature, Gnome Wayland session works perfectly on my C720 and it much snappier than X (though everything still run through xwayland), if the touchpad's tap-to-click actions and extra mouse buttons (back, next) weren't missing from Gnome's Wayland session then I would be moving to it today (and I'll bet these will be fixed two months from now with Gnome 3.16).

[ctappy]

My Chromebook as well would be missing those feature because it has a different type of keyboard.

Thank you

[bluetech]

@dhead666 Thanks for opening a bug.

First to explain why RedirectKey doesn't work currently: in general, we try to support all of the features in Xkb, unless

1. Nobody ever uses them (e.g. overlays, certain key behaviors) and no one complains.
2. They haven't aged well and are not missed (geometry).
3. They present some technical difficulty to implement.

Unfortunately RedirectKey is the 3rd... It is inherently a server/compositor-side feature; to quote the Xkb spec for SA_RedirectKey:

Key press causes a key press event for the key specified by newKey instead of for the actual key. The state reported in this event reports of the current effective modifiers changed as follow: Any real modifiers specified in modsMask are set to corresponding values from mods . Any real modifiers bound to the virtual modifiers specified in vmodsMask are either set or cleared, depending on the corresponding value in vmods . If the real and virtual modifier definitions specify conflicting values for a single modifier, the real modifier definition has priority.

Key release causes a key release event for the key specified by newKey ; the state field for this event consists of the effective keyboard modifiers at the time of the release, changed as described above.

The SA_RedirectKey action normally redirects to another key on the same device as the key or button which caused the event, unless that device does not belong to the input extension KEYCLASS, in which case this action causes an event on the core keyboard device.

Basically it mangles the key events sent to the client. However libxkbcommon is a generic library and doesn't act as a midlayer or deal with events directly in any way (as opposed to the xkb stuff in xserver and xlib), so we can't just implement actions like these in the library. These are the same reasons we don't currently handle some accessibility features which are specified in xkb (like mousekeys and others, which need to synthesize, alter and suppress events, timers and what not).

In the Wayland case in particular, if such features are desirable and the proper place for their configuration is in the xkb keymap, then we will need to expose some API to the compositor (hopefully not involving callbacks...).

So there's a larger architectural consideration here, closely related to keyboard accessibility. I'd suggest you bring this up with the Wayland devs (wayland-devel mailing list) - if the data from the keymaps is eventually needed we can certainly expose it.

[dhead666]

then we will need to expose some API to the compositor (hopefully not involving callbacks...).

Do you mean that some changes are also needed to be made in each compositor? (Weston, Gnome ...)

These are the same reasons we don't currently handle some accessibility features

Are these important features? if so then how these features supposed to be implemented? via the compositor? or maybe this is something that Wayland is actually lacking?

I'll bring it up in the wayland-devel mailing list but I'm not sure I really understand Wayland inner workings (I'm pretty sure I don't).

Also as a user (and not a developer) it sounds to me like a solution that's too complex and might not be worth pursuing, at least if it's only needed for my specific use case.
I might just educate myself about input devices, maybe it's possible to bind the input to a custom service that will modify events and then pass them to a virtual input device that will be visible to Wayland.

[bluetech]

Well if you are content in doing the redirection in another layer, that's possible in linux at least. See here: https://gist.github.com/bluetech/c5839c78278200c668e0 (just the needed syscalls; of course if you want to actually use this you'd need to work on the script a bit).

[bluetech]

I just realized dumping a C file on a user might not be very helpful to him... If you need help with it let me know.

Also note that it redirects the key on the device for the entire system: also on the tty's, for other users, etc.

[dhead666]

@bluetech thanks, that is very helpful as I'm inexperience a bit in coding but I do want to improve my skills and this is a great example.

My main issue is mapping key press combinations (e.g Alt+Shift+Up) so I believe that I will need to read the status of the button(s) (pressed, released) which I don't believe possible with EVIOCGKEYCODE.

Anyway, I can continue this discussion via email so I won't spam every subscribed developer.

Also, ATM I'm less concern in having the RedirectKey action in libxkbcommon because it seem like it should be easier to implement what I need by manipulating the events directly from the input device, so you're welcome to close this issue and also #19 (as it only effect keys that I mapped to actions).

[nariox]

@dhead I don't know about other subscribers, but I would like to see the
development of your conversations. I wouldn't mind it at all.

Pedro Nariyoshi

On Wed, Feb 4, 2015 at 9:10 AM, dhead666 [email protected] wrote:

@bluetech https://github.com/bluetech thanks, that is very helpful as
I'm inexperience a bit in coding but I do want to improve my skills and
this is a great example.

My main issue is mapping key press combinations (e.g Alt+Shift+Up) so I
believe that I will need to read the status of the button(s) (pressed,
released) which I don't believe possible with EVIOCGKEYCODE.

Anyway, I can continue this discussion via email so I won't spam every
subscribed developer.

Also, ATM I'm less concern in having the RedirectKey action in
libxkbcommon because it seem like it should be easier to implement what I
need by manipulating the events directly from the input device, so you're
welcome to close this issue and also #19
#19 (as it only effect
keys that I mapped to actions).

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[stev47]

Doesn't binding the appropriate keysyms to higher levels work for Home/End/PgUp/PgDown, i.e. without any action/redirect stuff? the de(neo) layout is doing just that and it works fine in X11.

[bluetech]

@stev47 it seems that in the patch @dhead666 linked to, he already tried that (see the keysyms in the 3rd level).

@dhead666 why indeed do you need to need to actually redirect the key at all, are the keysyms not sufficient?

Perhaps some programs look at the keycode directly, instead of the keysym (you mentioned firefox, chrome, libreoffice)?

[dhead666]

@bluetech you are correct, the RedirectKey needed for those three apps.

I didn't investigate yet a proper solution suitable for my needs (I've got lots to learn, just started reading The Linux Programming Interface) but I don't see any reason why this issue shouldn't be closed as @bluetech already stated about the RedirectKey that

They present some technical difficulty to implement.

[bluetech]

Indeed, we are not likely to implement RedirectKey, so I'll close the issue.

Regarding the reason you need RedirectKey: I just tested it, and firefox, libreoffice do use the keysym (it would be very wrong to use the keycode); the real reason your patch (without the RedirectKey) does not work with these applications, I am pretty sure, is the extra modifiers Alt+Shift. I think these applications (incorrectly!) regard the key press as "Alt+Shift+Prior", and so the shortcut for just "Prior" is not activated. Evince (gtk3), for example, gets this right (it takes into account "consumed modifiers"). So what the RedirectKey really achieves for you is actually the clearmods=Alt+Shift part, and not the redirection part. Interesting, though unfortunate...

Have fun with TLPI!

[cxandru]

Indeed, we are not likely to implement RedirectKey, so I'll close the issue.

Regarding the reason you need RedirectKey: I just tested it, and firefox, libreoffice do use the keysym (it would be very wrong to use the keycode); the real reason your patch (without the RedirectKey) does not work with these applications, I am pretty sure, is the extra modifiers Alt+Shift. I think these applications (incorrectly!) regard the key press as "Alt+Shift+Prior", and so the shortcut for just "Prior" is not activated. Evince (gtk3), for example, gets this right (it takes into account "consumed modifiers"). So what the RedirectKey really achieves for you is actually the clearmods=Alt+Shift part, and not the redirection part. Interesting, though unfortunate...

Have fun with TLPI!

Sadly there are still many applications that need "clearmods" to work. E.g. Using arrow keys while alt-tabbing on xfce, or using arrow /editing keys produced by modifiers (via the neo2 layout) inisabelle jedit. The problem is that we cannot force all applications to handle keypresses correctly, especially not legacy ones, so I feel that treating this as a wontfix leaves users stranded with no alternative. #145 is an instance of yet another user needing this feature.

[wismill]

@cxandru as Ran wrote above, the complete support of RedirectKey will not happen, but I would like to re-assess the support of modifiers and clearModifiers options while ignoring the keycode one. Could you add your use case to #145 with the relevant parts of your xkb files?