On 2023-08-27 19:32 +03:00, Heinrich Schuchardt wrote: > Am 27. August 2023 16:56:51 MESZ schrieb Alper Nebi Yasak > <[email protected]>: >> 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.
