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

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

[Heinrich Schuchardt]

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?

Best regards

Heinrich

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

[Rob Clark]

On Wed, Oct 25, 2017 at 3:45 PM, Heinrich Schuchardt <xypron.glpk@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..

BR,
-R

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

[Simon Glass]

Hi Heinrich,

On 6 November 2017 at 18:36, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, Oct 25, 2017 at 3:45 PM, Heinrich Schuchardt <xypron.glpk@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..

Yes that seems right to me. I focussed originally on things I could
try on hardware, but we can do this with tests.

Regards,
Simon

[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@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@all, unless someone really needs it. 
Then they can implement it :).


Alex