While looking at a bugreport in Qt5 [1] I noticed that there is a difference between what is returned by XLookupString VS xkb_keysym_to_utf8. Docs of XLookupString [2] states that: "the KeySym is mapped, if possible, to an ISO Latin-1 character or (if the Control modifier is on) to an ASCII control character, and that character is stored in the buffer." It seems that xkb_keysym_to_utf8 doesn't implement this behaviour. [1] https://bugreports.qt-project.org/browse/QTBUG-36281 [2] http://tronche.com/gui/x/xlib/utilities/XLookupString.html
xkb_keysym_to_utf8 is an analogue of XLookupKeysym, not of XLookupString. The latter takes an event, calculates the appropriate keysym (taking status of, e.g., Shift into account), and generates a string from that. The correct fix, while we lack API for this, would be to calculate the unconsumed modifiers for the event, and use them to transform the returned keysym.
Sorry for the delay, this turned out to be quite annoying, so I procrastinated :) This bug is because we don't implement this part of the spec: http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Control_Modifier Since it's in the spec, and users apparently expect it, we need support it somehow. Since I definitely don't want to leave it to each user to implement, I think we should implement it internally. The problem is that our current keysym-to-string functions have no idea what the modifier state is, they operate solely on the keysym. So we must add some new API for this. This is inconvenient but I don't see a way to avoid it. New API also has the advantage that users have to "opt-in" to the new behavior, so they can see what changed if something breaks for them with the Control transformation. I'm attaching my proposed changes. The first patch is just some UTF-8 utils I need for the second patch. The second patch adds the new API, see the commit message and doxygen docs for the details. The third patch implements the Control transformation in a way compatible with Xlib (which is pretty lame and US-centric...). They are also here: https://github.com/bluetech/libxkbcommon/commits/bug-75892 I'll be happy to hear any comments, then I'll push them in a few days.
Created attachment 96209 [details] [review] 0001-Add-utf8.-c-h-for-common-UTF-8-util-functions.patch
Created attachment 96210 [details] [review] 0002-state-add-xkb_state_key_get_-utf8-utf32-API-function.patch
Created attachment 96211 [details] [review] 0003-state-apply-control-transformation-on-utf8-utf32-key.patch
Tested the patches, the new xkb_state_key_get_utf8 function works as expected. Fixes the described issue and doesn't seem to introduce any regressions. :)
Thanks for testing Gatis. I've pushed the patches, 0.4.1 release to follow soon.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.