From: Mario Limonciello <mario.limonciello@amd.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Aaron Ma <aaron.ma@canonical.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2] PCI: vgaarb: Include 0x0380 devices in boot VGA selection
Date: Tue, 23 Jun 2026 07:16:52 -0700 [thread overview]
Message-ID: <f4eff053-d37e-4172-ba94-b9ef746b9370@amd.com> (raw)
In-Reply-To: <3045831e-bbc2-43bd-bc47-3cf720fd8a6c@suse.de>
On 6/23/26 00:32, Thomas Zimmermann wrote:
> (cc dri-devel)
>
> Hi Mario et al
>
> Am 22.06.26 um 18:09 schrieb Mario Limonciello:
>> +Thomas Zimmermann
>
> Thanks.
>
>>
>> Here is the lore link for you for full context.
>>
>> Aaron's v1: https://lore.kernel.org/linux-
>> pci/20260618081803.2790848-1-aaron.ma@canonical.com/
>> My proposal: https://lore.kernel.org/linux-
>> pci/20260621175230.1453114-1-mario.limonciello@amd.com/
>
> I saw this patch. I was slightly confused, because it says 'fbcon'.
>
>> Aaron's v2: https://lore.kernel.org/linux-
>> pci/20260622061339.3306046-1-aaron.ma@canonical.com/
>>
>> On 6/21/26 23:13, Aaron Ma wrote:
>>> Some firmware boot displays use PCI class 0x0380
>>> (PCI_CLASS_DISPLAY_OTHER). vgaarb only registers pci_is_vga()
>>> devices, so those devices are skipped by vga_is_firmware_default()
>>> and cannot become vga_default_device().
>
> I think the current behavior is correct. The vgaarb is for mediating
> VGA's hard-coded I/O addresses among multiple devices. IMHO the module
> should not manage other graphics devices.
>
> IOW, I think a fix should mostly be outside of vgaarb.c.
>
>>>
>>> On hybrid systems this can leave a discrete VGA GPU as
>>> vga_default_device() even when the firmware framebuffer is on the
>>> 0x0380 device. That makes boot_vga point at the wrong GPU and can
>>> make boot_display report multiple devices through different paths.
>
> I assume that boot_display is true for both cards because one device has
> the screen_info settings, and the other is the 'vga_default_device',
> Right?
>
>>>
>>> Register legacy VGA and 0x0380 display devices for default selection
>>> and boot_vga visibility. Keep legacy VGA decode ownership limited to
>>> pci_is_vga() devices so 0x0380 devices are not treated as legacy VGA
>>> decoders.
>>>
>>> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
>>> ---
>>> Changes in v2:
>>> - Keep legacy VGA decodes and owns limited to pci_is_vga() devices.
>>> - Keep 0x0380 devices eligible for firmware/default selection and
>>> boot_vga visibility without treating them as legacy VGA decoders.
>>> - Update the commit message to describe the boot_vga compatibility goal.
>>
>> I really think dropping the fallback path (we found nothing, so this
>> VGA thing must be it) is the right direction.
>>
>> I'd like Thomas' comments about that though.
>>
>> If we must keep that path, how about instead modify how
>> vga_is_firmware_default() works. We could instead have
>> vga_has_firmware_default() and vga_is_firmware_default() both.
>>
>> If the system vga_has_firmware_default() then no longer activate the
>> fallback path.
>>
>>>
>>> drivers/pci/pci-sysfs.c | 3 ++-
>>> drivers/pci/vgaarb.c | 27 +++++++++++++++------------
>>> include/linux/pci.h | 14 ++++++++++++++
>>> 3 files changed, 31 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>> index d37860841260c..843d83ec9550a 100644
>>> --- a/drivers/pci/pci-sysfs.c
>>> +++ b/drivers/pci/pci-sysfs.c
>>> @@ -1717,7 +1717,8 @@ static umode_t pci_dev_attrs_are_visible(struct
>>> kobject *kobj,
>>> struct device *dev = kobj_to_dev(kobj);
>>> struct pci_dev *pdev = to_pci_dev(dev);
>>> - if (a == &dev_attr_boot_vga.attr && pci_is_vga(pdev))
>>> + if (a == &dev_attr_boot_vga.attr &&
>>> + pci_is_vga_or_other_display(pdev))
>>> return a->mode;
>>
>> I really don't think we want boot_vga exported on a non-VGA device.
>> Even if the rest of the PR hangs around, this hunk I think should go.
>
> I agree. Boot_vga does not mean that there's a mode installed, but
> rather that the VGA device got posted by the BIOS/UEFI. That's clearly
> not the case for the other-display device.
>
>
>>
>>> if (a == &dev_attr_serial_number.attr && pci_get_dsn(pdev))
>>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
>>> index c360eee11dd9e..56a86779e6d28 100644
>>> --- a/drivers/pci/vgaarb.c
>>> +++ b/drivers/pci/vgaarb.c
>>> @@ -741,6 +741,7 @@ static bool vga_arbiter_add_pci_device(struct
>>> pci_dev *pdev)
>>> unsigned long flags;
>>> struct pci_bus *bus;
>>> struct pci_dev *bridge;
>>> + bool legacy_vga = pci_is_vga(pdev);
>
> Just a word on terminology. AFAIU in this context 'legacy' does not mean
> that VGA is legacy. Legacy refers to VGA's original hard-coded I/O
> ranges (e.g, 0xa0000, 0x3c2, etc.) .
>
>
>
> I think Mario's suggestion at [1] might be a better way forward than
> modifying vgaarb. For boot_vga, we want a VGA device. For the primary
> device, we want the device with the pre-configured framebuffer on it. So
> I'd do something like this in video_is_primary_device():
>
> if (screen_info is_valid) {
> // do the screen_info test from [2]
> } else {
> // fall back to the default vga device. [3]
> }
>
> This should get us at most one primary graphics device; preferably the
> one with the framebuffer. With no framebuffer set up, using the default
> VGA seems a sensible choice. We can still have distinct boot_display and
> boot_vga flags, because this is what the system looks like.
>
> And with that, another patch has to go into the Xorg server. Support for
> boot_display got added in commit 41c58693c ("Add check for
> `pci_device_linux_sysfs_boot_display()`") [4] AFAICT. This needs to be
> reworks a bit, so that it first tests for boot_display; and then falls
> back to boot_vga if the former did not exist.
Makes sense.
Here is an updated kernel patch:
https://lore.kernel.org/linux-pci/20260623141505.1816786-1-mario.limonciello@amd.com/T/#u
Here is a change to xserver:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2242
prev parent reply other threads:[~2026-06-23 14:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 6:13 Aaron Ma
2026-06-22 16:09 ` Mario Limonciello
2026-06-23 7:32 ` Thomas Zimmermann
2026-06-23 14:16 ` Mario Limonciello [this message]
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=f4eff053-d37e-4172-ba94-b9ef746b9370@amd.com \
--to=mario.limonciello@amd.com \
--cc=aaron.ma@canonical.com \
--cc=bhelgaas@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome