-
Notifications
You must be signed in to change notification settings - Fork 9
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
Operation on low-speed USB #27
Comments
I would accept patches to add support for that as long as it doesn't add lots of code to handle this very niche use case. Unfortunately not something I have the time to work on. |
Rethinking this, it could simplify implementing the protocol where the pixel transfer isn't big like in tiny displays and e-ink/monochrome displays. |
That's very true. All USB classes can use reports, and the logic device-side to handle them is usually very, very simple. And for me, this was to add support for a 128x64 LCD display, I am currently using HIDAPI to update. EDIT: Just FYI to note: You are allowed to use control transfers of much greater than the max packet size. I.e. in my demo on a low speed device, I use 1080 byte control transfers, and everything works fine. I can easily write firmware and test things, but I don't have a lot of experience with the kernel, and it's been about 9 years since I last compiled a desktop kernel. |
There's a lot of options for running on low speed devices especially in unusual situations, i.e. grainuum, v-usb, rv003usb, where only control and interrupt transfers are possible, but control transfers can be extremely fast (typically 400-500kbit/s) and support arbitrarily large payloads.
Any hope of allowing video updates via control transfers instead of requiring bulk endpoints?
The text was updated successfully, but these errors were encountered: