On 9/17/21 11:23 AM, Mark Kettenis wrote:
From: Heinrich Schuchardt xypron.glpk@gmx.de Date: Fri, 17 Sep 2021 04:56:31 +0200
Hi Heinrich,
On 9/16/21 3:01 PM, Mark Kettenis wrote:
Provide correct framebuffer information for 30bpp modes.
This is not enough to get a correct GOP implementation for the 30bpp mode.
Have a look at efi_gop_pixel efi_vid16_to_blt_col() and efi_blt_col_to_vid16() and where they are used.
Ah right. This does indeed not support EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() correctly. I shouldn't be too hard to translate between XRGB2101010 and XRGB8888. Any ideas how I could test that code?
setenv efi_selftest block image transfer bootefi selftest
should show an animated submarine with yellow portholes similar to
https://gist.github.com/xypron/7e1f73408465da71e3ef946250e76776#file-sub-png
Best regards
Heinrich
Signed-off-by: Mark Kettenis kettenis@openbsd.org
lib/efi_loader/efi_gop.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c index 1206b2d7a2..42bf49b184 100644 --- a/lib/efi_loader/efi_gop.c +++ b/lib/efi_loader/efi_gop.c @@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)
switch (gopobj->bpix) {#ifdef CONFIG_DM_VIDEO
- case VIDEO_BPP30: case VIDEO_BPP32: #else case LCD_COLOR32:
@@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void) switch (bpix) { #ifdef CONFIG_DM_VIDEO case VIDEO_BPP16:
- case VIDEO_BPP30: case VIDEO_BPP32: #else case LCD_COLOR32:
@@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void) #endif { gopobj->info.pixel_format = EFI_GOT_BGRA8; +#ifdef CONFIG_DM_VIDEO
This symbol is not 30bpp specific. Is there a Kconfig variable that we can use to hide 30bpp support where it is not needed?
I quite deliberately didn't add a separate config option for 30bpp as there is very little code that is added to the already existing 32bpp code. In a sense 30bpp is just a different submode of the 32bpp support with just a different color map, so I thought it made sense to group it under CONFIG_VIDEO_32BPP. I did initially consider adding a separate config option for it, but it quickly turns into an #ifdef maze that makes it hard to understand the code.
The CONFIG_DM_VIDEO check is just there to make sure the 30bpp is only offered in the DM model. Based on recent discussions I expect the !CONFIG_DM_VIDEO case to disappear in the near feature so adding 30bpp support for the non-DM case doesn't make sense.
The EFI GOP code currently doesn't check the CONFIG_VIDEO_BPP16 and CONFIG_VIDEO_BPP32 defines to see which of these modes are enabled within U-Boot, so we don't "hide" 16bpp support on platforms that just support 32bpp either.
Which modes does the M1 support?
We're not sure. It does support at least 8-bit (32bpp) and 10-bit (30bpp) color depth modes. But the firmware tends to come up with 10-bit color depth whenever it can and I'm not planning to add support for changing the framebuffer mode on the M1, since the interface to do that is "interesting" [1].
[1] See Alyssa Rozenzweig's talk at XDC 2021, https://www.youtube.com/watch?v=uTZISTjqy9Q
- } else if (bpix == VIDEO_BPP30) {
gopobj->info.pixel_format = EFI_GOT_BITMASK;gopobj->info.pixel_bitmask[0] = 0x3ff00000; /* red */gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */gopobj->info.pixel_bitmask[2] = 0x000003ff; /* blue */gopobj->info.pixel_bitmask[3] = 0xc0000000; /* reserved */+#endif } else { gopobj->info.pixel_format = EFI_GOT_BITMASK; gopobj->info.pixel_bitmask[0] = 0xf800; /* red */