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

[Maksim Yevmenkin]

On 9/20/06, Ruslan Ermilov <ru at freebsd.org> wrote:
> On Wed, Sep 20, 2006 at 09:44:49AM -0700, Maksim Yevmenkin wrote:
> > On 9/20/06, Ruslan Ermilov <ru at freebsd.org> wrote:
> > >On Wed, Sep 20, 2006 at 09:28:46AM -0700, Maksim Yevmenkin wrote:
> > >> On 9/20/06, Ruslan Ermilov <ru at freebsd.org> wrote:
> > >> >Here's another demo that indicates that sparc64 doesn't work
> > >> >properly.  In this case it's a CONS_SETKBD ioctl which is used
> > >> >by kbdcontrol(8).  I "kldload vkbd" and make sure two vkbd
> > >> >instances exist, /dev/vkbdctl0 and /dev/vkbdctl1.
> > >>
> > >> [...]
> > >>
> > >> actually, i just tracked this down as part of my work on pr
> > >> sparc64/96798. there are few problems mentioned in this pr. kbdcontrol
> > >> -k not working is just one of them.
> > >>
> > >> basically, kb_index is wrong, and, in my case, is always 0. which
> > >> defaults to first keyboard (i.e. subkbd(4)). that is why i can not use
> > >> kbdcontrol -k to switch between sunkbd(4) and, say, ukbd(4).
> > >>
> > >Yes, this is the endianness bug we were talking about.
> > >Hold on, the fix is almost ready.  :-)
> >
> > sure, btw i think CONS_SETKBD is easy. nothing seems to calling it
> > from the kernel, so we could (intptr_t *) cast it and it should just
> > work. i really want to change it to
> >
> > #define CONS_SETKBD     _IOW('c', 110, int)
> >
> Yes, it would break both binary and source API compatibility.  No
> we cannot do it.

ok, i just tested the following patch on sparc64 and it makes
'kbdcontrol -k' work as expected. i can now switch between ukbd0 and
sunkbd0 without any problems.

--- syscons.c.orig      Fri Mar  3 16:41:28 2006
+++ syscons.c   Wed Sep 20 09:57:09 2006
@@ -1194,7 +1194,7 @@
            keyboard_t *newkbd;

            s = spltty();
-           newkbd = kbd_get_keyboard(*(int *)data);
+           newkbd = kbd_get_keyboard(*(intptr_t *)data);
            if (newkbd == NULL) {
                splx(s);
                return EINVAL;

can i commit it?

thanks,
max

p.s. yes, i know, there are few other ioctl's with the same problem. i
just want to address it one ioctl at a time :)