Re: Keyboard handling on non-x86

On Sun, May 22, 2005 at 08:40:41PM -0400, Michael wrote:
>Hello,
>
>here's the patch.

Thanks -- I'm committing it now.

>> If older versions of NetBSD (x86 at least) don't have wscons, there
>> should at least be a check that it is available.
>
>Did that. X -configure with wscons support / NetBSD it will try to open
>/dev/wskbd, if it succeeds it will write driver kbd, protocol wskbd and
>device /dev/wskbd into XF86Config, if not it falls back to driver
>keyboard.

That's good.  Even better, especially for the modular driver, would be
to handle this automatically in the driver at run-time.  The mouse driver
does this and should handle auto-detection of wscons support on NetBSD
for mouse input without the need for any mouse configuration data in the
config file.

>> I suggested using the xfree86 XKB rules/keycodes for consistency of
>> features across platforms and because they are the best-supported ones
>> within XFree86.  In the past, diverging from this has resulted in
>> unnecessary feature and functionality differences between platforms.
>> Also, the set of XKB key tokens (the <XXXX> objects mapped to raw
>> keycodes by the keycodes files) would ideally be platform-independent
>> to avoid the unnecessary need to have multiple copies of the XKB
>> symbol mappings.
>
>I added the Sun-specific keynames found in atKeynames.h to the Sun map
>in bsd_KbdMap.c and changed both the legacy driver and the modular
>keyboard driver to drop anything that's no sane scancode ( like
>KEY_NOTUSED ) and in case of the legacy driver anything that translates
>to something >0x7f because xf86PostKbdEvent() uses 0x80 as up/down
>indicator. This way everything is fine and the extra keys are (almost)
>all usable with kbd while the legacy driver behaves the same as before -
>extra keys don't work, some scancodes get mangled ( like most cursor
>keys ).

OK.

>> The symbols mappings in xkbcomp/symbols/pc are the most full-featured
>> that we have, and they're not really PC-specific.  In fact, it is
>> probably a good time to promote them out of their pc/ subdirectory.
>
>They don't contain mappings for Sun extra keys like audio up/down and
>the extra function keys. Then there's nothing to do for the compose key.

Additional keyboard model-specific mappings can be added, especially with
these mapping promoted out of the their current location.

>> That would just leave the issue of whether the raw keyboard codes are
>> mapped to a consistent set of X keycodes within the driver, or whether
>> that is handled by using different XKB keycodes files.  I don't see a
>> great advantage to doing this mapping at the XKB level.
>
>The Sun map had a minor mistake (or feature?)- Props/L3 and ScrollLock
>were swapped.

Sounds like a bug.

Thanks again for the patch.

David