Re: Keyboard handling on non-x86

On Thu, May 19, 2005 at 08:11:25PM -0400, Michael wrote:
>Hello,
>
>right now I'm struggling to get XFree86 properly supported on
>NetBSD/sparc and sparc64 and one problematic point is the keyboard
>handling. 
>With
>Option "Protocol" "wscons"
>Option "Device" "/dev/wskbd0"
>things work reasonably well but the Xserver doesn't pot these options
>into XF86Config when configuring itself, so I tried to get the

Ideally it should automatically determine when "wscons" mode is needed.
This would be easier to do via the modular XFree86 "keyboard" driver
than with the built-in "kbd" driver.  See more below.

>read-input-from-console mode to work. This is where the mess started. 
>XFree tries to switch the console fd into raw mode and if that fails it
>complains and recommends to add the above lines to XF86Config. This was
>ok since we didn't support raw mode on Sun keyboards. Now we do.
>In this mode of operation XFree obviously expects to read AT-style
>scancodes from the console fd and feed them into its event queue via
>xf86PostKbdEvent(). With a Sun Type 5 this can't work since it uses a
>completely different set of scancodes ( but at least it uses but 7 the
>same way to signal key up / down ). What confused me for a while is some
>code in xf86PostKbdEvent() that seemed to handle Sun scancodes but as it
>is now it can't possibly work. And it doesn't properly translate Sun
>scancodes into whatever X uses internally, so I conditionally replaced
>xf86Info.kbdEvents with a function that reads from the console fd,
>translates Sun scancodes unto AT scancodes the way xf86PostWSKbdEvent()
>does and feeds them to xf86PostKbdEvent(). This works mostly, but I
>found that the PageDown key didn't deliver a scancode. Some debugging
>revealed something ugly - its translated keycode collides with the
>prefix code used by AT keyboards for cursor keys and the number block
>and the prefix handling in xf86PostKbdEvent() is skipped when
>xf86Info.kbdEvents points to the wscons version. Still easy to get
>around this, ugly as it is.
>Finally I found that atKeynames.h defines names for Sun-typical keys
>found nowhere else, but what it assigns them starts at 0x84 so it
>collides with the AT keyup/down bit - to deliver it to
>xf86PostKbdEvent() I'd have to prefix them which I can't since prefixing
>is disabled. 
>
>So - what would you suggest - I think I should replace
>xf86PostKbdEvent() with something usable by wscons which doesn't need
>all this AT-inherited nonsense, I don't really see why I should emulate
>this broken excuse for a protocol to get keyboard events into the
>Xserver. There are two sets of functions which seem to deal with
>keyboard input on BSD - one in bsd_io.c and another in bsd_kbd.c - the
>latter seems unused. What's the purpose of this?
>And lastly - why does the wscons protocol option require a device name?
>Defaulting it to /dev/wskbd should do the trick.
>Would it be better to write an input driver module for wskbd that uses
>wscons' hardware-independent scancodes instead? Seeing the mess that the
>current code is I'd almost think so.

I would suggest following this up via the modular "keyboard" driver.
Like the mouse driver, it consists of two components: a
platform-independent input driver module in xfree86/input/keyboard/, and
an OS-specific portion in xfree86/os-support/platform/.  The interface
between the two should make it possible to avoid forcing all keyboard
models into the AT-style mould.  Also, as with the mouse driver, it
should be able to automatically determine which is the best device/protocol
mode to use at run-time.

One thing to keep in mind is that the mapping between physical keys and
their X keycodes should remain the same on all platforms.  This mapping
is specified in the file xc/programs/xkbcomp/keycodes/xfree86.

If you find any issues with the keyboard driver or the interface between
the platform-specific and platform-independent components of it, this is
the place to discuss and resolve them.

David