[gentoo-dev] Re: xorg-x11-6.7.0-r2, XF86Standby: keysym 0x0, NoSymbol

[Duncan]

Duncan posted <pan.2004.07.23.07.47.51.730874@×××.net>, excerpted below, 
on Fri, 23 Jul 2004 00:47:52 -0700:

> Norberto Bensa, excerpted below0:
>
>> did anything related to keyboards changed in xorg-x11-6.7.0-r2 since
>> -r1? I can't seem to make my "Suspend" key work (it was in -r1) Keyboard is a
>> Microsoft Natural Keyboard Pro.
>>
>> xev says: keycode 225 (keysym 0x0, NoSymbol)
>
> I thought it was just me!  Logitech Cordless Desktop Pro, here.
>
> It's supposed to use the same keysym, XF86Standby, assigned to <I5F>, in
> /etc/X11/xkb/symbols/inet, which is assigned to kernel keycode 223 in
> /etc/X11/xkb/keycodes/xfree86, as the MS keyboards.

OK.  Spent about as much time on this as I'm going to.  Results:

It's not the kernel.  Booting back to Mandrake (using the same kernel,
but different userland naturally, and XFree86 not Xorg) gave me the
expected keycode 223 and XF86Standby, recognized by KDE.

Surprise, however!  It is NOT just X, either.  I did a showkeys on both
Gentoo and Mandrake, console mode, and they came out DIFFERENT.  Mandrake
yields a multi-code output (14, and 0, and..), while Gentoo yields a
single code (142).  (I believe those are in hex, not the decimal that xev
displays, but didn't attempt to verify.)  Thus, it /might/ be something
else in userland, maybe glibc.

Next, back in Gentoo, I tried simply backing up the (/etc/X11/xkb/)
keycodes/xfree86 and symbols/inet files, and copying the XFree86 files
over the xorg ones, to see if that made a difference.  I doubted it would,
but figured it was a quick elimination so tried it.  I was right.  It
didn't work.

I then tried setting up an xmodmap key remap. That /almost/ worked, but
not quite. xev output the new keycode (223) and keysym (XF86Standby), but
it also output that it was a conversion, keycode 225 into 223, and while
khotkeys would recognize it when CHANGING a hotkey, it would NOT recognize
it trying to trigger a programmed action.

Then I spent several hours trying to figure out how to just do a single
key mod as a separate file, or do it as a single line in the xorg.conf
device keyboard section, so I could leave the existing xkb configuration
intact, to no avail.  I gave up, feeling rather thick, and frustrated. <g>

Back on the trail of something I KNEW should work, I decided I had to
modify either the symbols or the codes files themselves.  I chose the
modify the symbols table (symbols/inet).  Again, trying to be as minimally
invasive as possible, I tried defining XF86Standby to BOTH I5F and I61. 
As with the xmodmap thing, that /almost/ worked, with the same results
(xev saying it was there but converted, khotkeys taking it when SETTING a
hotkey, but ignoring it when attempting to USE a hotkey).

I'd tried putting the I61 definition UNDER the I5F one, so they stayed in
order.  Since THAT  didn't work, I tried reversing them, thinking I61
would then be the "real" lookup, being first defined, with I5F then
showing up as "converted".  I'm not sure why, perhaps because of the
sequence of my trials, but that had no effect.  The system STILL said I61
was a conversion from I5F, and it STILL almost-but-not-quite worked.

However, what finally *DID* work was commenting out the I5F definition
altogether, so I61 = XF86Standby was the ONLY XF86Standby definition. 
Loading X/KDE for what felt like the hundredth time in the session, *IT*
*WORKED*!!

So, an at least temporary solution is to edit /etc/X11/xkb/symbols/inet,
finding the appropriate section for your keyboard, and changing this:

    key <I5F>   {       [ XF86Standby           ]       };

into this:

//  key <I5F>   {       [ XF86Standby           ]       };
    key <I61>   {       [ XF86Standby           ]       };

While that works for now, I'm not entirely happy with it, as depending on
how the file is installed by the ebuild (thru /usr or /etc, due to the
symlink to the grandparent xkb dir) and the CONFIG_PROTECT, it will either
need reedited each time xorg is upgraded, or if CONFIG_PROTECTED, when the
bug is fixed.

I do also need to see about filing the bug, still, checking for duplicates
first. I'm tempted to wait until the August release, however, and see if
it's fixed there before bothering, as if it's not in process already,
validating the fix might make it impossible to do by then anyway.  OTOH,
I DO wonder what changed, and doing the duplicate bug research might turn
that info up, if it HAS already been filed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@g.o mailing list