On Fri, Dec 04, 2009 at 05:24:23AM +0100, Stefan Dirsch wrote:
On Thu, Dec 03, 2009 at 04:37:05PM +0100, Egbert Eich wrote:
AIUI, if someone wants to use the proprietary driver, it is enough that the package adds nomodeset boot option to bootloader configuration and the drivers should continue to work just fine? (I'm no fan, but on few machines I need 3D on ATI...)
The idea is that the install script for the proprietary driver would either set the global NO_KMS_IN_INITRD sysconfig variable or blacklist exactly those PCI ids in /etc/kms/<drm_driver_name>.blacklist and rerun mkinitrd.
BTW, in which sysconfig file should this variable be set? Apparently it's not added by any of your patches, only checked in setup-kms.sh.
I've been thinking about the blacklisting some more. It's very easy to get the system inconsistent when we have different sort of blacklistings. modprobe supports blacklisting per driver (not per modalias or any wildcared variant thereof). If we are willing to scarifice per device ID blacklisting we should simply go with the blacklisting modprobe supports. If we also make sure that options listed in /etc/modprobe.d/* are copied to initrd for the drivers copied to it then - The user can disable KMS (per driver) by adding the a line options <drivername> modeset=0 to /etc/modprobe.d/options - ATI (as an example) can simply ship a file containing the line blacklist radeon and dump it into /etc/modprobe.d/ to prevent loading the radeon driver. rerunning mkinitrd will generate a new initrd without the radeon module. NO_KMS_IN_INITRD by itself doesn't provide a big benefit. If the DRM driver isn't loaded in initrd it will be loaded by udev (which can be prevented) or by the Xserver. Thus this option would only be useful for developers who want to load a DRM driver by hand and thus not have it loaded by initrd. (As a note on the side: when KMS is activated DRM drivers cannot be unloaded - which makes debugging this driver a real treat :( ) If we want black listing or option listing based on PCI Ids we'd have to provide a script which scans the hardware and adds appropirate entries to /etc/modprobe.d/. It would have to be rerun every time the hardware changes. Expanding modprobe to perform such a mapping might be possible but I don't want to go this route without soliciting for feedback on opensuse-kernel. The reason why I (and probably you) think that this might be useful is that SaX2 used to maintain per device ID lists of driver options. kernel developer might have a different take on that.
The latter is actually preferred as the fglrx driver doesn't support the range of hardware that is covered by the free drivers.
But if the driver doesn't support the hardware and a different driver is in use anyway, it makes no sense to install it, right? It even harms since it replaces system libraries like libGL, etc. which could result in all kind of weird effects. Thus I believe it's sufficient to set NO_KMS_IN_INITRD.
See above.
The uninstall script should be kind enough to remove those entries and rerun mkinitrd.
Of course.
One reason for the vendors of proprietary drivers prefering to write 'nomodeset' to menu.list instead directly could be that this kind of works on Fedora, Ubuntu and openSUSE. Until it gets overwritten again on openSUSE later by the next kernel update or similar. Not sure whether changes in menu.lst are safe on Fedora/Ubuntu. Could be.
nomodeset will prevent KMS from being activated it will not prevent the driver from being loaded. Two different things. I would think what I suggested above will also work universally and doesn't involve tedious line parsing in menu.lst. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org