On Fri, May 20, 2005 at 02:37:59PM -0400, Michael wrote: >Hello, > >> Ideally it should automatically determine when "wscons" mode is >> needed. > >Ok, on NetBSD that would be always, none of the pre-wscons ports runs >XFree as far as I can tell. So - some ( like x86 ) might not exactly >/need/ it but they /should/ use it.
If older versions of NetBSD (x86 at least) don't have wscons, there should at least be a check that it is available. >> This would be easier to do via the modular XFree86 "keyboard" driver >> than with the built-in "kbd" driver. See more below. > >Yeah, I finally found it - looks MUCH more sane than what I've been >ranting about yesterday. In fact I got it to work pretty well now and I >have a few questions. > >> 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. > >That's what I'm doing now. When I find a Sun keyboard I simply change >the default xkb settings to rules=sun and model=type4 or type5. Works >pretty well when I disable scancode remapping ( it's still in the >driver... ) - then even the Sun-specific keys work and it can still be >overridden via XF86Config. > >> 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. > >Agreed. > >> 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. > >What I'm doing right now is to make the keyboard driver use xkb for >scancode->keysym translation, at least for Sun keyboards. This allows >all keys to work and avoids all these AT-scancode quirks. To do that I >leave both the remap function and the scancode translation table at >NULL and set the XKB keymap according to what wskbd tells me about the >keyboard ( sun type4 or sun type 5 ). The wscons support code there has >numerous issues: >- it didn't know about WSKBD_TYPE_SUN5 so initially it tried to use >AT-style scancode translation. >- the mapping between XLEDs and wscons ioctls is wrong. The reason seems >to be the sun keymap which says: > > indicator 4 = "Caps Lock"; > indicator 3 = "Compose"; > indicator 2 = "Scroll Lock"; > indicator 1 = "Num Lock"; > >... while XFree's map says: > > indicator 1 = "Caps Lock"; > indicator 2 = "Num Lock"; > indicator 3 = "Scroll Lock"; > >the latter seems to be hard-coded into the driver. > >The driver still attempts to translate everything into AT scancodes >which is a Bad Thing in my opinion, I think the main reason is to catch >special keystrokes like ctrl-alt-backspace before xkb does. Is this >really necessary? Shouldn't xkb handle them correctly? These are still handled in the driver for cases when XKB isn't used, and as fallbacks when XKB initialisation fails for some reason. It is probably a good idea to keep these fallbacks within the keyboard driver, especially the ctrl-alt-backspace escape method. >Wouldn't it be better to select a sane xkb map instead of attempting to >make everything fit a PC keymap? 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. 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. 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. I'd like to see a lot of the unnecessary platform differences amongst the XKB data files eliminated. I suspect that with some work most of the platforms specific copies of the XKB symbols files could be removed. (It may also be time to remove the obsoleted xkbcomp/keymap files.) Ivan Pascal is most familiar with this area and may have other ideas/comments/plans. David _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
