Hi Az I've been digging around on this one, but I have some info, just don't know what to do with it... Did some keycode checking, and the -r2 xfree is sending a different keycode (according to xev) for the right arrow key. Nothing in my configuration changed from the 4.2.1 setup. In xfree-4.2.1 right arrow sends keycode 114 In xfree-4.2.1-r2 right arrow sends keycode 110 Nothing else noticeable is amiss and I really have no idea where to go from here with it. I assigned bug to you for now, you can dump it back on me once I get a clue as to what to do :) Any suggestions would be great. Also it works fine still from kernel, showkeys shows me all the same keycodes that it did with older version (shouldn't be affected anyway)
Will do. What keymap btw ? Tried a different one yet ?
Okie, I went through a variety of keymaps etc, and even compared the newer keymaps and keycodes files to old ones, they are all identical and I get the same response with any keymap/keycode combo I tried. It looks like something else is causing this stuff. Any other suggestions?
No idea. Ill do a diff of xkb source in 4.2.1 and 4.2.1-r2, and see if I can track it down to a patch/whatever.
Ahh that sounds like exactly what the doctor ordered lemme know when you have something for me to test out
I did a bit of checking and the differences seem _very_ trivcial, this is a head scratcher...in fact I don't know what chagned really, looks identical: diff -uNr /var/tmp/portage/xfree-4.2.1/work/xc/lib/xkbfile/ /var/tmp/portage/xfree-4.2.1-r2/work/xc/lib/xkbfile/ diff -uNr /var/tmp/portage/xfree-4.2.1/work/xc/lib/xkbfile/maprules.c /var/tmp/portage/xfree-4.2.1-r2/work/xc/lib/xkbfile/maprules.c --- /var/tmp/portage/xfree-4.2.1/work/xc/lib/xkbfile/maprules.c 2003-01-07 12:33:56.000000000 -0500 +++ /var/tmp/portage/xfree-4.2.1-r2/work/xc/lib/xkbfile/maprules.c 2001-10-27 23:32:47.000000000 -0400 @@ -502,15 +502,15 @@ } else { if (rule->keycodes) - names->keycodes= _Concat(names->keycodes,rule->keycodes); + names->keycodes= _Concat(names->keycodes,rule->keycodes); if (rule->symbols) - names->symbols= _Concat(names->symbols,rule->symbols); + names->symbols= _Concat(names->symbols,rule->symbols); if (rule->types) - names->types= _Concat(names->types,rule->types); + names->types= _Concat(names->types,rule->types); if (rule->compat) - names->compat= _Concat(names->compat,rule->compat); + names->compat= _Concat(names->compat,rule->compat); if (rule->geometry) - names->geometry= _Concat(names->geometry,rule->geometry); + names->geometry= _Concat(names->geometry,rule->geometry); if (rule->keymap) names->keymap= _Concat(names->keymap,rule->keymap); }
Created attachment 7051 [details, diff] xkdbcomp diff Looks like there may be some big(ish) behaviour changes here, not sure how much applies but the definately messed with some keymaps.
First one prob just indentation/tab fixes. Looking at last diff now.
Looks more like eastern support, euro support and the bison-1.75 fix. Not really anything that looks like what could be causing. This on your PPC box Gerk ? Other guys with same problem ?
Yep on my ppc boxen (all of them). This problem occurs for all ppc users trying to use 4.2.1-r2. It's very perplexing. I;m not sure it's going to make the cut for 1.4 release time, but it would be great if it can. I've been working on this one myself for some time now and have gotten no where, its a large compile and I just don't have the time to fight with it :(
Oki, Ill see what I can do.
was there a lot of changes from 4.2.1 to 4.2.1-r2 ? Because 4.2.1 runs very well for me, the only issue I have with it is that it doesn't have the -fPIC fixup for xinerama. Times like this I wish we could run paralelle builds for different arches, as 4.2.1 + the fPIC patch would be all we really need ATM. I also have an ebuild that's done to supply the whole of dri-trunk into 4.2.1 (bringing it up to 4.2.99.2) which works amazingly well on my machine, gives most PPC users full dri capability. I went from 99fps in glxgears to 1400fps :) :) So maybe a 4.2.99.2 ebuild would be in order for ppc stable? (4.2.1 + dri-trunk stuff I have?). It might be an ugly build, but it would get things done very well for 1.4 release and being stable. Any thoughts on this Az ? BTW, the right arrow key is working ok again with 4.2.99.3
It's not PPC specific. I built xfree86-4.2.1-r2 for SPARC (sun5(us) kbd). On this system, Right arrow is OK, but the 'L/l' key sends 'B/b', and ',/<' sends 'v/V'. On another SPARC system with a different keyboard, it is reported that only the 'B' key is broken. My guess is that all platforms are broken in some way or another as far as xf86-4.2.1-r2 kbd mappings are concerned.
I think between Azarah and I we have tracked this down and there is a forthcoming build ( -r3) to correct this.
Gerk, your feedback on fixed -r2 ok? You think we should do a bump to -r3 to get people to update and make sure its fixed for all ?
Gerk, any feedback from Nall ?
Things are all fine for most users, Nall still has some strange keycode issues, I will cc him on this bug and get him on the loop. I think his down arrow key is mapping to eject heh
roughneck has this same issue so I'm adding him to cc
i'm still seeing this. pressing the down arrow causes the CD to eject. xev shows it's a keycode of 116. looking into this tonight.
dug in a little more tonight and this is not an X problem per se. from the console showkeys yields [Fn-F12] => 108 [Down] => 108 so this is futher reaching than X. there's something going on in the kernel scancodes->keycodes mapping. however, i did see this with respect to X (from the output of startx): Couldn't load XKB keymap, falling back to pre-XKB keymap here's my X keyboard setup: Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "CustomKeycodes" Option "XkbModel" "Macintosh" Option "XkbLayout" "us" Option "XkbRules" "xfree" EndSection thoughts?
No longer an issue for me on sparc (see #14126, 13161).
THis is most definately a pre XKB layout issue, likely with the adb styled keyboard layouts. Using XKB layouts is a work around, but the problem lies with upstream code. I've been told they know of at least part of this, so we'll see what happens in their CVS I suppose
ok, I finally got the skinny on all this... the pre XKB assumes ADB keycodes... adb keycodes in the kernel are very much depcreciated and the cause of this stuff by the looks of it. This wont be getting fixed according to the kernel people I have spoken with as it is legacy only, new sets should be using linux keycodes and not adb keycodes, so I'm going to close this bug Thanks az and everyone else
This bug should be closed, no longer an issue.
