On 19/11/2019 17:06, Tony Lindgren wrote:

The userspace apps need to do this. If they're using single-buffering, then
using the dirtyfb ioctl should do the trick, after the SGX has finished
drawing.

Sounds like that's not happening.

But why would the userspace app need to know this might be needed for
a DSI command mode display and that it's not needed for HDMI?

When double-buffering, the userspace doesn't need to care, as the page-flip ioctl explicitly tells that the buffer is ready.

When single buffering, either the userspace has to tell that the buffer is now ready, or the kernel has to guess based on something. But afaics, the latter is always a guess, and may not be a good guess.

The kernel could trigger a delayed update based on, say, page fault if drawing with CPU. But how much delayed... And with this scenario, we would somehow need to find a way to catch the writes from any IP to the buffer, and afaik there's no such thing.

It's probably somewhat difficult if EGL is controlling the display, as,
afaik, SGX EGL is closed source, and that's probably where it should be
done.

But adding back the hacky omap gem sync stuff, and then somehow guessing
from the sync finish that some display needs to be updated... It just does
not sound right to me.

Right it's ugly. Still sounds like we need something in the kernel
that knows "this is a DSI command mode LCD and needs to be updated".

I think one option is to refresh the command mode display all the time. Either using a timer, or trigger updates based on the previous update being finished.

Of course, that's kind of against the whole point of manual update display, but then it should effectively behave like a conventional always-updating display (except your HW is more expensive and consumes more power than a conventional display).

There's this Panel Self Refresh feature in DisplayPort (which I think is implemented in drm_self_refresh_helper.c), which has some similarities to this case. But if I read it right, that also expects some kind of trigger from userspace (any DRM commit) to start the refresh.

Afaik, Weston and X both handle page flips and/or dirtying the fb, so they should work. Are there applications that do not work, and cannot be made to work, except the few SGX test apps?

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to