Bug 75892

Summary:	XLookupString vs xkb_keysym_to_utf8
Product:	libxkbcommon	Reporter:	Gatis Paeglis <gatis.paeglis>
Component:	General	Assignee:	Daniel Stone <daniel>
Status:	RESOLVED FIXED	QA Contact:	Ran Benita <ran234>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	0001-Add-utf8.-c-h-for-common-UTF-8-util-functions.patch 0002-state-add-xkb_state_key_get_-utf8-utf32-API-function.patch 0003-state-apply-control-transformation-on-utf8-utf32-key.patch

Description Gatis Paeglis 2014-03-07 15:32:26 UTC

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

Comment 1 Daniel Stone 2014-03-13 15:57:30 UTC

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.

Comment 2 Ran Benita 2014-03-22 18:23:54 UTC

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.

Comment 3 Ran Benita 2014-03-22 18:24:24 UTC

Created attachment 96209 [details] [review]
0001-Add-utf8.-c-h-for-common-UTF-8-util-functions.patch

Comment 4 Ran Benita 2014-03-22 18:24:47 UTC

Created attachment 96210 [details] [review]
0002-state-add-xkb_state_key_get_-utf8-utf32-API-function.patch

Comment 5 Ran Benita 2014-03-22 18:25:12 UTC

Created attachment 96211 [details] [review]
0003-state-apply-control-transformation-on-utf8-utf32-key.patch

Comment 6 Gatis Paeglis 2014-03-24 11:44:49 UTC

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. :)

Comment 7 Ran Benita 2014-03-27 17:44:46 UTC

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.