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

Am 07.09.23 um 04:30 schrieb Sui Jingfeng:
> 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.
Well I can point you to the code if you don't believe me.
> But there cases where three are multiple monitors and each video card
> connect one.
Yeah, but this is irrelevant. The key point is the configuration is 
taken over when the driver loads.

So whatever is there before as setup (one monitor showing console, three 
monitors mirrored, whatever) should be there after loading the driver as 
well. This configuration is just immediately overwritten because nobody 
cares about it.
>
> 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.
Well that is simply not correct. There is not concept of "primary" 
display, it can just be that a monitor was brought up by the BIOS or 
bootloader and we take over this configuration.
> 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.
Well, I have over 25 years of experience with display hardware and what 
you describe here was never an issue.

What you have is simply a broken display driver which for some reason 
can't handle your use case.

I strongly suggest that you just completely drop this here and go into 
the AST driver and try to fix it.

Regards,
Christian.

>
>> 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.
>>

Hi,


On 2023/9/7 17:08, Christian K?nig wrote:
> Well, I have over 25 years of experience with display hardware and 
> what you describe here was never an issue. 
I want to give you an example to let you know more.

I have a?ASRock AD2550B-ITX board[1],
When another discrete video card is mounted into it mini PCIe slot or PCI slot,
The IGD cannot be the primary display adapter anymore. The display is totally
black.
I have try to draft a few trivial patch to help fix this[2].

And I want to use the IGD as primary, does this count as an issue?

[1] https://www.asrock.com/mb/Intel/AD2550-ITX/
[2] https://patchwork.freedesktop.org/series/123073/

Hi,


On 2023/9/7 17:08, Christian K?nig wrote:

> I strongly suggest that you just completely drop this here 

Drop this is OK, no problem. Then I will go to develop something else.
This version is not intended to merge originally, as it's a RFC.
Also, the core mechanism already finished, it is the first patch in this series.
Things left are just policy (how to specify one and parse the kernel CMD line)
and nothing interesting left.
It is actually to fulfill my promise at V3 which is to give some examples as
usage cases.

> and go into the AST driver and try to fix it. 
Well, someone tell me that this is well defined behavior yesterday,
which imply that it is not a bug. I'm not going to fix a non-bug.
But if thomas ask me to fix it, then I probably have to try to fix.
But I suggest if things not broken, don't fix it. Otherwise this may
incur more big trouble. For server's single display use case, it is
good enough.


Thanks.