Skip to content

Conversation

@RetiredWizard
Copy link
Contributor

I believe to properly work with non BOOT mice, the kernel driver detach/attach commands need to be called using the USB interface index of the mouse.

This PR adds the mouse interface index to the attributes of the BootMouse class and uses the index to detach the kernel driver before configuring the mouse.

@RetiredWizard RetiredWizard marked this pull request as draft December 2, 2025 05:24
@RetiredWizard RetiredWizard marked this pull request as ready for review December 2, 2025 07:00
@RetiredWizard
Copy link
Contributor Author

It seems the interface usage of HID devices that have multiple interfaces (combo keyboards) is somewhat random. My initial testing indicating that just detaching/reattaching the interface returned would work. It didn't take too much use before I found instances that I needed to check all the interface up to the returned interface. After a fair amount of use/testing I found that sometimes the third interface needed to be checked as well.

The bottom line is that the current version of this checks the first 3 interfaces for report mice. The code is still using the returned interface for boot mice which I think is always going to be 0 so it's possible the BootMouse class doesn't need to have the interface added as an attribute after all (which was the original purpose of this PR), but this seems to be working now and I don't think using the class attribute for boot mice is actually wrong.

If on review someone believes that boot mice should simply check interface 0, I can put that back in place and remove the interface from the BootMouse class again.

@RetiredWizard
Copy link
Contributor Author

The BootMouse class currently maintains a single boolean to indicate that a kernel driver was attached. The atexit callbacks that I've been using check the flag and if it's True then check the first three interfaces on the device and reattach any that are not active.

This procedure has been working in all the combination of tests I've been running however I don't know if there is a type of HID device that has interfaces that would not be happy having the attach_kernel_driver method being called.

A more precise approach would be to use a list for the was_attached attribute so that only interfaces that were attached and are not currently active would have the attach_kernel_driver method called.

I'm not sure the change is necessary though?

@RetiredWizard
Copy link
Contributor Author

I decided to ask ChatGPT about the two issues that were worrying me. Using the interface index rather than 0 for boot mice and using a single was_attached boolean.

Understanding that I haven't confirmed the ChatGPT conclusions with direct documentation research, I think it's recommendations lines up with the way I was leaning.

ChatGPT indicated that the order of kebyoard/mouse on the USB interfaces for a boot mouse is not guaranteed so using zero is probably not a good idea. It also suggested that reattaching all three interfaces would likely work but it would be a better solution (cleaner and more efficient) to utilize a list for was_attached. It also indicated that in some rare situations calling attach_kernel_driver() unnecessarily could cause errors or hang the device.

I'm going to go ahead and update this PR to include a list for was_attached. Until that's complete and tested I'll switch this to draft status.

@RetiredWizard RetiredWizard marked this pull request as draft December 3, 2025 19:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant