Bug 30548

I do not know what exactly was broken in xorg code (in fedora only? it is ok in ubuntu). But I alway preferred keysym names. So I would be happy to fix the bug. Would you attach the patch(es) here?

Created attachment 39107 [details] [review]
Remove some extra semicolons

Notice that these bugs does not exist in released Fedora versions, but in Fedora 14 beta which uses newer versions of xorg related packages. So, I think there is something wrong in newer versions. Specially, the first patch is a clear error in "ir" layout file and prevents it from loading at all. The layout file has been modified recently.

Also, the main bug affects other layouts too, such as "af".

Created attachment 39108 [details] [review]
Replace some key codes with corresponding names (but not all of them)

I'm not sure if all key codes have a corresponding name. (?!)

Review of attachment 39107 [details] [review]:

This one is already fixed in git

Thanks, committed!

Thanks :)
But I should assert that, if it has not been solved already, the problem will cause some keys in some layouts to not work in newer versions of xorg (xorg-x11-server-Xorg-1.9.0). So, either all key codes in all layouts should be replaced, or the problem should be fixed.

I see your point. The thing is that not entire Unicode is covered by X keysym names.

I guessed so (since I didn't find keysym names for some codes), and this is why I think the old behavior should be kept. Maybe I should report a bug against another package?

You can raise the issue at xorg-devel maillist. But IIRC the idea was that we do not have to add full Unicode - the unicode hex codes should work...

Yes, but the problem is that unicode hex codes doesn't work in xorg-xserver 1.9.0!

File a bug against xorg Input/XKB

Thanks, submitted: https://bugs.freedesktop.org/show_bug.cgi?id=30549

You should use git bisect to determine which commit to libX11 causes the
bug.  A couple of possibilities might be 2e7a18b6a617 or bea0873caf50.

But I don't have an xorg development stack at hand, and at least for now I cannot afford that in terms of required bandwidth and time...

(In reply to comment #15)
> But I don't have an xorg development stack at hand, and at least for now I
> cannot afford that in terms of required bandwidth and time...

you only need the dependencies for libX11-devel and then clone the libX11 git tree from git://anongit.freedesktop.org/git/xorg/lib/libX11. I've been on vacation for 2 weeks and will spend the next two and a half days on planes. If you help bisecting, we can fix this issue as soon as I'm back.

OK. I'll try. but both mentioned commits are done after libX11 1.3.4 release (which is used in Fedora 14 and is problematic). So, maybe these commits fix the problem! I'll test and report the results.

Well, I tried going back to earlier versions... but even by replacing libX11 1.3.1 files (used in Fedora 13 and work fine) the problem still exists. So, either the problem is not in libX11 or it is triggered by change(s) in another component. (or maybe there is something wrong in my tests!)

As mentioned in the comments #11 and #12 at https://bugzilla.redhat.com/show_bug.cgi?id=638244, it seems that all hex codes in the form of 0x100XXXX should be replaced with the form UXXXX in all keyboard layouts. UXXXX form hex code still work in the latest X server.

That's just a workaround for a bug - the X server should not be breaking
compatibility with the existing xkb keytables.

xkbcomp commit below fixes this issue.


commit a281386fa887e6bf4110840779aed46dd0ac89b6
Author: Daniel Stone <daniel@fooishbar.org>
Date:   Fri Jul 9 19:34:29 2010 +0100

    Fix parsing of 0x1a2b3c4d-style symbols
    
    Raw keysyms were not getting parsed correctly, due to forgetting to add
    the code to libX11, forgetting to add the backwards-compat code for old
    libX11s, and then stuffing the lexing up anyway.  Yeesh.
    
    Signed-off-by: Daniel Stone <daniel@fooishbar.org>