gud icon indicating copy to clipboard operation
gud copied to clipboard

Operation on low-speed USB

Open cnlohr opened this issue 1 year ago • 3 comments

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?

cnlohr avatar Oct 16 '24 09:10 cnlohr

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 usb_sg_init() does not support control requests otherwise it would have been trivial to implement. From a quick look at the docs it seems that usb_submit_urb() should be able to handle scatter/gather control transfers.

Unfortunately not something I have the time to work on.

notro avatar Oct 16 '24 19:10 notro

very niche use case

Rethinking this, it could simplify implementing the protocol where the pixel transfer isn't big like in tiny displays and e-ink/monochrome displays.

notro avatar Oct 16 '24 20:10 notro

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.

cnlohr avatar Oct 16 '24 20:10 cnlohr