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

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2988 bytes --]

Hi

Am 06.09.23 um 05:08 schrieb suijingfeng:
> Hi,
> 
> 
> On 2023/9/5 23:05, Thomas Zimmermann wrote:
>> However, on modern Linux systems the primary display does not really 
>> exist. 'Primary' is the device that is available via VGA, VESA or EFI. 
> 
> I may miss the point, what do you means by choose the word "modern"?
> Are you trying to tell me that X server is too old and Wayland is the 
> modern display server?

It comes down to that. Xorg's device handling is out of date. Fixing it 
would require a redesign of the whole program. A 'modern' compositor 
delegates device handling to the kernel. All it does is to open the 
device files and use the provided functionality. I've briefly mentioned 
this in the other email.

There's more to 'modern', such as 'uses Wayland for compositing', 'Mesa 
for direct rendering' or 'does atomic modesetting'. But that's all 
unrelated here.

> 
> 
>> Our drivers don't use these interfaces, but the native registers.
> 
> 
> Yes and no?
> 
> Yes for the machine with the UEFI firmware,
> but I not sure if this statement is true for the machine with the legacy 
> firmware.

What I mean is: the primary device is the one that owns the VGA/VESA/EFI 
I/O space. But DRM drivers don't program by VGA registers or VESA/EFI 
calls. They use the hardware's actual native registers in the each 
device's I/O space. So each device operates on it's own. They (usually) 
don't have to share/arbitrate access to the VGA registers.

Hence the idea of a primary device does not make sense here. It's useful 
to pick an initial default, but further display setup should rather be 
left to userspace.

> 
> As the display controller in the ASpeed BMC is VGA compatible.
> Therefore, in theory, it should works with the VGA console on the machine
> with another VGA compatible video card. So the ast_vga_set_decode() 
> function
> provided in the 0007 patch probably useful on legacy firmware environment.
> 
> To be honest, I have tested this on various machine with UEFI firmware.
> But I didn't realized that I should do the testing on legacy firmware 
> environment
> before sending this patch. It seems that the testing effort needed are 
> quite
> exhausting, since all my machines come with the UEFI firmware.
> 
> So is it OK to leave the legacy part to someone else who interested in it?
> Probably Alex is more professional at legacy VGA routing stuff?

Maybe you can describe the user's problem to us. TBH I still don't 
understand what you're trying to solve. If you what to set the console's 
initial output device, you can make a parameter in vgaarb. But I also 
don't really see a need for that either.

Best regards
Thomas

> :-)
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]