Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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 an attachment (id=63338) [details]
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 an attachment (id=63469) [details]
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 an attachment (id=63633) [details]
'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.