[U-Boot] [RFC] efi_loader: frame buffers in EFI GOP and DM_VIDEO
Simon Glass
sjg at chromium.org
Tue Nov 7 13:28:39 UTC 2017
Hi Heinrich,
On 6 November 2017 at 18:36, Rob Clark <robdclark at gmail.com> 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..
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
More information about the U-Boot
mailing list