cvs commit: src/sys/dev/kbdmux kbdmux.c

[Marius Strobl]

On Mon, Feb 27, 2006 at 02:33:52PM -0800, Maksim Yevmenkin wrote:
> On 2/27/06, Marius Strobl <marius at alchemy.franken.de> wrote:
> > On Sat, Feb 25, 2006 at 02:43:11PM -0800, Maksim Yevmenkin wrote:
> > > Scott,
> > >
> > > [...]
> > >
> > > > So what do we need to do to get this enabled and running by default and
> > > > get rid of the USB keyboard hack in the loader, as well as make the
> > > > keyboard flags sane and predictable?
> > >
> >
> > <...>
> >
> > >
> > > i think this should do it. any comments?
> > >
> >
> > FYI, in order to make kbdmux(4) work on sparc64 the endian bugs in
> > the keyboard IOCTLs of syscons(4) and probably elsewhere need to
> > be fixed. In order to make it work with Sun RS232 keyboards (sparc64
> 
> could you please point me to the keyboard ioctl with the endian bugs
> you are talking about?

KBADDKBD, KDSETLED, probably some others don't work. E.g. trying to
configure kbdmux(4) for an AT and a USB keyboard with kbdcontrol(1)
on sparc64 I get:
follow# kldload kbdmux
follow# kbdcontrol -a ukbd0 < /dev/kbdmux0
kbd2
    kbdmux0, type:AT 101/102 (2)
WARNING pid 545 (kbdcontrol): ioctl sign-extension ioctl ffffffff80244b44
follow# kbdcontrol -k < /dev/kbdmux0 < /dev/ttyv0
kbd2
    kbdmux0, type:AT 101/102 (2)
kbdcontrol: unable to (un)mux the keyboard: Invalid argument
follow# kbdcontrol -a atkbd0 < /dev/ttyv0
kbd0
    atkbd0, type:AT 101/102 (2)
WARNING pid 547 (kbdcontrol): ioctl sign-extension ioctl ffffffff80244b44
kbdcontrol: unable to (un)mux the keyboard: Operation not supported by device
follow#

I think this is the same type of problem that was fixed for some other
IOCTLs in sys/dev/syscons/syscons.c rev. 1.403.

> 
> > uses AT, Sun RS232 and USB keyboards) kbdmux(4) needs to get rid of
> > the assumption that a slave keyboard driver returns AT keyboard
> > scancodes in K_RAW mode. The latter probably also applies to powerpc
> > once there is support for ADB keyboards.
> 
> imo, that is not just kbdmux(4) assumption. it seems like a more
> general assumption, i.e. ukbd(4), for example, translates usb
> scancodes into at scancodes by default.
> 
> we should make a decision which scancodes keyboard drivers should be
> returning and change kbdmux(4), syscons(4) etc. to support it.
> 

As others already pointed out the USB scancode set probably would be
a good choice for this. Unlike the AT scancode set it at least seems
to support a superset of the keys available on ADB, AT and Sun key-
boards.
Btw., do you know how the NetBSD keyboard multiplexing deals with
this? According to the xorg-server sources they use the respective
native scancodes for all of ADB, AT, USB and Sun keyboards.

> until then, i'm afraid, sun rs232 and powerpc adb keyboard drivers
> will have to translate their own scancodes into at scancodes (just
> like ukbd(4) does).
> 

I think it isn't worth the effort to change sunkbd(4) to translate
to AT scancodes until there's a final decision what scancode set
to use as it also means creating special keyboard rules for XKB to
make the Sun-specific keys work again in X and probably breaks POLA
when users have to change their xorg.conf in a stable branch in
order to make the keyboard work again.
Could you maybe change ukbd(4) to set its keyboard type to KB_101
when compiled with UKBD_EMULATE_ATSCANCODE and kbdmux(4) to only
accept KB_101 keyboard drivers (looks like atkbd(4) with KB_84
keyboards also won't work with kbdmux(4) anyway) as an interim
solution?

Marius

-- 
This mail was scanned by AntiVir Milter.
This product is licensed for non-commercial use.
See www.antivir.de for details.