For me, testing xorg-6.7.99.902 on sparc (32 or 64) with a 2.4.xx series kernel and a sparc keyboard (type4, type5), the xorg.conf InputDevice section for the Keyboard is either quite imcompatible with xorg.conf for 6.7.0, or else there are problems with the driver for the keyboard: Background: On sparc64 with kernel 2.6.x, the only keyboard changes required for the move 6.7.0 ==> 6.7.99.902 are cosmetic ('keyboard' --> 'kbd', remove Protocol) With kernel 2.4.xx, this is certainly not the case for me. Playing with various reasonable looking alternatives to my default never has given me a working configuration yet. The closest maps 'a' ==> 's', 's' ==> 'd', 'Tab' ==> 'q', 'z','x',' '... ==> <DEAD> and so on. Worst maps result in things like "L-Shift' ==> Reboot, xinit ==> Reboot or other exciting posibilities. (Here, 'reboot' means 'the system reboots' as opposed to reboot-to-get-the-console-back.) For now, I am holding on to this bug until I can get more information because: 1. I am not sure yet that this is not a user (i.e., my) mistake. Comments are welcome. 2. I want to test some permutations like building with #define UseDeprecatedKeyboardDriver YES 3. I suspect that no one else is actively testing xorg-x11-6.7.99.xxx with sparc right now, anyway, so I might as well hole on to it until I figure it out, give up, or get told the answer by someone on the CC list. That last option (someone says "You idiot, you need to ...") because on these systems, if a major rebuild is required (and changing behavior like USE_DEPRECATED_KEYBOARD_DRIVER is such a case), I have to wait a LONG time between tests.) :) I don't know enough yet to know if this blocks Bug 60292 or not.
That's xorg-x11-6.7.99.902, of course (not xorg-6...)
With DEPRECATED_KEYBOARD SS20 + CG6 + xorg-x11-6.7.99.902 + sun-kbd is fine. I'll verify for sparc64 (U2) as well, then reassign bug. Workaround in the ebuild looks like this (for example): if [[ $(uname -r) != 2.6.* ]] then einfo "Kernel $(uname -r) needs the Deprecated keyboard driver" echo "#define UseDeprecatedKeyboardDriver YES" >> config/cf/host.def fi in the ebuild where "case ${ARCH} ... sparc)" is setting up other config options for sparc. My build-for-sparc xorg-x11 at d.g.o/~fmccor/files/xorg-x11.tbz2 contains this change now.
Not uname by default, more like this: if ( [ -e "${ROOT}/usr/src/linux" ] && \ [ ! `is_kernel "2" "6"` ] ) || \ [ "`uname -r | cut -d. -f1,2`" != "2.6" ] then foo In fact, even that's not quite right. The last part should be an integer test so we don't need to change this when/if anything greater than 2.6 comes out. Point is to default to using /usr/src/linux for deciding which kernel is the proper one. If it doesn't exist (such as on an installing system that hasn't emerged kernel sources yet), drop back to uname.
Created attachment 38398 [details] xorg-x11-6.7.99.902 ebuild which autodetects requirement for Deprecated Keyboard on sparc
Also on sparc64 with kernel 2.4.xx, xorg-x11-6.7.99.902 seems to need the Deprecated Keyboard Driver. With this driver, ..902 runs fine on sparc64(ffb2+) and, as noted in Comment 2, on sparc32(cg6). I am marking this as a blocker for 60292 because without a resolution, this version of xorg-x11 is not usable on sparc with kernels from the 2.4 series and sun keyboards. The attached ebuild is the one I have been using to test a workaround for this (and other) problems noted in xorg-x11 testing for this version on sparc. Notice that it doesjust what Comment 2 suggests, and from my point of view, that is an adequate solution. Of course. others might have a different point of view, and I can work with anyone who wants to build a proper solution into the xkb driver, but without such a request, I am finished with this bug and am satisfied with the resolution. Note added in proofing: I had not seen Comment 3 when I made the atachment. And in greatest generality, what matters is the kernel running on the system you are building for, not building on, so no solution like this is quite correct, I suppose. I don't really care how the specification is done, so long as the end result is that the ebuild can build a working xorg.
Sorry about the incomplete kernel check. I was in a hurry when I did all this and didn't read the xfree eclass (nor the rest of this ebuild, I guess).
1. Donnie's Comment 3 is fine: if ( [ -e "${ROOT}/usr/src/linux" ] && \ [ ! `is_kernel "2" "6"` ] ) || \ [ "`uname -r | cut -d. -f1,2`" != "2.6" ] then einfo "Building for kernel-$(uname -r) requires special treatment" echo "#define UseDeprecatedKeyboardDriver YES" >> config/cf/host.def fi at about line 408. 2. I notice that the version I made available does not have the "fix" for a clean compile on (some) sparc32-SMP systems. I'll update it later for that; I thought I had listed the fix at 60292, but I didn't. The "fix" is echo "/* Keep compiler happy */" >> xc/programs/Xserver/hw/xfree86/drivers/ati/<fails-to-compile> the name of which I don't have near by, but even easier is just take 'ati' out of the list of drivers built for sparc, since I don't think there are any ati drivers for sparc32 anyway. This list is in the ebuild at about line 399.
Not my evening, I guess. The last bit of Comment 7 is addressed only to sparc32 systems, where there is no point in building ati drivers anyway. Every sparc kernel 2.2 or 2.4 system is caught by this general bug; the ati comment was only in case a 2.2 or 2.4 kernel sparc32-SMP system needs to test, but is one on which the compile itself fails.
BTW: are we expected to keep this workaround forever, or what? (Note that we still have 2.0-series kernels floating around, so it might be nicer to actually fix it instead of waiting for 2.4 kernels to disappear).
If this question is addressed to me, I can't answer it. As best as I can determine, the problem is in xorg when the kbd driver needs sun rules. With the deprecated driver, we have (with kernels 2.2, 2.4) Driver "keyboard" Option "Protocol" "Standard" Option "XkbKeycodes" "sun(type5)" Option "XkbModel" "type5" Option "XkbRules" "sun" Option "XkbLayout" "en_US" which is exactly what the keyboard is. With kernel 2.6, we have, say, Driver "kbd" Option "XkbModel" "type5" Option "XkbRules" "xorg" Option "XkbLayout" "en_US" because of kernel changes. ========================= The problem discussed here is sun+kbd driver. The only Rules choice that has a chance is "sun" with kernel 2.4 (and experimentation shows that any thing else leads to a reboot). But once you choose with kernel 2.4 something that looks like Driver "kbd" Option "XkbRules" "sun" the BEST I have been able to achieve gets the "a-key" ==> "s"; "z-key" ==> "" mentioned in the original description. The reason I unassigned myself the bug is that right now, this looks like a problem in xorg kbd itself, peculiar to sun keyboards with kernels < 2.6. As long as the built-in (deprecated) driver works for that combination, I don't see any reason to make xkb driver work for it too, but if you or xorg (ajax?) want to pursue it, I'm willing to work with you. (xorg is not sensitive to the kernel, here. The problem comes from the required keyboard rules, which change with the 2.4 ==> 2.6 change. Two sample xorg.conf files (for 6.7.0) at http://dev.gentoo.org/~fmccor/docs/xorg/xorg.conf/xorg.conf.html make explicit what I am talking about. --- With 2.6, specifying KEYMAP="sunkeymap" to rc.conf is a *bad idea* :))
Some additional information. There appear to be at least two problems here, and they depend more on whether or not actually uses the xkb files, it seems, than or which driver is used. The first is the keyboard shift, and experimentation indicates it comes about like this: Force by whatever means 'xev' to run and look at the keys coming in. Pick a live key, say 'j'. xev says that 'j' comes in as keycode=91, and sun type5 keycode for 91 corresponds to <AC08>. Now, look at what symbol that is. The symbol for a sun type5 for <AC08> comes from us(basic), and us(basic) for <AC08> -> 'k'. Hence, the shift. The second problem is that about half of the keyboard is dead. This seems to come from a variety of mistakes. Here are a couple of them (again, from xev): 1. The 'k' key comes in as keycode=111 (wrong!) and eventually gets translated to Shift_L (left shift key). However, we should see 111 -> <AB05> -> 'b' (also wrong, of course). 2. The 'l' key comes in as keycode=93 (probably wrong, but consistent with 'j'). This should map 93 -> <AC10> -> ';' (wrong, but consistent). But it does not. It maps 'l' -> 93 -> <DEAD> I don't see it, but maybe this will trigger an idea from someone.
To my knowledge there's no way to change the incoming hardware keycode. The hardware keycodes have no standards or rules they should be following, so they can't be wrong or right -- they are what they are. You can just change the keycode it's translated to (e.g., <AE05> or whatever), or change the keysym (e.g., k) depending on the situation.
So I need to chase down where the deprecated driver is and figure out how it manages to get it right....
Look into the xkb settings -- they've had different defaults. That may be enough to break things.
Thanks, I'm sure it's something like that. If I use the 'keyboard' driver and set up xorg.conf to define the keyboard with Options, I get 'j' -> 90, etc., and everything works. If instead I clear the defaults and force file loads from xkb with a keymap, then it's back to 'j' -> 91 (== 'k'-on-screen). I just haven't isolated the 'keyboard' processing yet.
Small update on my understanding of the keycode/scancode thing: The keyboard sends a scancode in hex, which the kernel translates to a keycode (144, 97, etc.). X gets that hardware keycode, turns it to what XKB calls a "keycode" (<AE04> etc) that generally specifies position on the keyboard, then converts that to a "keysym" (k, l, m, etc). See e.g., getkeycodes(8) and setkeycodes(8) for more info on the kernel part. So if the kernel's translation is different, that could cause problems too.
Still the case with xorg-x11-6.8.99.x; so just note the fact and update the summart to keep it relevant. (Someday "real soon now" kernel 2.6.423 will be out and stable on sparc, and this can disappear. Until then, it's annoying, and the deprecated keyboard driver has to stay around.)
I had run into the same problem, and had planned to follow all leads listed here for a long time. Now I did, and I made it work. The keyboard section from the xorg.conf shown on http://dev.gentoo.org/~fmccor/docs/xorg/xorg.conf/xorg.conf.html works perfectly on my Ultra 5, with sparc-sources-2.4.30, xorg-x11-6.8.2-r1, and a Type 5c keyboard.
Created attachment 63338 [details, diff] Fix for kbd on Sparc frm xorg-CVS Xorg hast just fixed the kbd-problems in CVS I'll attach a diff from thier cvs-site (has some offsets to 6.8.2)
Thanks. I'll verify on a kernel-2.4.xx in a day or so, and pass on the results.
As mentioned in Comment 19, for xorg-x11-6.8.2 [-r2], the patch as written does not apply cleanly. But if you fix up the line number range to conform to 6.8.2 version of kbd.c, resulting kbd_drv.so module builds cleanly, and so far works fine on 2.4.xx kernels. So this bug is essentially fixed except for some bookkeeping issues. So, I'm changing its status to fixed upstream, since we tell people now to use the (deprecated) keyboard driver, and it still gets built for 2.4 kernels. We can keep doing that until this fix makes it into a stable-for-sparc version of xorg. Thanks, Ferris
Oh, I should add for completeness: kbd_drv.so with this patch still works with hernel-2.6.xx: sun keyboards there look like PC keyboards, so the "if (pKbd->sunKbd) {" test is never true.
Created attachment 63469 [details, diff] kbd fix for 6.8.2 systems This is the corresponding patch for xorg-x11-6.8.2[-r2]. If you want to use it, apply it by hand in xc/programs/Xserver/hw/xfree86/input/keyboard. (By the way, I have not found any way to get the xorg-CVS version to install cleanly: HUNK 1 always fails; HUNK 2 always succeeds. But if you install it by hand, everything works, and as long as it is eventually going to be released correctly, that's all that matters.)
Created attachment 63633 [details, diff] 'diff -u' patch to correct kernel-2.4.xx 'kbd' problems, any version or xorg. The same patch as the one it replaces (see previous comment), but run it in your ${PORTAGE_TMPDIR}/portage/xorg-x11-[version]/work directory with the same command: patch -z- -b -p0 < {wherever}/kbd.patch-gentoo This should work for any version of xorg-x11 you are building, and it allows you to forget about whether or not you need the deprecated keyboard. (You must apply this patch by hand; I am not providing modified ebuilds to apply the patch automatically. Either way, you have to grab a patch and apply it.)
With xorg-x11-6.8.99.15, this patch is incorporated into the release and so is not needed at all. I'll close it as soon as this xorg series settles down and gets unmasked, and I can reverify. In the mean time, from .99.15 on the bit which for .15 is at lines 741--42 of the ebuild: einfo "Building for kernels less than 2.6 requires special treatment." echo "#define UseDeprecatedKeyboardDriver YES" >> ${HOSTCONF} should no longer be needed.
(In reply to comment #25) > In the mean time, from .99.15 on the bit which for .15 is at lines 741--42 of > the ebuild: > einfo "Building for kernels less than 2.6 requires special treatment." > echo "#define UseDeprecatedKeyboardDriver YES" >> ${HOSTCONF} > should no longer be needed. Done.
Comments #24 and #25 committed to 6.8.2-r5.
