On Tue, Jul 14, 2020 at 09:03:14PM +0200, Noralf Trønnes wrote: > > > Den 14.07.2020 19.40, skrev Peter Stuge: > > Hi Noralf, > > > > Noralf Trønnes wrote: > >> I would like to keep the SET_BUFFER request since it will serve as a > >> syncing point between the host and the device. I'm no USB expert but I > >> assume that a bulk transfer can fail halfway through and result in the > >> next update starting where the previous one failed and thus writing > >> beyond the end of the display buffer. > > > > Transfers either succeed completely (possibly after many retries), > > time out (after zero or more transfered bytes) or fail catastrophically > > (e.g. from device disconnect). > > > > In all cases, the driver on the host knows/has available how many bytes > > were successfully transfered. > > > > I was thinking about the device, that it could get out of sync. Let's > say the host sends a 1k framebuffer and half of it gets transferred and > the rest fails for some reason. Lubomir's MCU implementation has an > endpoint max size of 64 bytes and a callback is called for each packet. Note that 64 bytes was chosen totally arbitrarily, without any thought. Perhaps the full frame of 1024 bytes would work just fine. I'm not familiar with USB at all. > If the 1k transfer fails at some point, will the device be able to > detect this and know that the next time the rx callback is called that > this is the start of a new framebuffer update? > > Noralf. Lubo _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
