Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 61940 - xorg-x11-6.8.[29].*+ sparc + sun kbd + kernel-2.4.xx => Keyboard Input device is either incompatible with 6.7.0 or broken
Summary: xorg-x11-6.8.[29].*+ sparc + sun kbd + kernel-2.4.xx => Keyboard Input device...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: Sparc Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
Depends on:
Reported: 2004-08-27 09:05 UTC by Ferris McCormick (RETIRED)
Modified: 2005-09-19 19:34 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

xorg-x11- ebuild which autodetects requirement for Deprecated Keyboard on sparc (xorg-x11-,39.41 KB, text/plain)
2004-08-28 12:25 UTC, Ferris McCormick (RETIRED)
Fix for kbd on Sparc frm xorg-CVS (kbd.patch,967 bytes, patch)
2005-07-13 12:36 UTC, Matthias Muthmann
Details | Diff
kbd fix for 6.8.2 systems (kbd.patch-6.8.2,652 bytes, patch)
2005-07-15 06:46 UTC, Ferris McCormick (RETIRED)
Details | Diff
'diff -u' patch to correct kernel-2.4.xx 'kbd' problems, any version or xorg. (kbd.patch-gentoo,744 bytes, patch)
2005-07-17 10:59 UTC, Ferris McCormick (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ferris McCormick (RETIRED) gentoo-dev 2004-08-27 09:05:07 UTC
For me, testing xorg- 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 ==> 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

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
2.  I want to test some permutations like building with 
     #define UseDeprecatedKeyboardDriver YES
3.  I suspect that no one else is actively testing 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.
Comment 1 Ferris McCormick (RETIRED) gentoo-dev 2004-08-27 09:20:44 UTC
That's xorg-x11-, of course (not xorg-6...)
Comment 2 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 08:47:29 UTC
With DEPRECATED_KEYBOARD SS20 + CG6 + xorg-x11- + 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.* ]]
	    einfo "Kernel $(uname -r) needs the Deprecated keyboard driver"
	    echo "#define UseDeprecatedKeyboardDriver YES" >> config/cf/host.def
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.
Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2004-08-28 12:21:06 UTC
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.
Comment 4 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 12:25:49 UTC
Created attachment 38398 [details]
xorg-x11- ebuild which autodetects requirement for Deprecated Keyboard on sparc
Comment 5 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 12:38:46 UTC
Also on sparc64 with kernel 2.4.xx, xorg-x11- 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.
Comment 6 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 13:01:24 UTC
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).
Comment 7 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 16:05:10 UTC
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" ]
                einfo "Building for kernel-$(uname -r) requires special treatment"
                echo "#define UseDeprecatedKeyboardDriver YES" >> config/cf/host.def
  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.
Comment 8 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 16:24:22 UTC
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.
Comment 9 Donnie Berkholz (RETIRED) gentoo-dev 2004-08-28 18:53:37 UTC
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).
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2004-08-28 19:46:28 UTC
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
make explicit what I am talking about. --- With 2.6, specifying KEYMAP="sunkeymap" to rc.conf is a *bad idea* :))

Comment 11 Ferris McCormick (RETIRED) gentoo-dev 2004-12-13 11:41:10 UTC
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.
Comment 12 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-13 13:15:30 UTC
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.
Comment 13 Ferris McCormick (RETIRED) gentoo-dev 2004-12-13 13:33:23 UTC
So I need to chase down where the deprecated driver is and figure out how it manages to get it right....
Comment 14 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-13 14:12:16 UTC
Look into the xkb settings -- they've had different defaults. That may be enough to break things.
Comment 15 Ferris McCormick (RETIRED) gentoo-dev 2004-12-14 06:46:06 UTC
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.
Comment 16 Donnie Berkholz (RETIRED) gentoo-dev 2004-12-15 21:12:36 UTC
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.
Comment 17 Ferris McCormick (RETIRED) gentoo-dev 2005-04-20 05:26:43 UTC
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.)
Comment 18 Peter Schloemer 2005-06-15 11:45:54 UTC
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 works perfectly
on my Ultra 5, with sparc-sources-2.4.30, xorg-x11-6.8.2-r1, and a Type 5c keyboard.
Comment 19 Matthias Muthmann 2005-07-13 12:36:39 UTC
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)
Comment 20 Ferris McCormick (RETIRED) gentoo-dev 2005-07-14 09:28:55 UTC
Thanks.  I'll verify on a kernel-2.4.xx in a day or so, and pass on the results.
Comment 21 Ferris McCormick (RETIRED) gentoo-dev 2005-07-14 15:35:22 UTC
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 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.

Comment 22 Ferris McCormick (RETIRED) gentoo-dev 2005-07-14 20:43:38 UTC
Oh, I should add for completeness: 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.
Comment 23 Ferris McCormick (RETIRED) gentoo-dev 2005-07-15 06:46:36 UTC
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.)
Comment 24 Ferris McCormick (RETIRED) gentoo-dev 2005-07-17 10:59:24 UTC
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
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
Comment 25 Ferris McCormick (RETIRED) gentoo-dev 2005-07-20 10:16:15 UTC
With xorg-x11-, 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.
Comment 26 Donnie Berkholz (RETIRED) gentoo-dev 2005-07-20 10:19:14 UTC
(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.

Comment 27 Joshua Baergen (RETIRED) gentoo-dev 2005-09-19 19:34:38 UTC
Comments #24 and #25 committed to 6.8.2-r5.