[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-sparc
Subject:    [gentoo-sparc] xorg-x11-6.8.0-r4 + sparc + kernel-2.4.xx + 'kbd' keyboard driver
From:       Ferris McCormick <fmccor () gentoo ! org>
Date:       2004-12-08 18:39:50
Message-ID: 41B74A76.4040602 () gentoo ! org
[Download RAW message or body]

I am writing this as a note before turning it into a bug report because 
the problem looks like a problem someone might look at and say "Of 
course, you dummy, do this!"

I misspoke slightly yesterday when I said the 'kbd' driver shifted keys 
as always.  It shifts keys ('a' -> 's', etc) if the keysymbols are 
defined as sun/us(type5).  Otherwise, the living keys seem OK, but there 
are a lot of dead ones --- 'k', 'l', 'z'. 'x', ....

With the deprecated driver, everything is fine with or without the 
keysymbols definition, so for now on, assume a Keyboard like this:
   Option      "Protocol"    "Standard"
   Option      "XkbKeycodes" "sun(type5)"
   Option      "XkbModel"    "type5"
   Option      "XkbRules"    "sun"
   Option      "XkbLayout"   "en_US"
   Option      "XkbTypes"    "types/complete"
   Option      "XkbCompat"   "compat/complete"
   Option      "XkbGeometry" "sun(type5unix)"

This works with the deprecated driver, but as I said before, there are a
lot of dead keys with the 'kbd' driver.

Now, let's set up an experiment:  We make a (new) Keyboard map, call it
  Option       "XkbKeymap"     "sun/us(type5_Unix)"
which looks a lot like sun/us(type5_unix) except we can play with it. 
In fact, we can make it look exactly like the above set of options if we 
like.

If we do that, behavior should remain the same, and indeed with 'kbd' it
does.  With the deprecated 'keyboard', however, things change:  No 
matter how we define the Keymap, 'keyboard' and 'kbd' are identical (and 
wrong --- dead keys at 'k', 'l', 'z', 'x', ...) (except for keysymbols).

So, it looks to me like three things are happening:
1.  Without the Keymap, the 'keyboard' driver ignores some options and 
processes them internally; with keymap, the xkb files are used.
2.  XkbSymbols file sun/us(type5) is probably wrong, but ignored as an 
option by 'keyboard';
3.  At least one other xkb/ file is wrong but ignored by 'keyboard' as 
an option.  When actually used, it causes keys like 'k' to be dead for 
both drivers.

Unfortunately, at this point, I am confused.  It looks like input/kbd.c 
sets things up for 'kbd' driver, but beyond that I haven't found where 
the xkb files are processed or ignored.

Thoughts?


Thanks,
Ferris

-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc)

["signature.asc" (application/pgp-signature)]
--
gentoo-sparc@gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]