Well, apparently UXXXX style key codes do work, but 0x100XXXX style key codes has stopped working. I wonder if this is intentional.

I still cannot find anything other than:

  2e7a18b6a617b9b4bfcea2d36f2bd2d7e0c4a3dd

which touches the conversions.

It seemed like there were a change which attempted to prevent the leak
which occur when dealing with the Uxxxx keysym conversions, but that
affects XKeysymToString(3) and remains.  (It is a *hard* problem.)

I just tried out this simple test which runs XStringToKeysym(3) on
argv[1] and printf(3)s the result.  I get correct results for every
type of input string I tried:

// Run XStringToKeysym(3) on argv[1] and return the result
#include <stdio.h>
#include <X11/Xlib.h>
int main (int argc, char *argv[]) {
    KeySym key;
    if (argc < 2) {
        fprintf (stderr, "Usage: %s <string>\n", argv[0]);
        return -1;
    }
    key = XStringToKeysym(argv[1]);
    printf ("%ld\t%#lx\n", key, key);
}


It only needs to link against -lX11.

If that works on the affected systems then, AFAICT, the bug can
not be in libX11.

Someone still needs to bisect.

On my Fedora 13 system with libX11-1.3.1 (which does *NOT* have the mentioned problem), these are the results:

[hedayat@localhost]~% ./a.out 10006f1  
0	0
[hedayat@localhost]~% ./a.out 0x10006f1
0	0
[hedayat@localhost]~% ./a.out U06f1      
16778993	0x10006f1
[hedayat@localhost]~% ./a.out Farsi_1    
16778993	0x10006f1


I get the same results in F14 with libX11-1.3.4 (which is affected by the mentioned bug). 
BTW, as I've mentioned in bug #30548, I've also replaced libX11-1.3.4 files in Fedora 14 with libraries from my Fedora 13 (libX11-1.3.1) and it still has the same problem. So, I also think that the problem is not in libX11 (or at least, it's been triggered by changes in somewhere else).

On Wed, Oct  6, 2010 at 05:37:14 -0700, bugzilla-daemon@freedesktop.org wrote:

> BTW, as I've mentioned in bug #30548, I've also replaced libX11-1.3.4 files in
> Fedora 14 with libraries from my Fedora 13 (libX11-1.3.1) and it still has the
> same problem. So, I also think that the problem is not in libX11 (or at least,
> it's been triggered by changes in somewhere else).
> 
Could be xkbcomp.

Is XStringToKeysym expected to return the correct code for 0x100XXXX codes?! I guess that previously, the one who called this function were skipping this function call when facing with 0x100XXXX codes, but it doesn't do it right now. So, maybe XStringToKeysym should be fixed to return the same hex code when encountering 0x100XXXX codes?

> Is XStringToKeysym expected to return the correct code for 0x100XXXX codes?!

The current version does.  A string like "0x100CA23" returns the integer 0x100CA23.

Aha, confirmed. It works in the latest git. BTW, the problem still persists. Where should this bug go from this point? :(

Well, since the bug is fixed and has been for over three months, I'm going to mark it FIXED ...

(In reply to comment #7)
> Aha, confirmed. It works in the latest git. BTW, the problem still persists.
> Where should this bug go from this point? :(

Sorry, I should've been a little more clear - xkbcomp from git master any time after July 9th fixes the issue.  I believe F14 had a broken xkbcomp for a while, but an update has been pushed there too.

:) Thanks