[U-Boot] [RFC] efi_loader: frame buffers in EFI GOP and DM_VIDEO

[Alexander Graf]

On 11/07/2017 02:36 AM, Rob Clark wrote:
> On Wed, Oct 25, 2017 at 3:45 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> Hello Alex, hello Simon,
>>
>> I have just been reading through efi_gop and video_uclass.c and there seems
>> to be something missing in the support of video modes.
>>
>> U-Boot configuration knows the following color models:
>>
>> 16-color
>> 256-color
>> 32k (1:5:5:5)
>> 64k (5:6:5)
>> 16.8M (8:8:8)
>>
>> In lib/efi_loader/efi_gop.c I only found
>>
>> VIDEO_BPP32
>> VIDEO_BPP16
>> Patch a812241091ce efi_loader: Add DM_VIDEO support (Alexander Graf)
>>
>> Shouldn't gop_blt differentiate between 32k and 64k color mode?
>> Unfortunately video_uclass.c cannot tell the difference!
>> What about 4 and 8 bit modes?
>>
>> When I look at the coding in video_uclass.c, function video_clear it seems
>> that this only correctly supports 32bit and 8bit mode.
>> Patch 1acafc73bfc7 dm: video: Add a video uclass (Simon Glass)
>>
>> Shouldn't 4, 15 and 16 bit modes be added here?
>>
> (apologies for being a bit behind on u-boot mails but been busy on
> other upstreams)
>
> iirc UEFI only supports a subset of what u-boot supports (and I think
> it is worse because u-boot doesn't do a good job of differentiating
> between different component orders of a given bpp).. but we could
> support more hw by not with the path that doesn't expose the scanout
> buffer address and only supports blitting to scanout buffer (and doing
> conversion as part of the blit).  I think it is mostly a matter of
> someone who has this hw writing and testing the appropriate blit
> paths..

My thinking was that the most useful bit of GOP support is efifb in 
Linux. Using that you can directly pass the frame buffer to Linux and 
use it from there, removing the need for a graphics driver in simple use 
cases and allowing early boot messages to appear on the screen.

This however only works well with 32bpp. Even 16bpp was essentially 
unused in the wild - we had to fix bugs in Linux first to actually make 
it work :). I don't think any other modes will realistically ever be 
supported.

So my base take on this is: Let's treat devices that have <16bpp depth 
as simply not having graphics at all, unless someone really needs it. 
Then they can implement it :).


Alex