-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fix #2348 support for CapsLock/NumLock LEDs in usb_hid #2366
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
Conversation
This is work in progress. Currently the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is the right API because output reports can theoretically be used for other things besides LEDs. A better api would be a circular buffer of reports that can be read through a receive_report
function.
I agree a more general API would be more useful, but I think it will require a considerable amount of planning. How large should the buffer be? How many entries of what size? Do we pre-allocate it always? Do we let the user choose the size that fits best their use case? How can the user make an informed decision about it? I think that the particular combination of |
I'd rather not add a special API because I'm going to be doing the BLE HID library soon and it'll expose this same API. We can limit the buffer a bunch for now though. How about an 8 byte buffer that only queues 1 byte reports and return 1 byte bytestrings? When we have other reports to support we'll just make the implementation smarter. |
I like that. I could even live with just one one-byte report, because I only care about the most recent one. This would make the internals easy enough even for me to implement, and would have an API that could be expanded later when needed. Thanks! |
I tried to do a ring buffer, but it's a bit out of my depth. For now I just made a simple 1-item buffer for a single-byte report, but I updated the Python API to be what was suggested. We can change the underlying implementation later on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implementation is totally fine. Thanks for doing it! Just a couple suggestions but then it should be good to go.
I changed the interface to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Let me know when I should take another look.
@deshipu any object to me closing this until it is fixed up? |
Sorry, I didn't have time to look into this properly, I will make a new pull request when I figure this out. |
No description provided.