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

112 views
Skip to first unread message

Ivan Quitschal

unread,
Jun 27, 2022, 11:21:52 AM6/27/22
to freebsd...@freebsd.org, wu...@freebsd.org

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?

 

Thanks

 

--tzk

 

Hans Petter Selasky

unread,
Jun 27, 2022, 11:28:54 AM6/27/22
to Ivan Quitschal, freebsd...@freebsd.org, wu...@freebsd.org
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.

--HPS

Warner Losh

unread,
Jun 27, 2022, 11:38:58 AM6/27/22
to Hans Petter Selasky, Ivan Quitschal, freebsd...@freebsd.org, wu...@freebsd.org
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

Michael Gmelin

unread,
Jun 27, 2022, 11:44:34 AM6/27/22
to Ivan Quitschal, freebsd...@freebsd.org, wu...@freebsd.org
Did you set hw.usb.usbhid.enable="1" in /boot/loader.conf, or by using
the sysctl? If you don't do it yet, I'd recommend the former.

Cheers
Michael

>
> Thanks
>
> --tzk
>



--
Michael Gmelin

Ivan Quitschal

unread,
Jun 27, 2022, 12:21:06 PM6/27/22
to Hans Petter Selasky, freebsd...@freebsd.org, wu...@freebsd.org, gre...@freebsd.org, i...@bsdimp.com

> 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.

>--HPS


Hi Michael

Yes , hw.usb.usbhid.enable="1" is in loader.conf , not sysctl

Hi Warner

When ums.ko is up, the second attach is always taken by "ums" first no matter what. First time you boot tho, it takes the correct one (hms)

Hi Hans

Looks like this below is the only order I could make it work even tho uhid and usbhid get loaded regardless what I put on loader.conf

usbhid_load="NO" <-- still loaded anyway
uhid_load="NO" <-- still loaded anyway
ums_load="NO" <- this one is not loaded
ic_load="YES"
iichid_load="YES"
hidbus_load="YES"
hsctrl_load="YES"
hidmap_load="YES"
hcons_load="YES"
hkbd_load="YES"
hms_load="YES"
hmt_load="YES"
hconf_load="YES"

hw.usb.usbhid.enable="1"

with the order below , after 5 reboots and lots of kvm switches , it always ended up on the right iichid device. Seems to be working now

but like I said, its random, let see after some more reboots if this rule is still valid

thanks

Ivan

Michael Gmelin

unread,
Jun 27, 2022, 12:29:34 PM6/27/22
to Ivan Quitschal, Hans Petter Selasky, freebsd...@freebsd.org, wu...@freebsd.org, gre...@freebsd.org, i...@bsdimp.com
I don't know if it makes any difference in your case, but I had best
results loading these drivers through rc.conf, e.g.:

sysrc kld_list+="hidraw hkbd"

Cheers
Michael

--
Michael Gmelin

Vladimir Kondratyev

unread,
Jun 27, 2022, 1:01:27 PM6/27/22
to Ivan Quitschal, freebsd...@freebsd.org
On 27.06.2022 18: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 <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?
>
> Thanks
>
> --tzk

It seems that usbhid's bus probe priority must be increased from
BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1

Test this patch:

diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
index fe53f11b8f4..174e1c28ae9 100644
--- a/sys/dev/usb/input/usbhid.c
+++ b/sys/dev/usb/input/usbhid.c
@@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
return (ENXIO);

- return (BUS_PROBE_GENERIC + 1);
+ return (BUS_PROBE_DEFAULT + 1);
}

static int



--
WBR
Vladimir Kondratyev

Ivan Quitschal

unread,
Jun 27, 2022, 1:50:15 PM6/27/22
to Vladimir Kondratyev, Ivan Quitschal, freebsd...@freebsd.org


On Mon, 27 Jun 2022, Vladimir Kondratyev wrote:
>
> It seems that usbhid's bus probe priority must be increased from
> BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1
>
> Test this patch:
>
> diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
> index fe53f11b8f4..174e1c28ae9 100644
> --- a/sys/dev/usb/input/usbhid.c
> +++ b/sys/dev/usb/input/usbhid.c
> @@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
> if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
> return (ENXIO);
>
> - return (BUS_PROBE_GENERIC + 1);
> + return (BUS_PROBE_DEFAULT + 1);
> }
>
> static int
>
>
>
> --
> WBR
> Vladimir Kondratyev
>


Hi Vladimir,

Looks like the patch did the job. After 5 reboots with 3 detachs each , no
problem occurred.

looks like its fixed now, in case it happens again ill send another email.

thank you / all

--tzk

PS: i removed all module_loads from loader.conf in order to perform the test

Ivan Quitschal

unread,
Jun 28, 2022, 3:01:18 AM6/28/22
to Vladimir Kondratyev, freebsd...@freebsd.org


On Mon, 27 Jun 2022, Vladimir Kondratyev wrote:
>
> It seems that usbhid's bus probe priority must be increased from
> BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1
>
> Test this patch:
>
> diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c
> index fe53f11b8f4..174e1c28ae9 100644
> --- a/sys/dev/usb/input/usbhid.c
> +++ b/sys/dev/usb/input/usbhid.c
> @@ -802,7 +802,7 @@ usbhid_probe(device_t dev)
> if (hid_test_quirk(&sc->sc_hw, HQ_HID_IGNORE))
> return (ENXIO);
>
> - return (BUS_PROBE_GENERIC + 1);
> + return (BUS_PROBE_DEFAULT + 1);
> }
>
> static int
>
>
>
> --
> WBR
> Vladimir Kondratyev
>

Hi Vladimir / All,

Just a question in case you guys know how.
Problem is fixed , nothing about that, but after the keyboard is detached and reattached , I
always have to do another "kbdcontrol -r fast" myself for it to get back to the speed I use.
I've tried to call this command from within devd.conf alongside moused, but no success.
Any ideas ?

Thanks again for fixing the attach priority

Thanks

--tzk

Vladimir Kondratyev

unread,
Jun 28, 2022, 6:03:51 AM6/28/22
to freebsd...@freebsd.org
On 28.06.2022 09:59, Ivan Quitschal wrote:
>

> Hi Vladimir / All,
>
> Just a question in case you guys know how.
> Problem is fixed , nothing about that, but after the keyboard is detached and reattached , I
> always have to do another "kbdcontrol -r fast" myself for it to get back to the speed I use.
> I've tried to call this command from within devd.conf alongside moused, but no success.
> Any ideas ?
>

May be DE overrides repeat rate for you?

Anyway, it is possible to change repeat rate through evdev interface.
Following snippet of code illustrates a way to do that:


#include <sys/ioctl.h>
#include <dev/evdev/input.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void
usage(void)
{
printf("usage: eviocresp /dev/input/event0\n");
}

int
main(int argc, char** argv)
{
int fd = 0;
int rep[2] = {0, 0};

if (argc < 2) {
usage();
exit(0);
}

if ((fd = open(argv[1], O_RDWR)) < 0) {
perror("unable to access file, exiting");
exit(1);
}

/* get current auto-repeat args. */
if (ioctl(fd, EVIOCGREP, rep)) {
perror("unable to set delay and repeat rate for input devices");
exit(1);
}

/* set auto-repeat rate as 0. */
rep[1] = 0;

if (ioctl(fd, EVIOCSREP, rep)) {
perror("unable to set delay and repeat rate for input devices");
exit(1);
}

printf("rep[0]:%d;rep[1]:%d\n", rep[0], rep[1]);
close(fd);
}



--
WBR
Vladimir Kondratyev

Ivan Quitschal

unread,
Jun 28, 2022, 9:17:38 AM6/28/22
to Vladimir Kondratyev, freebsd...@freebsd.org
Hi Vladimir,

Worked , i think i will try to implement it within /usr/src/sys/dev/usb/input/
as soon as I find out where exactly : )

for now I made this and its working great now:
I compiled your code and copied to:
/usr/local/bin/eviocresp

In /etc/devd.conf

notify 100 {
match "system" "DEVFS";
match "subsystem" "CDEV";
match "type" "CREATE";
match "cdev" "input/event[0-9]+";

action "/usr/local/sbin/moused -m 2=3 -p /dev/$cdev -I /var/run/moused.`echo $cdev | cut -c 7-`.pid";
action "/usr/local/bin/eviocresp /dev/$cdev";
};

detach 100 {
device-name "hms[0-9]+";
action "/bin/pkill moused"; <-- this part is need for the reason explained below
};

BUG:
I had to put the following in rc.local since the first moused loaded always have the cursor
"shaking" in the screen, even with the actual mouse totally stopped.

rc.local:

pkill moused
for file in /dev/input/event[0-9]*; do
/usr/local/sbin/moused -m 2=3 -p $file -I /var/run/moused.`echo $file | cut -c 12-`.pid
Done

I don’t know why, but moused only gets its cursor pointer on screen "not shaking" (I mean not moving) on the second
moused execution, you need to pkill and run it again in order to work properly. Maybe it's getting attached to
the wrong /dev/event* on the first run. On the first run , I always have 4 moused processes , after I pkill and re-run it
I only get 2 (that’s when it works properly)

That I'm pretty sure it’s a bug, right?

Well, now I can attach and detach the mouse and keyboard as much as I want and everything remains the same
Thank you again

--tzk

Reply all
Reply to author
Forward
0 new messages