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 _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
