[PATCH v9 0/9] Adjust fbcon console device detection
Bjorn Helgaas
helgaas at kernel.org
Thu Jul 24 18:36:23 UTC 2025
On Thu, Jul 17, 2025 at 03:56:58PM -0500, Bjorn Helgaas wrote:
> On Thu, Jul 17, 2025 at 12:38:03PM -0500, Mario Limonciello wrote:
> > From: Mario Limonciello <mario.limonciello at amd.com>
> >
> > Systems with more than one GPU userspace doesn't know which one to be
> > used to treat as primary. The concept of primary is important to be
> > able to decide which GPU is used for display and which is used for
> > rendering. If it's guessed wrong then both GPUs will be kept awake
> > burning a lot of power.
> >
> > Historically it would use the "boot_vga" attribute but this isn't
> > present on modern GPUs.
> >
> > This series started out as changes to VGA arbiter to try to handle a case
> > of a system with 2 GPUs that are not VGA devices and avoid changes to
> > userspace. This was discussed but decided not to overload the VGA arbiter
> > for non VGA devices.
> >
> > Instead move the x86 specific detection of framebuffer resources into x86
> > specific code that the fbcon can use to properly identify the primary
> > device. This code is still called from the VGA arbiter, and the logic does
> > not change there. To avoid regression default to VGA arbiter and only fall
> > back to looking up with x86 specific detection method.
> >
> > In order for userspace to also be able to discover which device was the
> > primary video display device create a new sysfs file 'boot_display'.
> >
> > A matching userspace implementation for this file is available here:
> > Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/39
> > Link: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2038
> >
> > Dave Airlie has been pinged for a comment on this approach.
> > Dave had suggested in the past [1]:
> >
> > "
> > But yes if that doesn't work, then maybe we need to make the boot_vga
> > flag mean boot_display_gpu, and fix it in the kernel
> > "
> >
> > This was one of the approached tried in earlier revisions and it was
> > rejected in favor of creating a new sysfs file (which is what this
> > version does).
> >
> > It is suggested that this series merge entirely through the PCI tree.
> >
> > Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/37#note_2938602 [1]
> >
> > v9:
> > * Add more to cover letter
> > * Add bug link to last patch
> > * Update commit message for last patch
> > * Update boot_display documentation description
> >
> > Mario Limonciello (9):
> > PCI: Add helper for checking if a PCI device is a display controller
> > vfio/pci: Use pci_is_display()
> > vga_switcheroo: Use pci_is_display()
> > iommu/vt-d: Use pci_is_display()
> > ALSA: hda: Use pci_is_display()
> > Fix access to video_is_primary_device() when compiled without
> > CONFIG_VIDEO
> > PCI/VGA: Replace vga_is_firmware_default() with a screen info check
> > fbcon: Use screen info to find primary device
> > PCI: Add a new 'boot_display' attribute
> >
> > Documentation/ABI/testing/sysfs-bus-pci | 9 +++++
> > arch/parisc/include/asm/video.h | 2 +-
> > arch/sparc/include/asm/video.h | 2 ++
> > arch/x86/include/asm/video.h | 2 ++
> > arch/x86/video/video-common.c | 17 ++++++++-
> > drivers/gpu/vga/vga_switcheroo.c | 2 +-
> > drivers/iommu/intel/iommu.c | 2 +-
> > drivers/pci/pci-sysfs.c | 46 +++++++++++++++++++++++++
> > drivers/pci/vgaarb.c | 31 +++--------------
> > drivers/vfio/pci/vfio_pci_igd.c | 3 +-
> > include/linux/pci.h | 15 ++++++++
> > sound/hda/hdac_i915.c | 2 +-
> > sound/pci/hda/hda_intel.c | 4 +--
> > 13 files changed, 102 insertions(+), 35 deletions(-)
>
> Applied to pci/boot-display for v6.17, thanks!
I kept the pci_is_display() changes but deferred the following for now:
Fix access to video_is_primary_device() when compiled without CONFIG_VIDEO
PCI/VGA: Replace vga_is_firmware_default() with a screen info check
fbcon: Use screen info to find primary device
PCI: Add a new 'boot_display' attribute
I think the boot_display attribute isn't quite baked yet and I don't
want to add something when it looks like we're immediately going to
change the implementation and maybe the sysfs location.
Bjorn
More information about the dri-devel
mailing list