linux-kernel - Re: [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a9af88c5-4509-96ff-a7fd-a0f72d2f1e6a@linux.dev>
Date:   Thu, 7 Sep 2023 10:30:05 +0800
From:   Sui Jingfeng <sui.jingfeng@...ux.dev>
To:     Christian König <ckoenig.leichtzumerken@...il.com>,
        suijingfeng <suijingfeng@...ngson.cn>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Daniel Vetter <daniel@...ll.ch>,
        "Deucher, Alexander" <Alexander.Deucher@....com>
Cc:     nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, linux-pci@...r.kernel.org
Subject: Re: [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user
 to select the primary video adapter at boot time

Hi,


On 2023/9/6 17:40, Christian König wrote:
> Am 06.09.23 um 11:08 schrieb suijingfeng:
>> Well, welcome to correct me if I'm wrong.
>
> You seem to have some very basic misunderstandings here.
>
> The term framebuffer describes some VRAM memory used for scanout.
>
> This framebuffer is exposed to userspace through some framebuffer 
> driver, on UEFI platforms that is usually efifb but can be quite a 
> bunch of different drivers.
>
> When the DRM drivers load they remove the previous drivers using 
> drm_aperture_remove_conflicting_pci_framebuffers() (or similar 
> function), but this does not mean that the framebuffer or scanout 
> parameters are modified in any way. It just means that the framebuffer 
> is just no longer exposed through this driver.
>
> Take over is the perfectly right description here because that's 
> exactly what's happening. The framebuffer configuration including the 
> VRAM memory as well as the parameters for scanout are exposed by the 
> newly loaded DRM driver.
>
> In other words userspace can query through the DRM interfaces which 
> monitors already driven by the hardware and so in your terminology 
> figure out which is the primary one.
>
I'm a little bit of not convinced about this idea, you might be correct.
But there cases where three are multiple monitors and each video card
connect one.

It also quite common that no monitors is connected, let the machine boot
first, then find a monitors to connect to a random display output. See
which will display. I don't expect the primary shake with.
The primary one have to be determined as early as possible, because of
the VGA console and the framebuffer console may directly output the primary.
Get the DDC and/or HPD involved may necessary complicated the problem.

There are ASpeed BMC who add a virtual connector in order to able display remotely.
There are also have commands to force a connector to be connected status.


> It's just that as Thomas explained as well that this completely 
> irrelevant to any modern desktop. Both X and Wayland both iterate the 
> available devices and start rendering to them which one was used 
> during boot doesn't really matter to them.
>
You may be correct, but I'm still not sure.
I probably need more times to investigate.
Me and my colleagues are mainly using X server,
the version varies from 1.20.4 and 1.21.1.4.
Even this is true, the problems still exist for non-modern desktops.

> Apart from that ranting like this and trying to explain stuff to 
> people who obviously have much better background in the topic is not 
> going to help your patches getting upstream.
>

Thanks for you tell me so much knowledge,
I'm realized where are the problems now.
I will try to resolve the concerns at the next version.


> Regards,
> Christian.
>