From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
deller@gmx.de, sam@ravnborg.org, hpa@zytor.com
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
stable@vger.kernel.org
Subject: Re: [PATCH] fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes
Date: Thu, 13 Jun 2024 11:57:49 +0200 [thread overview]
Message-ID: <87wmmtqi5e.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <eea40059-2692-4b1e-a92e-006908220f34@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
> Hi Javier
>
> Am 13.06.24 um 11:35 schrieb Javier Martinez Canillas:
>> Thomas Zimmermann <tzimmermann@suse.de> writes:
>>
>> Hello Thomas,
>>
>>> Test the vesa_attributes field in struct screen_info for compatibility
>>> with VGA hardware. Vesafb currently tests bit 1 in screen_info's
>>> capabilities field, It sets the framebuffer address size and is
>>> unrelated to VGA.
>>>
>>> Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in
>>> the mode's attributes field signals VGA compatibility. The mode is
>>> compatible with VGA hardware if the bit is clear. In that case, the
>>> driver can access VGA state of the VBE's underlying hardware. The
>>> vesafb driver uses this feature to program the color LUT in palette
>>> modes. Without, colors might be incorrect.
>>>
>>> The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix
>>> incorrect logo colors in x86_64"). It incorrectly stores the mode
>>> attributes in the screen_info's capabilities field and updates vesafb
>>> accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for
>>> the new x86 setup code") fixed the screen_info, but did not update vesafb.
>>> Color output still tends to work, because bit 1 in capabilities is
>>> usually 0.
>>>
>> How did you find this ?
>
> I was reading through vesafb and found that [1] and [2] look
> surprisingly similar, which makes no sense. So I started looking where
> bit 1 came from. The flag signals a 64-bit framebuffer address for EFI
> (see VIDEO_CAPABILITY_64BIT_BASE
> <https://elixir.bootlin.com/linux/latest/C/ident/VIDEO_CAPABILITY_64BIT_BASE>).
> But old VESA framebuffers are usually located within the first 32-bit
> range. So the bit is mostly 0 and vesafb works as expected.
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/vesafb.c#L274
> [2]
> https://elixir.bootlin.com/linux/latest/source/include/linux/screen_info.h#L26
>
I see. Thanks a lot for the explanation and references.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2024-06-13 9:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 9:02 [PATCH] fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes Thomas Zimmermann
2024-06-13 9:35 ` Javier Martinez Canillas
2024-06-13 9:53 ` Thomas Zimmermann
2024-06-13 9:57 ` Javier Martinez Canillas [this message]
2024-06-13 21:30 ` Helge Deller
2024-06-13 21:50 ` Javier Martinez Canillas
2024-06-13 22:24 ` Helge Deller
2024-06-14 7:23 ` Thomas Zimmermann
2024-06-14 8:09 ` Helge Deller
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=87wmmtqi5e.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=hpa@zytor.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.