On Mon, Jun 16, 2025 at 5:21 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > Hi > > Am 16.06.25 um 08:50 schrieb David Airlie: > [...] > >>>> > >>>> It's also a bit concerning that we're making a policy decision here > >>>> that the integrated graphics is the "boot VGA" device, among two > >>>> non-VGA devices. I think vgaarb has a similar legacy policy decision > >>>> for VGA devices that it's stuck with, but it's not clear to me that > >>>> reiterating the policy selection here is still correct. Thanks, > >>>> > >>>> Alex > >>> I'm with you there. That's actually exactly why the first swing at > >>> this was with a patch to userspace. > >>> > >>> https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/37 > >> I second Alex' point. I acked the patch purely on my understanding of > >> how it does this, but as I noted, I'd also prefer to solve this in user > >> space. I think we should push back on this change. > >> > > If we are solving this in userspace I think fixing it in libpciaccess > > is probably also the wrong place, which leaves open where is the right > > place? > > Why is libpciaccess the wrong place? I see that the boot display is not > necessarily on the PCI bus. But if its not handled in libpciaccess, > should it rather go into Xorg directly? Because this isn't generally a PCI problem, and it involves accessing ACPI stuff, who says it won't need DT stuff on other hardware? Just seems like libpciaccess is convenient but so is the kernel, I don't think userspace is right at all. The kernel should abstract the hardware. > > To be honest the what GPU is driving the display at boot hint should > > come from the kernel, since it knows already, whether boot_vga is the > > best method of doing that is open to questions. > > The proposed user-space patch looks way less intrusive than the kernel > change. I don't care for intrusive, I care for correct. > > > > > It might be better to have a bit somewhere on the drm device that shows this. > > > > hello new UAPI. > > In the kernel, there's already video_is_primary_device. [1] On x86, it > looks at vga_default_device(), on other architectures, it looks at > firmware settings. If there's no default vga on x86, it could do more > heuristics to figure out the boot display. The result can be exported by > a boot_display file via sysfs. video_is_primary_device() is currently > used by fbcon. Any changes to the helper would likely benefit fbcon as well. > We should work on that then, since fbcon also needs this info to be correct, it should go in the kernel. Dave.