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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
