Den 20.02.2021 18.27, skrev Noralf Trønnes:

Den 19.02.2021 22.42, skrev Peter Stuge:

quoted

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.

quoted

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.