[PATCH] efi: Correct handling of frame buffer

[Simon Glass]

Hi,

On Sun, 27 Aug 2023 at 12:41, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>
> 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...

Yay! I'd like sync to happen there. In fact I am wondering if cyclic
should have a flag indicating whether the callee has enough time to do
whatever it wants (e.g. several milliseconds) or should be very fast.

>
> > 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.

Look, the EFI API is not going to work so well here. but it is what it
is. The purpose of this patch is to make it work. Of course it will be
slow, but it isn't really noticeable to me.

Regards,
Simon