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

[Ivan Quitschal]

> 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 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> 
> 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

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

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

[Vladimir Kondratyev]

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 
#include 

#include 
#include 
#include 
#include 

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

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

[Ivan Quitschal]

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

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

[Ivan Quitschal]

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

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

[Vladimir Kondratyev]

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 

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

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

[Michael Gmelin]

On Mon, 27 Jun 2022 16:18:58 +
Ivan Quitschal  wrote:

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

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

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

[Ivan Quitschal]

> 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

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

[Michael Gmelin]

On Mon, 27 Jun 2022 15:19:28 +
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?

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

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

[Warner Losh]

On Mon, Jun 27, 2022 at 9:27 AM Hans Petter Selasky  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

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

[Hans Petter Selasky]

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.


--HPS

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

[Ivan Quitschal]

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