Date: Wed, 1 Mar 2006 18:45:32 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: cvs-src@freebsd.org, Scott Long <scottl@samsco.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/kbdmux kbdmux.c Message-ID: <20060301184532.A58089@newtrinity.zeist.de> In-Reply-To: <bb4a86c70602271433g6a546df1iba2bbc9719039640@mail.gmail.com>; from maksim.yevmenkin@gmail.com on Mon, Feb 27, 2006 at 02:33:52PM -0800 References: <200602252159.k1PLxT8G036312@repoman.freebsd.org> <4400D478.7060707@samsco.org> <bb4a86c70602251443i13879a2cw979596c60b86cd70@mail.gmail.com> <20060227194350.A57612@newtrinity.zeist.de> <bb4a86c70602271433g6a546df1iba2bbc9719039640@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 27, 2006 at 02:33:52PM -0800, Maksim Yevmenkin wrote:
> On 2/27/06, Marius Strobl <marius@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060301184532.A58089>