#3079 XkbKeycodeToKeysym fails sometimes

[Brian Griffin]

The XkbKeycodeToKeysym call cannot always be used if the X server does not support it. A run time check is necessary before using this call. If the X server does not support the extension, this call will return NoSymbol for some keys, depending on the particular server and keyboard setup.

I have seen this behavior on different configurations, but I have not been able to determine exactly what's different about the setup. However, in all cases, absence of the extension is true (test `xdpyinfo | grep XKEYBOARD` || echo bad) when the call fails. Unfortunately, the inverse is not true, i.e., the xkb call does work in some cases where the extension is not present.

I'm currently working on a patch that will verify the existence of the extension first, when the Display is opened, and then use the appropriate (old or new) call as required. If you think about it, this makes sense since the server is not necessarily on the build/installation machine, so this has to be a runtime decision, not a compile time decision.

Please stay tuned...

[Stuart Cassoff]

I made the XkbKeycodeToKeysym change simply to avoid compiler warnings about XKeycodeToKeysym being deprecated but it's been nothing but trouble. Sorry about that. I'm starting to wonder if it was the right thing to do.

[Brian Griffin]

I think it's the right thing to do, but maybe premature and incomplete. I have it working currently, but I noticed that under the same X server, Tk reports different keycodes for the same key events than it did before. This only matters if your tk scripts actually cares about keycodes. That, by definition, is not going to be portable, but it should be noted that there is a change. The funny thing is that this didn't happen until after I correctly initialized tk to use xkb.

[Brian Griffin]

It looks like xkb has and adverse impact on event generate. When using the xkb extension, a number of event tk tests fail. The crux of the problem is illustrated here:

% bind . <Key> {puts "%K %k %A %t"}
% after 5000 event generate . <Key-H>
after#1
>> h 12 h 0
% after 5000 event generate . <Key-H> -state 1
after#2
>> H 12 H 0

For any key that requires a modifier, the key symbol is not sufficient, the state must also be set. I haven't investigated why this is. This might be isolated in [event generate] only. Real events from the keyboard seem to work fine.

I've added the current patch that I'm testing to this bug. This [event generate] issue has to be resolve though before this patch should be considered.

[Brian Griffin]

Ignore my last post. There was a bug in my changes. I'll post an updated patch once I'm done testing.

[Brian Griffin]

Patch to 8.5.13 to fix use of XkbKeycodeToKeysym usage

[Brian Griffin]

The patch in the attached file solves the problem, and all tk event tests pass now.

[Brian Griffin]

I should have noted that this patch does not avoid the original issue of the old API (XKeycodeToKeysym) being deprecated. The fact is this is really a silly warning for a compiler to make because it assumes that X is a closed system when in fact the server an application attaches to can be of any vintage, any OS, anywhere, which makes it next to impossible to deprecate anything in the X library. Deprecation is not a compile time choice, it can only be a runtime choice.
IMHO.

[Don Porter]

Is this ready to go in now so it can be
fixed in 8.5.14?

[Don Porter]

Runtime Xkb checks merged in with
compile time Xkb checks and committed
to core-8-5-branch. Please test.

[Don Porter]

Fix merged to trunk too.