Replies: 2 comments
-
|
Quick follow up: My approach only seemed to work but really didn't. It took me a while and many many reboots to figure out the reason. Apparently, at the time rc.local gets called / executes the command, usbhid isn't "enabled" by the kernel yet, hence the command doesn't seem to work. That might differ depending on the hardware configuration (speed of hdd/ssd/nvme and cpu). sleep 3 to make the command work. But I have to do some more testing because the issue this command is intended to solve doesn't occur at every (re)boot. So it's hard to tell if the command did work or the issue simple didn't occur. As an alternative I modified zfsbootmenu's xhci teardown script (/usr/share/zfsbootmenu/hooks/teardown.d/90-xhci-unbind.sh) to target usbhid instead of xhci_hcd and let rc.local execute the script. But it, too, required the 3s pause to be successful. |
Beta Was this translation helpful? Give feedback.
-
|
Another follow-up. The command to unbind and then bind again usbhid using rc.local worked for the intended purpose but meanwhile I circumvented the underlying issue on a hardware-basis, making the software workaround unnecessary. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Having again an issue with a frozen mouse pointer since a few kernel versions back and the linux team not really interested to fix the issue (probably due to me not being able to test mainline because of zfs) I decided to "fix" the issue by "restarting" the usb device or its bus/driver during boot.
The idea initially came from zfsbootmenu's xhci teardown script (/usr/share/zfsbootmenu/hooks/teardown.d/90-xhci-unbind.sh). That unfortunately doesn't help me at the time zbm executes the script, but generally the idea seems ok.
I searched for different approaches to get the job done, but many ddn't work. I was looking for a solution that only targets the specific device (mouse) and not a complete controller, but the commands I tested didn't work.
At first I tested adding a script to lightdm, but that results in the script being executed every time lightdm is executed, i.e. even when logging out or login after suspend, which is unnecessary - once per boot is enough.
So, I opted for rc.local.
Adding the command of the modified (added lines to bring the controller back up) teardown script from zbm works, but seems a bit drastic for my taste (to target the controller).
So, I opted for using modprobe on usbhid which seems to work so far. I'm just wondering if that is a suitable solution or a "no no".
That would be the question: Is this ok or would there be a better way to do that?
The two lines added to rc.local are:
modprobe -r usbhid
modprobe usbhid
Beta Was this translation helpful? Give feedback.
All reactions