Remapped keys in X11 have their original value in druid #1633
Comments
luleyleo
added
bug
|
interesting. I'm not sure exactly what the x11 backend is doing for key handling; if you wanted to investigate this a bit further you might check to see what that |
|
we're currently using a hard-coded mapping (see |
|
@jneem xkbcommon is the library that does the necessary magic. It is written in C and does some quite non-trivial stuff. Looking at the "X11 stuff" that gvim does ( x11rb provides access to these requests and even the full structure of the reply. I never really looked deeply into xkb. It is the only X11 extension that I know that was designed by a consortium and is documented in a PDF with 168 pages: https://www.x.org/releases/current/doc/kbproto/xkbproto.pdf
Don't go that way. Well, actually, if you want, it may be possible and give you 80% keyboard support. xcb-keysyms does not even have much code and can easily be rustified. The downside is that it uses core X11 and not the XKB extension. That means that it more or less will work, but some special cases still will not work. I am not even sure which ones. Keyboard layouts are complicated.
Huh. The source code for that looks almost identical to Anyway, just from the API this cannot work for everything: I have a German keyboard layout (
xkbcommon has some state struct. You feed it with key codes and you might get some utf8 out or not. This API properly supports dead keys like my |
|
Here is what I replied to the last person looking at xcb-keysyms: psychon/x11rb#316 (comment) That comment looks into what this library is actually doing and is a "half tutorial" for coding that in Rust. However, I still think that xcb-keysyms is the wrong thing to go to. I think it would actually work for this issue since this is just about "caps lock is now escape", but it cannot properly support dead keys. And re-writing xkbcommon in Rust is outside of the scope of x11rb. The library is way more than just a thin wrapper around the X11 protocol (well, "thin", the X11 resource stuff really is not thin, but was in scope for x11rb...). That means you need some ffi-based Rust wrapper around the C library. |
I would expect the resolution of ^+a to â to happen at a higher level in the API; either in a specific code-path for handling deadkeys or in a full-blown IME, although I don't know anything about how this works in x11. |
|
The proposed wayland backend from #1498 also uses xkbcommon (in fact, AFAIK all wayland clients use xkbcommon; I think xkbcommon was simply created for use with wayland): https://github.com/linebender/druid/pull/1498/files#diff-8fa9b22fdd2f520e900673156a5830f8bda7e68cb9a62eb8d6a1476626924176R200 Perhaps @derekdreery knows a bit more about this xkbcommon stuff. (There should not be much difference between xkbcommon for wayland and x11, but there are some special x11-specific functions in xkbcommon-x11: https://xkbcommon.org/doc/current/group__x11.html) |
|
I'm not an expert, but from reading when working on the wayland backend, it seemed that xkbcommon was the way to resolve keys correctly. Note that the wayland backend key mapping isn't fully working yet, and I may learn more as I work on it. |
|
So I guess the good news is that whatever we do for x11 can be shared with wayland. It also seems like there are rust bindings to xkbcommon. They don't appear to be very actively maintained, though (it's the same maintainer as the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I remap my Caps Lock key to Escape using the following file in
/etc/X11/xorg.conf.d/00-keyboard.conf:When I press the escape key in my druid application, using the X11 backend, I receive a
KeyEventwhere bothkeyandcodeare mapped toCapsLock.The remapping works in every other application installed in my system, so this was pretty surprising behaviour.
The text was updated successfully, but these errors were encountered: