On Wed, 2 Feb 2022 10:45:42 +0100 Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: > Den 02.02.2022 10.14, skrev Thomas Zimmermann: > > Hi Noralf, > > > > since you're here, I'll just hijack the discussion to ask something only > > semi-related. > > > > IIRC the gud driver doesn't update the display immediately during atomic > > commits. Instead, it instructs a helper thread to do the update. What's > > the rational behind this design? Is that something we should adopt for > > other drivers that operate over slow buses (USB, I2C, etc)? Would this > > be relevant for the ssd1307 driver? > > > > Async flushing is only necessary on multi display setups where there's > only one rendering loop for all the displays. I saw what tiny/gm12u320.c > did and Hans gave me the rationale. The SPI drivers run flushing inline. > Info on the gud wiki: > https://github.com/notro/gud/wiki/Linux-Host-Driver#asynchronous-flushing Hi, please also consider that userspace may throttle to the KMS pageflip events. If the pageflip event is immediate from submitting a flip, that could mean userspace will be repainting in a busy-loop, like 1 kHz. However, I remember something about virtual KMS drivers doing exactly this, and there being something that tells userspace to throttle itself instead of depending on pageflip completions. I just forget how that is supposed to work, and I'm fairly sure that e.g. Weston does not behave well there. Unfortunately, the pageflip event is also what synchronises FB usage. Once flipping in a new FB completed, the old FB is free for re-use. But, if the kernel is still copying out from the old FB, userspace may partially overwrite the contents, temporarily leading to an incomplete or too new image on screen. Do you have anything to prevent that? Thanks, pq
Attachment:
pgpouANDaZBXy.pgp
Description: OpenPGP digital signature
