[PATCH] efi: Correct handling of frame buffer

[Alper Nebi Yasak]

On 2023-08-27 19:32 +03:00, Heinrich Schuchardt wrote:
> Am 27. August 2023 16:56:51 MESZ schrieb Alper Nebi Yasak <alpernebiyasak at gmail.com>:
>> On 2023-08-25 22:28 +03:00, Simon Glass wrote:
>>> so we must allow EFI to write directly to the hardware framebuffer.
>>
>> If you want a fix independent of that series, I think the proper
>> approach here is having EFI draw to fb as it already does, then copying
>> from that to copy_fb at the end of gop_blt_int().
> 
> An EFI app can write directly to the framebuffer and mix that with API calls.

Ack. Can EFI apps write to framebuffer without informing U-Boot at all?
What I meant is, copying whenever EFI asks us to modify something or
tells us it modified something.

If it can write without telling us, how are cache flushes and hardware
syncs handled? Asking these because I'm doing some weird experiments
with video damage and cyclic video_sync() calls and VIDEO_COPY...

> blt functions causing a full copy would be much slower than what you get when eliminating the copy fb.

When we expose copy_fb to EFI, don't we need to keep fb up to date,
incurring the same cost? The VIDEO_COPY description mentions "reading
from the frame buffer is slow", so whatever code is "reading" would use
fb and would get bad data otherwise. But I can't exactly point to any
examples other than the video damage series copying fb onto copy_fb.