Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 27 Jun 2022 15:37:02 UTC
On Mon, Jun 27, 2022 at 9:27 AM Hans Petter Selasky <hps@selasky.org> wrote:

> On 6/27/22 17:19, Ivan Quitschal wrote:
> > Hi all
> >
> > Not sure if I found a problem here but here we go.
> >
> > Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle
> it between my windows and freebsd.
> > I am using iichid here to have my multimedia keys working on keyboard
> and all
> >
> > hw.usb.usbhid.enable="1"
> >
> > Im also using Wulf's moused
> > https://github.com/wulf7/moused
> > so far so good. Problem is:
> >
> > when I switch to windows , everything is detached correctly (hms, hkbd
> etc), but when I switch back, sometimes
> > the keyboard and mouse are wrongly attached to "ums" device , not hms.
> (sometimes it goes to the correct one).
> > Shouldn't ums/uhid modules be deactivated once hw.usb.usbhid.enable is
> set to 1 ?
> >
> > The workaround I did here was to manually kldunload both uhid.ko and
> ums.ko within rc.local during boot.
> > This way I can detache attach the kbd/mouse back as much as I want and
> it always end up in hms/hkbd devices
> >
> > Is this how its supposed to function? Randomly choosing between ums or
> hms?
> >
>
> Hi,
>
> Can you dump "kldstat" at the different times?
>
> I guess it may be just be that the wrong module is loaded first, so it
> grabs the device, because there are no other drivers loaded, even though
> ums is a generic driver.
>
> Try loading all relevant drivers in /boot/loader.conf . Then the attach
> order shouldn't matter.
>

We should fix the priority of the two drivers if the order matters...

Another possibility is that the ums is loaded and hms isn't so ums wins. If
any device wins, devmatch isn't invoked to load possible drivers..

Warner