[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 at suse.de
Wed Sep 6 07:46:15 UTC 2023
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230906/72283d4d/attachment.sig>
More information about the dri-devel
mailing list