-
-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HID OUT Report to the Pluggable HID (Keyboard Leds) #3820
Comments
This function was successfully added here: Notice that I removed the nodes and added the whole HIDDevice class as "node". This gives us the option to read more data (reportID etc) and execute virtual functions such as the setReportData. This method also uses less flash and less ram. The virtual function adds something back again, so it doesnt matter much. The SendReport can now be used via inherited parent. The device no longer need to see the HID instance. This also avoids mistakes in a wrong reportID since its taken by the internal saved ID. The saved reportID could also help you to generate a unique ISERIAL ID. That problem solved as well. (or at least given an option to do so) Some data in the HIDDevice is public to access it via the linked list pointer. It is inherited private, so the user cannot accidentally access this data. If desired one could add getters for this data but I dont think that someone what to read it, its known at compiletime via #define. This fix was added in a later commit. Most HID_ class variables and functions are now made static. I hided them from the user by making them private and a friend of the HIDDevice. This way noone can access this, even though noone ever will. Just for the purpose of good code. But we could then remove the instance and use HID_::variable/function to call those static members instead of a singleton we need to add.
An example for testing is provided. You should be able to copy the while "HID" folder in my repo. Every modification should be compatible with the internal Arduino library. You need to update the Keyboard and Mouse API though. Example in this commit: |
I want to note, that my code now also supports the boot protocol for keyboard. More infos here: |
Hi Nico, I took a look at your code and wow, some fixes are very clever (the However, consider that In fact, the main purpose of all the PluggableUSB stuff is to enable devs who want to hack with USB stuff to do this easily without touching the core. From my point of view you are doing a great job by pushing the limits of this implementation, but since you can achieve all this without touching the core I'd suggest you to publish your library (which will, in fact, become the de facto USB library) in the Lib Manager while keeping the base If you will need, at some points, more invasive changes I'll be glad to review and merge them 😉 |
Sure. I am aware that you'd have to change the whole Pluggable HID again. Since 1.6.6 is not out there, it would still be a chance to do so. That would save me the wrapper/copy. However I think I will always reach a limit where I do need to change the HID library. For example I will maybe add different HID devices (via new endpoint instead of multireport) to get things like RAW HID working. There is still more stuff to do and to fix. Maybe some fixes can be backported. But you are right, the base library should be kept simple and working. I just thought that some cosmetic things could be changed in the base HID as well, to not have two whole different HID structures. For example my HID Project will now only work for AVR because of this reason. I will publish my library to the library manager when its time to. The current real problem is, that I need .a linkage for my library to work. Right now I use a custom patched IDE. But this IDE is getting older and older, since we now have a new compiler (written in GO). I am more or less waiting for those two PRs to be reimplemented in the new compiler: I really need help with this, if you want to see the HID-Project in a non beta state. |
Closing this as it just adds some overhead that most people dont need. BootKeyboard in the current HID Project now supports such things. You just cant create an API with tons of features but keep it small, so thats fine like this. |
It would be nice to be able to check the keyboard leds with the pluggable HID. This would also make RAW HID possible as well (receiving from the Host).
Good Resources:
https://github.com/NicoHood/HID/blob/345dc26257238f8d361d1bed4b56d9d2114c4e99/avr/cores/hid/USB-Core/HID.cpp#L152-L166
https://github.com/NicoHood/HID/blob/345dc26257238f8d361d1bed4b56d9d2114c4e99/avr/cores/hid/USB-Core/HID.h#L172-L218
https://github.com/PaulStoffregen/cores/blob/master/teensy3/usb_dev.c#L483-L488
The code above should better use the wIndex value:
https://github.com/abcminiuser/lufa/blob/master/Demos/Device/LowLevel/KeyboardMouse/KeyboardMouse.c#L146-L156
Also see this:
https://github.com/abcminiuser/lufa/blob/master/Demos/Device/LowLevel/GenericHID/GenericHID.c#L148
This needs to be implemented here:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/HID/HID.cpp#L126-L130
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/USBAPI.h#L160-L168
https://github.com/abcminiuser/lufa/blob/master/LUFA/Drivers/USB/Class/Device/HIDClassDevice.c#L54
Maybe we could change the pluggable HID this way, that you pass the whole class (this) as pointer and make a function getDescriptor() with the friends attribute, that only the HID class can access it and nothing else? This way we do not need to save pointers for every value (like reportID etc) and also the HIDDescriptor pointer would be not needed anymore. That would require a parent class with virtual functions.
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/HID/HID.h#L47-L57
CC @facchinm
Also a quick question:
Why didnt you put
extern HID_ HID;
inside the HID header, so that the other libraries can include this and do not need to dupe this code? Is it because the user should not accidentally see the HID instance?Edit: I am currently working on a patch! Updates coming soon!
The text was updated successfully, but these errors were encountered: