Den 20.02.2021 18.27, skrev Noralf Trønnes:
Den 19.02.2021 22.42, skrev Peter Stuge:
More generally it's not very typical in USB to report the data size separately from the data itself, if reporting size explicitly at all.
Sizes can be part of the data structure itself (like in descriptors) but on the application layer (like here) it's convenient to just decide a sensible fixed maximum size and let the host try to always transfer that size while accepting short transfers. Unlike read() a short transfer only ever happens if and when a device intends for it, so that's like an in-band handshake but "for free".
Oh, and does/should the GUD EDID change if the panel "behind" the device CPU on a hotpluggable connector changes? It wouldn't be great to require GUD driver reprobe in that case. But maybe DRM requires that anyway?
If gud_connector_status_req.status has changed since last poll or GUD_CONNECTOR_STATUS_CHANGED is set, DRM will notify userspace which will reprobe the connector. connector->epoch_counter++ in gud_connector_status_request() triggers that.
I'm sorry I didn't spot this pattern earlier, I understand that it's late in the game and that changing it needs the gadget to change as well, but I do really think this is a worthwhile change throughout the protocol.
I see what you mean, I'll give it a try.
Peter, please have a look at this diff and see if I'm on the right track here: https://gist.github.com/notro/a43a93a3aa0cc75d930890b7b254fc0a
I want to avoid waisting a patch version cycle by being way off.
Noralf.