Message-ID: <6035cf27-1506-dda7-e1ca-d83ce5cb5340@suse.de>
Date:   Wed, 6 Sep 2023 10:05:27 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     suijingfeng <suijingfeng@...ngson.cn>,
        Sui Jingfeng <sui.jingfeng@...ux.dev>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        "Deucher, Alexander" <Alexander.Deucher@....com>
Cc:     nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        amd-gfx@...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

Am 05.09.23 um 17:59 schrieb suijingfeng:
[...]
>> FYI: per-driver modeset parameters are deprecated and not to be used. 
>> Please don't promote them.
> 
> 
> Well, please wait, I want to explain.
> 
> 
> 
> drm/nouveau already promote it a little bit.
> 
> Despite no code of conduct or specification guiding how the modules 
> parameters should be.
> Noticed that there already have a lot of DRM drivers support the modeset 
> parameters,

Please look at the history and discussion around this parameter. To my 
knowledge, 'modeset' got introduced when modesetting with still done in 
userspace. It was an easy way of disabling the kernel driver if the 
system's Xorg did no yet support kernel mode setting.

Fast forward a few years and all Linux' use kernel modesetting, which 
make the modeset parameters obsolete. We discussed and decided to keep 
them in, because many articles and blog posts refer to them. We didn't 
want to invalidate them. BUT modeset is deprecated and not allowed in 
new code. If you look at existing modeset usage, you will eventually 
come across the comment at [1].

There's 'nomodeset', which disables all native drivers. It's useful for 
debugging or as a quick-fix if the graphics driver breaks. If you want 
to disable a specific driver, please use one of the options for 
blacklisting.

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v6.5/source/include/drm/drm_module.h#L83


> for the modeset parameter, authors of various device driver try to make 
> the usage not
> conflict with others. I believe that this is good thing for Linux users.
> It is probably the responsibility of the drm core maintainers to force 
> various drm
> drivers to reach a minimal consensus. Probably it pains to do so and 
> doesn't pay off.
> But reach a minimal consensus do benefit to Linux users.
> 
> 
>> You can use modprobe.blacklist or initcall_blacklist on the kernel 
>> command line.
>>
> There are some cases where the modprobe.blacklist doesn't works,
> I have come cross several time during the past.
> Because the device selected by the VGAARB is device-level thing,
> it is not the driver's problem.
> 
> Sometimes when VGAARB has a bug, it will select a wrong device as primary.
> And the X server will use this wrong device as primary and completely crash
> there, due to lack a driver. Take my old S3 Graphics as an example:
> 
> $ lspci | grep VGA
> 
>   00:06.1 VGA compatible controller: Loongson Technology LLC DC (Display 
> Controller) (rev 01)
>   03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
> [AMD/ATI] Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM]
>   07:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 (rev 01)
>   08:00.0 VGA compatible controller: S3 Graphics Ltd. Device 9070 (rev 01)
> 
> Before apply this patch:
> 
> [    0.361748] pci 0000:00:06.1: vgaarb: setting as boot VGA device
> [    0.361753] pci 0000:00:06.1: vgaarb: VGA device added: 
> decodes=io+mem,owns=io+mem,locks=none
> [    0.361765] pci 0000:03:00.0: vgaarb: VGA device added: 
> decodes=io+mem,owns=none,locks=none
> [    0.361773] pci 0000:07:00.0: vgaarb: VGA device added: 
> decodes=io+mem,owns=none,locks=none
> [    0.361779] pci 0000:08:00.0: vgaarb: VGA device added: 
> decodes=io+mem,owns=none,locks=none
> [    0.361781] vgaarb: loaded
> [    0.367838] pci 0000:00:06.1: Overriding boot device as 1002:6778
> [    0.367841] pci 0000:00:06.1: Overriding boot device as 5333:9070
> [    0.367843] pci 0000:00:06.1: Overriding boot device as 5333:9070
> 
> 
> For known reason, one of my system select the S3 Graphics as primary GPU.
> But this S3 Graphics not even have a decent drm upstream driver yet.
> Under such a case, I begin to believe that only the device who has a
> driver deserve the primary.
> 
> Under such a condition, I want to reboot and enter the graphic environment
> with other working video cards. Either platform integrated and discrete 
> GPU.
> This don't means I should compromise by un-mount the S3 graphics card from
> the motherboard, this also don't means that I should update my BIOS 
> setting.
> As sometimes, the BIOS is more worse.
> 
> With this series applied, all I need to do is to reboot the computer and
> pass a command line. By force override another video card (who has a
> decent driver support) as primary, I'm able to do the debugging under
> graphic environment. I would like to examine what's wrong with the vgaarb
> on a specific platform under X server graphic environment.
> 
> Probably try compile a driver for this card and see it works, simply reboot
> without the need to change anything. It is so efficient. So this is 
> probably
> the second usage of my patch. It hand the right of control back to the
> graphic developer.
> 
> 

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

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists