Improved compatibility with Mac

[mdevaev]

Using HID-Project on Mac was associated with two very big problems. This patch solves both - for the boot mouse and the absolute mouse. I believe these fixes could be relevant for other devices, but I have only dealt with these two.

1. When using any HID-Project mouse in Recovery Mode, Mac does can see it at the kernel level (that is, the cursor moves), but at the same time it asks connecting the mouse (which is already connected). The fact is that checking for the connected mouse is performed in a very stupid way: by searching for USAGE(Pointer) in the descriptors. Hardware mouse always (or almost always) have this, so adding this to the descriptor solves the problem. Details here and here. I added this for absolute and boot mouses and it generally improves compatibility. It probably makes sense to do this for all mouses.

2. Another problem is that Apple UEFI (it uses another driver) could not work with BootMouse at all because it did not see it. It turned out that he needed a response to the HID_HID_DESCRIPTOR_TYPE request (which is strange, since we are already passing this descriptor in the interface). This is really part of the HID standard, and hardware mouse respond to this. Usually the BIOS and other things do not require this, but Apple UEFI turned out to be finicky.

I also added a bit of protocol and idle processing. It is better to let it be than not to be.

This patch is the result of my work with the hardware USB protocol analyzer. To understand the subtleties of Apple drivers, I compared how the Arduino behaves and how a "live" mouse works. All this is tested, of course.

[mdevaev]

Sorry for my terrible English, I'm very sleepy while writing this issue :)

[NicoHood]

Thanks a lot for sending this in!

It looks like you've got very good equipment and knowledge about USB (as much knowledge as you can have with that very weird spec + try &error). Would you mind having a look at these issue with the bootkeyboard? Maybe you have also a device that does not work, and the knowledge to fix that as well?

#34
#225

[mdevaev]

Thanks!

To solve these problems, I need samples of problematic devices. Everything works perfectly on all the motherboards I have. I am aware of the problems with KVM, but not with the BIOS. Your library is used by many thousands of people through my project, and none of them said that there are problems with the BIOS and keyboard in the Arduino. On the contrary, I recommend Arduino for crappy BIOSes if the Linux Gadget does not work well.

I'll keep you posted. I'm even interested in finding out what's wrong there myself. If I get my hands on a broken device, I will investigate it and let you know. If you need anything, you can write to me by email [email protected] or discord https://discord.gg/bpmXfz5

[NicoHood]

What is the project you are working on?

Did you notice my comments to the code?

[mdevaev]

I'm doing this, and hardware for it.

I responded to your comments in the review. Don't you see them?

[Bugerman21]

Hi All,
One year ago I have used this library on Leonardo, to simulate keystrokes on the keyboard from windows, boot menu, and BIOS, and check Caps Lock led status.
Now, I flow a similar problem with a new BIOS on Dell laptops.
When I am entering the boot menu or the BIOS, the laptop did not get from Leonardo a keystrokes.

Maybe this will help to someone for investigating the problem.
At this moment I found this solution that works with UNO:
I am sending commands from Leonardo to UNO.
https://www.instructables.com/How-to-Make-a-Arduino-HID-Keyboard/

[NicoHood]

This would possibly be the better solution:
#225