From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: kettenis@openbsd.org, u-boot@lists.denx.de, agust@denx.de,
agraf@csgraf.de
Subject: Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support
Date: Fri, 17 Sep 2021 13:29:06 +0200 [thread overview]
Message-ID: <77fcfc8f-ecb6-d503-66b2-d4015b04072e@gmx.de> (raw)
In-Reply-To: <561465f19c71ab5c@bloch.sibelius.xs4all.nl>
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 */
>>>
>>
>>
next prev parent reply other threads:[~2021-09-17 11:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 13:01 [PATCH 0/3] 30bpp framebuffer support Mark Kettenis
2021-09-16 13:01 ` [PATCH 1/3] video: Add 30bpp support Mark Kettenis
2021-09-25 13:40 ` Simon Glass
2021-09-25 16:55 ` Mark Kettenis
2021-09-16 13:01 ` [PATCH 2/3] efi_loader: GOP: " Mark Kettenis
2021-09-17 2:56 ` Heinrich Schuchardt
2021-09-17 9:23 ` Mark Kettenis
2021-09-17 11:29 ` Heinrich Schuchardt [this message]
2021-09-17 12:41 ` Mark Kettenis
2021-09-25 13:40 ` Simon Glass
2021-09-16 13:01 ` [PATCH 3/3] video: simplefb: " Mark Kettenis
2021-09-25 13:41 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77fcfc8f-ecb6-d503-66b2-d4015b04072e@gmx.de \
--to=xypron.glpk@gmx.de \
--cc=agraf@csgraf.de \
--cc=agust@denx.de \
--cc=kettenis@openbsd.org \
--cc=mark.kettenis@xs4all.nl \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).