Folks -
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution. Furthermore test packages are available to try things out on Factory. I would like to encourage people interested in development and technical discussions in general to participate in the discussion and the development efforts.
Kernel Modesetting (KMS) ========================
All of you who are using a graphical desktop on Linux have been using the X Window Sytem. The X Window System Server (XServer) is the instance which receives requests from your desktop applications to draw all the widgets (windows, buttons, images etc.) you see on your desktop. It also processes input from your keyboard and mouse and sends them to applications as events. Traditionally on Linux the XServer does not only draw images to the screen (ie writes them to some sort of frame buffer) but it is in charge of initializing, setting up and driving the graphics hardware.
This paradigm which has been true since the X Window System has been ported to Linux is about to change: Much of the initialization, set up (video mode setting) and control of the graphics hardware is about to move to the Linux kernel.
There are a number of advantages to this: - A central instance is in charge of the graphics hardware, other user mode applications (not just the Xserver) can take advantage of mode setting. - The Xserver will no longer require full root privileges as it doesn't talk to the hardware directly any more. - Faster boot process: The Xserver doesn't need to (re)initialize the graphics hardware any more, this is all done by the kernel very early in the boot cycle. - Smoother (flicker free) boot experience: The screen doesn't flicker and changes resolution any more when the Xserver starts. - One central entity is in charge and manages the resources of the graphics hardware - like the video memory which makes sharing of these resources between several applications (like Xserver and several DRI (Direct Rendering 3D) applications much easier.
KMS is integrated in the DRM drivers. In the near future most graphics driver will switch to KMS: - Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only. - KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets. - Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets. The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future.
Integration in openSUSE ======================= Now this begs the question what we have to do to integrate it into openSUSE. Originall I had plans to look into this for openSUSE 11.2 already - but then I got side tracked by other stuff it fell on the floor and noone else beat me to it either ... oh well. Now I had the chance to play around with KMS a little and came up with some ideas and a proof of concept. It turned out that the changes to openSUSE needed to fully support KMS are quite small. Key is to load the KMS aware DRM driver as early as possible in the boot process to avoid video mode changes later in the boot cycle - preferrably in the initrd.
The Boot Process ----------------
On openSUSE the boot loader is configured for two boot scenarios: default and failsafe. The user can select the failsafe boot scenario in case the default scenario does not work for him. In the failsafe scenario certain features are deactivated which have shown to cause problems on some systems.
Since KMS is a new feature it is a candidate for deactivation during a failsafe boot. Instead the system should then boot into the VESA framebuffer mode. Should this also fail the kernel will automatically fall back to a VGA text mode. To disable KMS on boot a new boot parameter is introduced: 'nomodeset'. This parameter is to the boot command line for the failsafe mode. The user may add this parameter by hand for any other boot mode.
The kernel command line is parsed in initrd and an appropriate entry is created in /etc/modprobe.d/options. Furthermore the graphics driver module and - if required - the agp module(s) are added in the correct order (agp modules first) to the list of modules to be loaded initially.
Changes to individual packages ==============================
1. yast2-bootloader & perl-Bootloader ------------------------------------- The boot parameter 'nomodeset' is added to the failsafe boot paramter lists in each of the modules. (I have not been able to find out which module provides the entry relevant for which situation, therefore I've whacked both.) yast2-bootloader updates the variable FAILSAFE_APPEND in /etc/sysconfig/bootloader appropriately.
2. kernel-source ----------------
To use KMS for a certain DRM driver the kernel config option CONFIG_DRM_<driver_name>_KMS needs to be set to 'y'. At the moment we will support KMS only for Intel hardware, thus only the variable CONFIG_DRM_I915_KMS needs to be changed.
In the sample build this has been enabled for the -default, -desktop, -pae, -debug, -trace and -vanilla kernels for the i386 and x86_64 platforms.
The kernel boot splash has already been fixed for KMS for openSUSE 11.2.
3. mkinitrd -----------
This package writes the initrd file. To add KMS support to the initrd mkinitrd needs to perform the following tasks:
1. Check the sysconfig variable NO_KMS_IN_INITRD, if set, don't attempt to install a KMS DRM capable driver.
2. Obtain a list of PCI devices installed on the system.
3. a. In the list of PCI devices identify those devices which are of class VGA and look for a matching driver. b. Before a driver is matched check the PCI vendor, device, subvendor and subdevice ids against a blacklist in /etc/kms/blacklist should this file exist. This file contains one vendor, device, subvendor and subdevice id per line, '*' serves as a wildchar, trailing wildchars may be ommitted, '#' at the beginning of a line serves as a comment. c. Use the standard modprobe alias mechanism to find a matching DRM driver module. This way standard blacklistings of kernel modules will be honored and update modules will be searched if they are available. KMS capable DRM drivers provide an alias list (in contrast to non-KMS capable DRM drivers which are to be loaded explicitely by the Xserver). d. If a driver is found check for a black listing in /etc/kms/<driver_name>.blacklist. The same rules as in 3 b. apply.
4. If a KMS capable DRM driver is found search for an agp driver: a. Obtain a list of all known agp drivers for the specific kernel and collect their alias lists. b. Match all installed PCI devices against the alias lists of each agp driver. If a match is found add the driver to the lists of modules to be loaded. Make sure that this driver is loaded prior the the DRM driver.
Two scripts setup-kms.sh and boot-kms.sh are added to mkinitrd. The former performs the tasks listed above, the latter provides the required module dependencies in the required order, parses the boot command line for the 'nomodeset' option and adds the apropriate entry to /etc/modprobe.d/options. The linuxrc script is extended to search the boot command line for <drivername>.<option>=* strings for each driver loaded in initrd and add the <option>=* part to /etc/modprobe.d/options.
4. udev -------
Udev loads any modules which are not loaded by linuxrc scripts directly. It is possible to let udev load the required DRM and AGP modules provided it is made sure that this happens in the correct order. Since there is no explicit dependency of DRM modules to AGP drivers as there is no general one to one match between the two drivers a udev rule must exist to enforce the correct order for all cases where a AGP module is required. This is true for Intel DRM drivers and any other driver for an AGP graphics chip. For this a rule file 79-waitfor-agp.rules is added which is run before 80-drivers.rules. It checks if either an Intel graphics (class VGA) device is processed or if the graphics device is an AGP device. The latter condition is tested by an auxiliary tool (is_agp) which is passed the kernel name of the event device. If either condition is true udev will wait for /dev/agpgart to appear before proceeding to load a DRM driver module. 'is_agp' checks the capabilities flags in the PCI config space of this device for AGP.
The changes to udev are not strictly required to make KMS work, still they augment the default module load process
Installation ============
Modified packages for Factory of - kernel-source, - mkinitrd, - yast2-bootloader, - perl-Bootloader, - mkinitrd - udev can be found in my build service home on OBS under home:eeich:Factory-KMS. For installation add http://download.opensuse.org/repositories/home://eeich://Factory-KMS/openSUS... to your installation repository and update the packages in question (going thru the usual vendor change hassle).
It is advisable to update mkinitrd before updating the kernel. Then when the kernel is installed the modified mkinitrd will be used and all steps required to install KMS will be performed.
TODO ====
- The kernel bootsplash sometimes produces wrong colors (WIP). Add KMS - Add KMS support to the RadeonHD driver.
Cheers, Egbert.
Hi!
Thanks for the detailed writeup.
On Thu, Dec 03, 2009 at 02:38:29PM +0100, Egbert Eich wrote:
KMS is integrated in the DRM drivers. In the near future most graphics driver will switch to KMS:
- Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only.
- KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets.
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future.
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...)
Thanks,
Petr "Pasky" Baudis
On Thu, Dec 03, 2009 at 03:23:54PM +0100, Petr Baudis wrote:
Hi!
Thanks for the detailed writeup.
On Thu, Dec 03, 2009 at 02:38:29PM +0100, Egbert Eich wrote:
KMS is integrated in the DRM drivers. In the near future most graphics driver will switch to KMS:
- Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only.
- KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets.
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future.
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.
The latter is actually preferred as the fglrx driver doesn't support the range of hardware that is covered by the free drivers.
The uninstall script should be kind enough to remove those entries and rerun mkinitrd.
Cheers, Egbert.
Torsdag den 3. december 2009 16:37:05 skrev Egbert Eich:
On Thu, Dec 03, 2009 at 03:23:54PM +0100, Petr Baudis 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.
The latter is actually preferred as the fglrx driver doesn't support the range of hardware that is covered by the free drivers.
The uninstall script should be kind enough to remove those entries and rerun mkinitrd.
That's only possible for RPMs built for openSUSE right?
People installing the blobs the manual way would have perform these actions manually? .. which currently means _all_ fglrx users on 11.2 for example.
On Thu, Dec 03, 2009 at 05:15:31PM +0100, Martin Schlander wrote:
That's only possible for RPMs built for openSUSE right?
I see no reason why fglrx couldn't do this by default everywhere, it certainly wouldn't break anything - someone only needs to let ATI know about this in time so that there's enough time for new fglrx version to get released before 11.3.
People installing the blobs the manual way would have perform these actions manually? .. which currently means _all_ fglrx users on 11.2 for example.
There is a work-around possible for the fglrx RPM builder: :)
http://forums.opensuse.org/hardware/426190-generating-catalyst-9-11-rpms-ope...
Agreed, it's a pain, but hardly openSUSE's fault. :(
On Thu, Dec 03, 2009 at 05:27:08PM +0100, Petr Baudis wrote:
On Thu, Dec 03, 2009 at 05:15:31PM +0100, Martin Schlander wrote:
That's only possible for RPMs built for openSUSE right?
I see no reason why fglrx couldn't do this by default everywhere, it certainly wouldn't break anything - someone only needs to let ATI know about this in time so that there's enough time for new fglrx version to get released before 11.3.
I believe %post of packages/SuSE/fglrx.spec in the shell script archive, from which all spec files are generated, can easily be adjusted. So everybody using "--buildpkg <distribution>" can benefit from such a change.
People installing the blobs the manual way would have perform these actions manually? .. which currently means _all_ fglrx users on 11.2 for example.
Package build is done since about we released 11.2. Now we're waiting for ATI to put them onto their server.
There is a work-around possible for the fglrx RPM builder: :)
http://forums.opensuse.org/hardware/426190-generating-catalyst-9-11-rpms-ope...
Fixed for 9-12. Also in git master, 8.68/9-12 and 8.67/9-11 branches on Phoronix.
Agreed, it's a pain, but hardly openSUSE's fault. :(
The culprit was a radical change in behaviour of RPM on 11.2. Ask Rüdiger Oertel for details, if you're interested.
About the statement, it's hardly openSUSE's fault. Any help I could get from the openSUSE community for the fglrx packaging scripts would be appreciated.
Best regards, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
Fredag den 4. december 2009 05:52:19 skrev Stefan Dirsch:
On Thu, Dec 03, 2009 at 05:27:08PM +0100, Petr Baudis wrote:
On Thu, Dec 03, 2009 at 05:15:31PM +0100, Martin Schlander wrote:
People installing the blobs the manual way would have perform these actions manually? .. which currently means _all_ fglrx users on 11.2 for example.
Package build is done since about we released 11.2. Now we're waiting for ATI to put them onto their server.
Argh. Damn them.
But thanks for the info, nice to know what's going on, when you're trying to support users and the question comes up on IRC lots of times each and every day.
On Thu, Dec 03, 2009 at 05:15:31PM +0100, Martin Schlander wrote:
The latter is actually preferred as the fglrx driver doesn't support the range of hardware that is covered by the free drivers.
The uninstall script should be kind enough to remove those entries and rerun mkinitrd.
That's only possible for RPMs built for openSUSE right?
People installing the blobs the manual way would have perform these actions manually? .. which currently means _all_ fglrx users on 11.2 for example.
My packages presently don't support KMS on 11.2. If you want to build them on 11.2 install them enable KMS support for Radeon, rebuild and install the kernel and then decide you want the fglrx driver, then yes: you are on your own. But I'd expect that if you can perform all these steps yourself you will be able to do this last step yourself, too.
Please note: this is all experimental. Nothing is carved in stone and if you do experiments on your machine you may end up in the situation where you have to fix some things by hand.
Cheers, Egbert.
-- Egbert Eich (Res. & Dev.) SUSE LINUX Products GmbH X Window System Development Tel: +49 911-740 53 0 http://www.suse.de ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
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.
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.
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.
Best regards, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
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.
On Fri, Dec 04, 2009 at 10:59:49AM +0100, Egbert Eich wrote:
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.
Makes perfectly sense to me. ATI can run mkinitrd in %postin.
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.
Assuming that drivers themselves provide such a blacklist file, this script could be run in %postin of such a driver package.
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.
Understood.
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.
I agree. So the approach for the proprietary drivers is to ship a modprobe.d file blacklisting the opensource DRm modules to prevent them being loaded and added to initrd.
Best regards, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
On Fri, Dec 04, 2009 at 12:04:52PM +0100, Stefan Dirsch wrote:
Makes perfectly sense to me. ATI can run mkinitrd in %postin.
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.
Assuming that drivers themselves provide such a blacklist file, this script could be run in %postin of such a driver package.
I would like to avoid this. The system may become inconsistent too easily. If you keep information in one place which needs to be converted to be stored in some other place where it is actually used you just ask for such inconstencies to happen. The user changes HW or edits the blacklist and wonders why things don't happen as expected (from the blacklist settings). Do we really need a per device ID blacklist?
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.
Understood.
If we really think this feature is needed we should start the discussion. If we cannot think of any reasonable use case now we should wait with this.
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.
I agree. So the approach for the proprietary drivers is to ship a modprobe.d file blacklisting the opensource DRm modules to prevent them being loaded and added to initrd.
Yes.
I will change the packages removing the device ID specific blacklists if you don't object.
Cheers, Egbert.
On Fri, Dec 04, 2009 at 03:06:41PM +0100, Egbert Eich wrote:
On Fri, Dec 04, 2009 at 12:04:52PM +0100, Stefan Dirsch wrote:
Makes perfectly sense to me. ATI can run mkinitrd in %postin.
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.
Assuming that drivers themselves provide such a blacklist file, this script could be run in %postin of such a driver package.
I would like to avoid this. The system may become inconsistent too easily. If you keep information in one place which needs to be converted to be stored in some other place where it is actually used you just ask for such inconstencies to happen. The user changes HW or edits the blacklist and wonders why things don't happen as expected (from the blacklist settings). Do we really need a per device ID blacklist?
Another option would be to hardcode that blacklist in the DRM driver itself, but then it should be possible to overwrite that default (how?). Not sure whether that's feasable at all.
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.
Understood.
If we really think this feature is needed we should start the discussion. If we cannot think of any reasonable use case now we should wait with this.
Ok. I believe it makes sense, but we might be the first ones asking for this feature and it might be not appreciated at all. Probably most developers will say: Fix the driver in that case or disable KMS for that ID.
I will change the packages removing the device ID specific blacklists if you don't object.
For now that's fine. :-)
CU, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
On Fri, Dec 04, 2009 at 03:25:18PM +0100, Stefan Dirsch wrote:
Another option would be to hardcode that blacklist in the DRM driver itself, but then it should be possible to overwrite that default (how?). Not sure whether that's feasable at all.
Yes.
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.
Understood.
If we really think this feature is needed we should start the discussion. If we cannot think of any reasonable use case now we should wait with this.
Ok. I believe it makes sense, but we might be the first ones asking for this feature and it might be not appreciated at all. Probably most developers will say: Fix the driver in that case or disable KMS for that ID.
Yes, that's my feeling, too.
I will change the packages removing the device ID specific blacklists if you don't object.
For now that's fine. :-)
Ok, working on that.
Cheers, Egbert.
On Fri, Dec 04, 2009 at 12:04:52PM +0100, Stefan Dirsch wrote:
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.
I agree. So the approach for the proprietary drivers is to ship a modprobe.d file blacklisting the opensource DRm modules to prevent them being loaded and added to initrd.
Implemented for SUSE/Novell's KMP packages (nvidia-gfx{,G01,G02}/ati-fglrxG0{1,2}) and fglrx upstream SUSE/Novell scripts.
Best regards, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/04/2009 04:59 AM, Egbert Eich wrote:
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.
YaST or the ATI installer could just dump the options or blacklist in its own file in /etc/modprobe.d. The "options" file isn't special. modprobe reads them all.
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.
Yeah, it's probably possible to do it per-device, but right now the code doesn't support it. It's a driver-global option.
- -Jeff
- -- Jeff Mahoney SUSE Labs
On Fri, Dec 04, 2009 at 12:51:30PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/04/2009 04:59 AM, Egbert Eich wrote:
- 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.
YaST or the ATI installer could just dump the options or blacklist in its own file in /etc/modprobe.d. The "options" file isn't special. modprobe reads them all.
Definitely. I was going to write ATI could use the file fglrx.conf.
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.
Yeah, it's probably possible to do it per-device, but right now the code doesn't support it. It's a driver-global option.
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Cheers, Egbert.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/04/2009 02:27 PM, Egbert Eich wrote:
On Fri, Dec 04, 2009 at 12:51:30PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/04/2009 04:59 AM, Egbert Eich wrote:
- 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.
YaST or the ATI installer could just dump the options or blacklist in its own file in /etc/modprobe.d. The "options" file isn't special. modprobe reads them all.
Definitely. I was going to write ATI could use the file fglrx.conf.
Yep, that'd be perfect.
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.
Yeah, it's probably possible to do it per-device, but right now the code doesn't support it. It's a driver-global option.
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Well here's where it gets tricky. modprobe can still only pass global driver options. I suppose it would be possible to pass a blacklist=<alias> or something to work around that, but that's not what I had in mind. It could also be handled via writing to a sysfs file. All drivers support an unbind option, too. This isn't really a discussion to be had with me on this list, though. I'm not at all involved with the DRM drivers.
- -Jeff
- -- Jeff Mahoney SUSE Labs
On Fri, Dec 04, 2009 at 02:45:17PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Well here's where it gets tricky. modprobe can still only pass global driver options. I suppose it would be possible to pass a blacklist=<alias> or something to work around that, but that's not what I had in mind. It could also be handled via writing to a sysfs file. All drivers support an unbind option, too. This isn't really a discussion to be had with me on this list, though. I'm not at all involved with the DRM drivers.
I've looked into 'unbind'. There doesn't seem to be a way to prevent a driver from being bound to devices when initially loaded. This is what we'd need.
Cheers, Egbert.
On Sun, Dec 06, 2009 at 11:30:34PM +0100, Egbert Eich wrote:
On Fri, Dec 04, 2009 at 02:45:17PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Well here's where it gets tricky. modprobe can still only pass global driver options. I suppose it would be possible to pass a blacklist=<alias> or something to work around that, but that's not what I had in mind. It could also be handled via writing to a sysfs file. All drivers support an unbind option, too. This isn't really a discussion to be had with me on this list, though. I'm not at all involved with the DRM drivers.
I've looked into 'unbind'. There doesn't seem to be a way to prevent a driver from being bound to devices when initially loaded. This is what we'd need.
You just don't load the driver then :)
Yeah, we don't have a way to do this on a per-device basis, and I can't think of a sane way to specify this, can anyone else?
thanks,
greg k-h
On Sun, Dec 06, 2009 at 02:46:22PM -0800, Greg KH wrote:
You just don't load the driver then :)
Greg, you may have to cards driven by the same driver, you may want to drive one but not the other. This discussion implicitely moved into this direction - the original question was: would it be useful to have an per alias blacklist? This could be added to modprobe but since there hasn't been any demand for it I'm not so sure if there's any interest for it. And I'm not really sure if we need it for DRM. I certainly don't want to create an elaborate solution noone has any need for ... this is called over-engineering. But we usually find out such things two weeks prior to GM - after the last Beta is out :((
Yeah, we don't have a way to do this on a per-device basis, and I can't think of a sane way to specify this, can anyone else?
This goes further: driver options are driver global, not per device. A sane way to specify this? Well, you could probably prefix options by the device ID the kernel uses.
Cheers, Egbert.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/06/2009 05:30 PM, Egbert Eich wrote:
On Fri, Dec 04, 2009 at 02:45:17PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Well here's where it gets tricky. modprobe can still only pass global driver options. I suppose it would be possible to pass a blacklist=<alias> or something to work around that, but that's not what I had in mind. It could also be handled via writing to a sysfs file. All drivers support an unbind option, too. This isn't really a discussion to be had with me on this list, though. I'm not at all involved with the DRM drivers.
I've looked into 'unbind'. There doesn't seem to be a way to prevent a driver from being bound to devices when initially loaded. This is what we'd need.
Well you could do it by adding an install rule to /etc/modprobe.d so that the unbind automatically runs after the module is loaded. Sure it would be claimed initially, but is the device left in a state where the driver disassociating would cause a problem?
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
- -Jeff
- -- Jeff Mahoney SUSE Labs
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
On 12/06/2009 05:30 PM, Egbert Eich wrote:
On Fri, Dec 04, 2009 at 02:45:17PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A per device blacklist would require modprobe to look at the alias list in the driver, match it against the hardware on the system and then apply the result to the blacklist. To make it general it would have to be usable for all sorts of device IDs. If we need it and the kernel people would accept such a feature (Jeff, your reply is very encouraging) I would actually implement this.
Well here's where it gets tricky. modprobe can still only pass global driver options. I suppose it would be possible to pass a blacklist=<alias> or something to work around that, but that's not what I had in mind. It could also be handled via writing to a sysfs file. All drivers support an unbind option, too. This isn't really a discussion to be had with me on this list, though. I'm not at all involved with the DRM drivers.
I've looked into 'unbind'. There doesn't seem to be a way to prevent a driver from being bound to devices when initially loaded. This is what we'd need.
Well you could do it by adding an install rule to /etc/modprobe.d so that the unbind automatically runs after the module is loaded. Sure it would be claimed initially, but is the device left in a state where the driver disassociating would cause a problem?
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Takashi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2009 11:46 AM, Takashi Iwai wrote:
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Yeah, but then we're in essentially the same position as we would be if we just blacklisted the module entirely, right?
- -Jeff
- -- Jeff Mahoney SUSE Labs
At Mon, 07 Dec 2009 11:51:58 -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2009 11:46 AM, Takashi Iwai wrote:
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Yeah, but then we're in essentially the same position as we would be if we just blacklisted the module entirely, right?
No, what I suggest is to write a script to check lspci, then load the module selectively only when any of lspci devices aren't on the blacklist.
For example, something like below: % cat /sbin/i915_loader.sh #!/bin/sh modeset="" /sbin/lspci -n | grep -q 1234:5678 || modeset="modeset=1" exec /sbin/modprobe i915 $modeset
Then add a line below to modprobe.d/somewhere.conf install i915 /sbin/i915_loader.sh
Takashi
On Mon, Dec 07, 2009 at 05:58:20PM +0100, Takashi Iwai wrote:
At Mon, 07 Dec 2009 11:51:58 -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2009 11:46 AM, Takashi Iwai wrote:
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Yeah, but then we're in essentially the same position as we would be if we just blacklisted the module entirely, right?
No, what I suggest is to write a script to check lspci, then load the module selectively only when any of lspci devices aren't on the blacklist.
For example, something like below: % cat /sbin/i915_loader.sh #!/bin/sh modeset="" /sbin/lspci -n | grep -q 1234:5678 || modeset="modeset=1" exec /sbin/modprobe i915 $modeset
Then add a line below to modprobe.d/somewhere.conf install i915 /sbin/i915_loader.sh
Should be: install --ignoreinstall i915 /sbin/i915_loader.sh to avoid a loop.
Thanks for the idea, Takashi! This will do the trick :)
Cheers, Egbert.
On Thu, Dec 10, 2009 at 12:16:28PM +0100, Egbert Eich wrote:
On Mon, Dec 07, 2009 at 05:58:20PM +0100, Takashi Iwai wrote:
At Mon, 07 Dec 2009 11:51:58 -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2009 11:46 AM, Takashi Iwai wrote:
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Yeah, but then we're in essentially the same position as we would be if we just blacklisted the module entirely, right?
No, what I suggest is to write a script to check lspci, then load the module selectively only when any of lspci devices aren't on the blacklist.
For example, something like below: % cat /sbin/i915_loader.sh #!/bin/sh modeset="" /sbin/lspci -n | grep -q 1234:5678 || modeset="modeset=1" exec /sbin/modprobe i915 $modeset
Then add a line below to modprobe.d/somewhere.conf install i915 /sbin/i915_loader.sh
Should be: install --ignoreinstall i915 /sbin/i915_loader.sh to avoid a loop.
You mean
exec /sbin/modprobe --ignoreinstall i915 $modeset
in the script, don't you?
CU, Stefan
Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------
On Mon, Dec 07, 2009 at 11:51:58AM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2009 11:46 AM, Takashi Iwai wrote:
At Sun, 06 Dec 2009 18:34:52 -0500, Jeff Mahoney wrote:
The problem in general is that we can't tell the kernel about rules for a module without first loading the module.
But we can know the PCI id before loading the corresponding module, at least. So, it'd be possible to load the module only when no blacklisted pci id is found in the modprobe install script.
Yeah, but then we're in essentially the same position as we would be if we just blacklisted the module entirely, right?
Not exactly. We can maintain and update a per device alias blacklist here at openSUSE. The user doesn't have to make any additions to the blacklist file he doesn't understand anyhow.
Cheers, Egbert.
On Sun, Dec 06, 2009 at 06:34:52PM -0500, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Well you could do it by adding an install rule to /etc/modprobe.d so that the unbind automatically runs after the module is loaded. Sure it would be claimed initially, but is the device left in a state where the driver disassociating would cause a problem?
Part of why we would like to have this is that the driver may be broken and loading it may crash the system with this particular device already. Therefore unbinding will of no use any more.
You may say: Then fix the d*** driver. But this may not always be possible. Those graphics chips have more transistors than your CPU, are much less well understood and change more rapidly than you can blink your eyes. So while the driver works in general it may fail on some PCI vendor/device/subvendor/subdevice ID (or requires a special option). I don't think this will change suddenly with the driver being in the kernel.
Cheers, Egbert.
Torsdag den 3. december 2009 14:38:29 skrev Egbert Eich:
Folks -
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early.
Unless I'm mistaken you didn't really account for the changes from a user point of view :-)
Will installing and using nvidia or fglrx blobs become more complicated and perhaps affected in other ways by enabling kms by default?
What happens for people with chips not supported or poorly supported by kms- drivers?
.. of course I guess I could find the answers to these questions on fedora forums :-)
On Thu, Dec 03, 2009 at 03:32:36PM +0100, Martin Schlander wrote:
Torsdag den 3. december 2009 14:38:29 skrev Egbert Eich:
Folks -
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early.
Unless I'm mistaken you didn't really account for the changes from a user point of view :-)
Hrm, I tought I did...
Will installing and using nvidia or fglrx blobs become more complicated and perhaps affected in other ways by enabling kms by default?
No, please check my reply to Petr's email.
What happens for people with chips not supported or poorly supported by kms- drivers?
If we find chips poorly supported we can go and blacklist them - provided there still is a userland X driver for them. Intel for example is going to abandon UL modesetting entirely soon.
.. of course I guess I could find the answers to these questions on fedora forums :-)
Or just ask them here...?
Cheers, Egbert.
On 12/03/2009 08:38 AM, Egbert Eich pecked at the keyboard and wrote:
Folks -
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution. Furthermore test packages are available to try things out on Factory. I would like to encourage people interested in development and technical discussions in general to participate in the discussion and the development efforts.
Kernel Modesetting (KMS)
All of you who are using a graphical desktop on Linux have been using the X Window Sytem. The X Window System Server (XServer) is the instance which receives requests from your desktop applications to draw all the widgets (windows, buttons, images etc.) you see on your desktop. It also processes input from your keyboard and mouse and sends them to applications as events. Traditionally on Linux the XServer does not only draw images to the screen (ie writes them to some sort of frame buffer) but it is in charge of initializing, setting up and driving the graphics hardware.
This paradigm which has been true since the X Window System has been ported to Linux is about to change: Much of the initialization, set up (video mode setting) and control of the graphics hardware is about to move to the Linux kernel.
There are a number of advantages to this:
- A central instance is in charge of the graphics hardware, other user mode applications (not just the Xserver) can take advantage of mode setting.
- The Xserver will no longer require full root privileges as it doesn't talk to the hardware directly any more.
- Faster boot process: The Xserver doesn't need to (re)initialize the graphics hardware any more, this is all done by the kernel very early in the boot cycle.
- Smoother (flicker free) boot experience: The screen doesn't flicker and changes resolution any more when the Xserver starts.
- One central entity is in charge and manages the resources of the graphics hardware - like the video memory which makes sharing of these resources between several applications (like Xserver and several DRI (Direct Rendering 3D) applications much easier.
KMS is integrated in the DRM drivers. In the near future most graphics driver will switch to KMS:
- Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only.
- KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets.
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future.
Integration in openSUSE
Now this begs the question what we have to do to integrate it into openSUSE. Originall I had plans to look into this for openSUSE 11.2 already - but then I got side tracked by other stuff it fell on the floor and noone else beat me to it either ... oh well. Now I had the chance to play around with KMS a little and came up with some ideas and a proof of concept. It turned out that the changes to openSUSE needed to fully support KMS are quite small. Key is to load the KMS aware DRM driver as early as possible in the boot process to avoid video mode changes later in the boot cycle - preferrably in the initrd.
The Boot Process
On openSUSE the boot loader is configured for two boot scenarios: default and failsafe. The user can select the failsafe boot scenario in case the default scenario does not work for him. In the failsafe scenario certain features are deactivated which have shown to cause problems on some systems.
Since KMS is a new feature it is a candidate for deactivation during a failsafe boot. Instead the system should then boot into the VESA framebuffer mode. Should this also fail the kernel will automatically fall back to a VGA text mode. To disable KMS on boot a new boot parameter is introduced: 'nomodeset'. This parameter is to the boot command line for the failsafe mode. The user may add this parameter by hand for any other boot mode.
The kernel command line is parsed in initrd and an appropriate entry is created in /etc/modprobe.d/options. Furthermore the graphics driver module and - if required - the agp module(s) are added in the correct order (agp modules first) to the list of modules to be loaded initially.
Changes to individual packages
- yast2-bootloader & perl-Bootloader
The boot parameter 'nomodeset' is added to the failsafe boot paramter lists in each of the modules. (I have not been able to find out which module provides the entry relevant for which situation, therefore I've whacked both.) yast2-bootloader updates the variable FAILSAFE_APPEND in /etc/sysconfig/bootloader appropriately.
- kernel-source
To use KMS for a certain DRM driver the kernel config option CONFIG_DRM_<driver_name>_KMS needs to be set to 'y'. At the moment we will support KMS only for Intel hardware, thus only the variable CONFIG_DRM_I915_KMS needs to be changed.
In the sample build this has been enabled for the -default, -desktop, -pae, -debug, -trace and -vanilla kernels for the i386 and x86_64 platforms.
The kernel boot splash has already been fixed for KMS for openSUSE 11.2.
- mkinitrd
This package writes the initrd file. To add KMS support to the initrd mkinitrd needs to perform the following tasks:
Check the sysconfig variable NO_KMS_IN_INITRD, if set, don't attempt to install a KMS DRM capable driver.
Obtain a list of PCI devices installed on the system.
a. In the list of PCI devices identify those devices which are of class VGA and look for a matching driver. b. Before a driver is matched check the PCI vendor, device, subvendor and subdevice ids against a blacklist in /etc/kms/blacklist should this file exist. This file contains one vendor, device, subvendor and subdevice id per line, '*' serves as a wildchar, trailing wildchars may be ommitted, '#' at the beginning of a line serves as a comment. c. Use the standard modprobe alias mechanism to find a matching DRM driver module. This way standard blacklistings of kernel modules will be honored and update modules will be searched if they are available. KMS capable DRM drivers provide an alias list (in contrast to non-KMS capable DRM drivers which are to be loaded explicitely by the Xserver). d. If a driver is found check for a black listing in /etc/kms/<driver_name>.blacklist. The same rules as in 3 b. apply.
If a KMS capable DRM driver is found search for an agp driver: a. Obtain a list of all known agp drivers for the specific kernel and collect their alias lists. b. Match all installed PCI devices against the alias lists of each agp driver. If a match is found add the driver to the lists of modules to be loaded. Make sure that this driver is loaded prior the the DRM driver.
Two scripts setup-kms.sh and boot-kms.sh are added to mkinitrd. The former performs the tasks listed above, the latter provides the required module dependencies in the required order, parses the boot command line for the 'nomodeset' option and adds the apropriate entry to /etc/modprobe.d/options. The linuxrc script is extended to search the boot command line for <drivername>.<option>=* strings for each driver loaded in initrd and add the <option>=* part to /etc/modprobe.d/options.
- udev
Udev loads any modules which are not loaded by linuxrc scripts directly. It is possible to let udev load the required DRM and AGP modules provided it is made sure that this happens in the correct order. Since there is no explicit dependency of DRM modules to AGP drivers as there is no general one to one match between the two drivers a udev rule must exist to enforce the correct order for all cases where a AGP module is required. This is true for Intel DRM drivers and any other driver for an AGP graphics chip. For this a rule file 79-waitfor-agp.rules is added which is run before 80-drivers.rules. It checks if either an Intel graphics (class VGA) device is processed or if the graphics device is an AGP device. The latter condition is tested by an auxiliary tool (is_agp) which is passed the kernel name of the event device. If either condition is true udev will wait for /dev/agpgart to appear before proceeding to load a DRM driver module. 'is_agp' checks the capabilities flags in the PCI config space of this device for AGP.
I keep seeing reference to "DRM" here. Is that referring to Digital Rights Management? If not, the acronym needs to be changed.
2009/12/3 Ken Schneider - Factory suse-list3@bout-tyme.net:
I keep seeing reference to "DRM" here. Is that referring to Digital Rights Management? If not, the acronym needs to be changed.
Glossary at http://wiki.x.org/wiki/radeonhd?action=fullsearch&context=180&value=...
Direct Render Manager - the X developers have used term DRM for quite a while, doubt they'll change the acronym now. It is unfortunate I agree.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2009 11:13 AM, Ken Schneider - Factory wrote:
I keep seeing reference to "DRM" here. Is that referring to Digital Rights Management? If not, the acronym needs to be changed.
Nope. Direct Rendering Manager. The acronym has been around since 2001, so don't hold your breath on it changing.
- -Jeff
- -- Jeff Mahoney SUSE Labs
2009/12/3 Egbert Eich eich@suse.de:
- Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only.
They even dropped UMS support from DDX driver, so 2.10 won't contain it.
- KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets.
With .33 it will hopefully leave staging. It already contains more features like OpenGL 1.5 and IRQs when comparing to not-KMS. 33 should bring more feature like HDMI and basic power management.
So yes, we definitely should switch to KMS.
Hi,
What about case of using closed NVIDIA drivers? Framebuffer can't set 1920×1080 with my card, it supports only 4:3 resolutions.
I saw Nouveau on Fedora setting this HD resolution easily and using it in Plymouth and then X.Org.
How is it possible?
What is the mode Plymouth is using? It's not the same text mode as plain Linux used to use. Or am I 2008 with it?
I don't understand how Nouveau, a X.Org display driver with kernel module can set desired widescreen res, while framebuffer with vesafb sets only 4:3 oO .
2009/12/3 Jakub 'Livio' Rusinek jakub.rusinek@gmail.com:
What about case of using closed NVIDIA drivers? Framebuffer can't set 1920×1080 with my card, it supports only 4:3 resolutions.
I saw Nouveau on Fedora setting this HD resolution easily and using it in Plymouth and then X.Org.
How is it possible?
KMS drivers set your modes in way it's normally done for X. This mean setting all that CRTCs, encoders, PLLs, outputs. That gives the same possibilities for console (fbcon module) as it's normally available for X.
On Thu, Dec 03, 2009 at 07:42:27PM +0100, Jakub 'Livio' Rusinek wrote:
Hi,
What about case of using closed NVIDIA drivers? Framebuffer can't set 1920×1080 with my card, it supports only 4:3 resolutions.
The closed source NVIDIA driver will not support KMS in the forseeable future.
I saw Nouveau on Fedora setting this HD resolution easily and using it in Plymouth and then X.Org.
How is it possible?
What is the mode Plymouth is using? It's not the same text mode as plain Linux used to use. Or am I 2008 with it?
I don't understand how Nouveau, a X.Org display driver with kernel module can set desired widescreen res, while framebuffer with vesafb sets only 4:3 oO .
VESA uses a hard coded set of modes. Your's may not be among them. I think only VBE 3.0 supports programmable modes (need to recheck to be sure) but VBE 3.0 support is often broken anyway as it is not used by any (commercial) OS vendor.
Cheers, Egbert.
On 03.12.2009 20:56, Egbert Eich wrote:
On Thu, Dec 03, 2009 at 07:42:27PM +0100, Jakub 'Livio' Rusinek wrote:
Hi,
What about case of using closed NVIDIA drivers? Framebuffer can't set 1920×1080 with my card, it supports only 4:3 resolutions.
The closed source NVIDIA driver will not support KMS in the forseeable future.
This is obvious (; .
I saw Nouveau on Fedora setting this HD resolution easily and using it in Plymouth and then X.Org.
How is it possible?
What is the mode Plymouth is using? It's not the same text mode as plain Linux used to use. Or am I 2008 with it?
I don't understand how Nouveau, a X.Org display driver with kernel module can set desired widescreen res, while framebuffer with vesafb sets only 4:3 oO .
VESA uses a hard coded set of modes. Your's may not be among them. I think only VBE 3.0 supports programmable modes (need to recheck to be sure) but VBE 3.0 support is often broken anyway as it is not used by any (commercial) OS vendor.
This is an interesting case. Interesting, if there's a man who can explain hardcoded set of resolutions with reasonable arguments...
VESA uses a hard coded set of modes. Your's may not be among them. I think only VBE 3.0 supports programmable modes (need to recheck to be sure) but VBE 3.0 support is often broken anyway as it is not used by any (commercial) OS vendor.
This is an interesting case. Interesting, if there's a man who can explain hardcoded set of resolutions with reasonable arguments...
Because standards are only good when they are easy to implement, and back in the days everybody was using 4:3 screens and resolutions didn't explode like they do these days, so this was something everybody could agree to Today it is only important as fall back option, so why push ahead with a more complicated standard if the old one does the error resolving case pretty good?
On 2009/12/03 14:38 (GMT+0100) Egbert Eich composed: [a lot]
Is it naive to expect KMS will have no negative impact on my ability to run 1856x1392 on tty7 while running 1400x1050 on tty8 while running 1024x768 on tty9 using a single gfx card and display and open source driver?
On Thu, Dec 03, 2009 at 07:27:58PM -0500, Felix Miata wrote:
On 2009/12/03 14:38 (GMT+0100) Egbert Eich composed: [a lot]
Is it naive to expect KMS will have no negative impact on my ability to run 1856x1392 on tty7 while running 1400x1050 on tty8 while running 1024x768 on tty9 using a single gfx card and display and open source driver?
This begs the question why you want to do this. The majority of users today run flat panel monitors (I know there are exceptions and there is no need to try to convince me differently). Flat panels work well on their native resolution. Anything other than native resolution will get rescaled internally and will look fuzzy or blurry in some way. Thus you want to run it at its native resolution as much as possible. DDC tells the 'preferred mode' and KMS will try to set it on startup. This should prevent you from ever having to switch modes.
However there is nothing in KMS that prevents you from switching modes. I'm not sure if you can have different resolutions on different virtual text consoles (or if chaning it for one console it will change it for all) but if you run X for example it will be able to set a different resolution than your text console. There is nothing in the design of KMS that would prevent this.
Cheers, Egbert.
On 2009/12/04 08:19 (GMT+0100) Egbert Eich composed:
On Thu, Dec 03, 2009 at 19:27:58 -0500, Felix Miata wrote:
Is it naive to expect KMS will have no negative impact on my ability to run 1856x1392 on tty7 while running 1400x1050 on tty8 while running 1024x768 on tty9 using a single gfx card and display and open source driver?
This begs the question why you want to do this.
Because I can (and do) now, and don't want to lose the ability. :-)
Better answer: Web site development flexibility. It's easier to see what users see using different settings when you use some of their settings life size. It's a lot more comfortable to do the evaluations without the head turning required using the multiple displays required if sticking to native flat panel resolutions. A quality CRT can run the gamut of resolutions too. To run the gamut with LCDs would take a mountain of wiring and physical space, not to mention all the extra hardware. AFAIK what I asked about and do is impossible on a Mac or Windoz.
Or maybe I want the same mode on more than one, but without panning enabled on one (straight 1600x1200), and with on another (1600x1200 plus panning to 1920 wide to emulate WUXGA).
The majority of users today run flat panel monitors (I know there are exceptions and there is no need to try to convince me differently).
FWIW, did you happen to notice that 100% of the modes I listed are 4:3 modes that few currently available-on-store-shelves LCDs can do?
Flat panels work well on their native resolution. Anything other than native resolution will get rescaled internally and will look fuzzy or blurry in some way. Thus you want to run it at its native resolution as much as possible.
Which is why I use a 4:3 CRT.
DDC tells the 'preferred mode' and KMS will try to set it on startup. This should prevent you from ever having to switch modes.
Less flexibility is not for me. I'll clip the DDC pin off the cable's plug if I have to to prevent smarty pants X from telling me what mode I must use on a CRT.
However there is nothing in KMS that prevents you from switching modes. I'm not sure if you can have different resolutions on different virtual text consoles (or if chaning it for one console it will change it for all)
This is the inverse of the question I originally asked. I'd normally rather all text consoles use the same, but might on occasion want different.
but if you run X for example it will be able to set a different resolution than your text console.
There is nothing in the design of KMS that would prevent this.
I hope. Quoting you from several hours ago: "It often doesn't work that way. Devs often have high flying goals and discover in the end the hard way that they cannot deliver."
On Fri, Dec 04, 2009 at 03:05:41AM -0500, Felix Miata wrote:
Because I can (and do) now, and don't want to lose the ability. :-)
Better answer: Web site development flexibility. It's easier to see what users see using different settings when you use some of their settings life size. It's a lot more comfortable to do the evaluations without the head turning required using the multiple displays required if sticking to native flat panel resolutions. A quality CRT can run the gamut of resolutions too. To run the gamut with LCDs would take a mountain of wiring and physical space, not to mention all the extra hardware. AFAIK what I asked about and do is impossible on a Mac or Windoz.
Or maybe I want the same mode on more than one, but without panning enabled on one (straight 1600x1200), and with on another (1600x1200 plus panning to 1920 wide to emulate WUXGA).
Fine. Xrandr supports that.
In my original posting I mentioned the standard use case and how it is tried to make this use case the default. But I also mentioned that if you need/want something else support is there to change it.
The majority of users today run flat panel monitors (I know there are exceptions and there is no need to try to convince me differently).
FWIW, did you happen to notice that 100% of the modes I listed are 4:3 modes that few currently available-on-store-shelves LCDs can do?
Flat panels work well on their native resolution. Anything other than native resolution will get rescaled internally and will look fuzzy or blurry in some way. Thus you want to run it at its native resolution as much as possible.
Which is why I use a 4:3 CRT.
DDC tells the 'preferred mode' and KMS will try to set it on startup. This should prevent you from ever having to switch modes.
Less flexibility is not for me. I'll clip the DDC pin off the cable's plug if I have to to prevent smarty pants X from telling me what mode I must use on a CRT.
Have you actually been following this thread or have you just dropped in for ranting? I think it has been mentioned ample times here that you can switch modes with xrandr and set your favorite mode while your X session is running. The desktop tools for xrandr will remember the last mode you've set and reset it next time you log in.
The things you are mentioning in your message have been supported by xrandr or have been added (even panning is back now thanks to Matthias Hopf).
I really fail to see what tree you are barking at. I believe that xrandr adds a lot of flexibility which will make things you want to do more easy than ever before.
However there is nothing in KMS that prevents you from switching modes. I'm not sure if you can have different resolutions on different virtual text consoles (or if chaning it for one console it will change it for all)
This is the inverse of the question I originally asked. I'd normally rather all text consoles use the same, but might on occasion want different.
but if you run X for example it will be able to set a different resolution than your text console.
There is nothing in the design of KMS that would prevent this.
I hope. Quoting you from several hours ago: "It often doesn't work that way. Devs often have high flying goals and discover in the end the hard way that they cannot deliver."
Oh, I strongly believe what you need is supported and is working well.
But if not - what do you want to do about it? Rant about it endlessly?
This will only distract people who are able to fix thing from doing so.
What keeps bothering me is the undertone in a few - definitely not all - of the messages here. I keep finding the same undertone in bugzilla: endless sarcastic rants blaming those who do the work for not working even more and harder and letting them know how stupid they are breaking or no longer supporting certain features.
What do you suggest we do? Stop developing so that things stay the same as they have in the past? Tell people to shop for hardware on Ebay to find stuff old enough to run on those system?
Certainly noone can rule out that desing decisions are made which have a stronger impact on existing functionality than strictly necessary and sometimes those people who make the decisions don't look beyond their plates and envision the needs of others - but in the free software world it's the people who do the work who decide how things will look like. Those doing work on openSUSE don't always have full control over such things and need to stick with what others have decided in the upstream project.
Cheers, Egbert.
2009/12/4 Egbert Eich eich@suse.de:
On Thu, Dec 03, 2009 at 07:27:58PM -0500, Felix Miata wrote:
On 2009/12/03 14:38 (GMT+0100) Egbert Eich composed:
DDC tells the 'preferred mode' and KMS will try to set it on startup. This should prevent you from ever having to switch modes.
Nvidia GS8300 was fairly recent card DX 10 card (2 years old) which did not pass DDC info through. I presume KMS will help with that sort of situation with an auto-configure X, because on boot you can tell the kernel what mode to use and hopefully that selection will be respected by X.
At the moment, the auto-configure might annoy the user by choosing non-ideal mode.
However there is nothing in KMS that prevents you from switching modes. I'm not sure if you can have different resolutions on different virtual text consoles (or if chaning it for one console it will change it for all) but if you run X for example it will be able to set a different resolution than your text console. There is nothing in the design of KMS that would prevent this.
Isn't the point, that when the same mode is used for virtual console & X, that you avoid flicker & unecessary re-setting modes when they have not changed.
Instead of kernel and X changing modes, the kernel has full responsibility rather than sharing it with user space.
So KMS has to support the X RandR resolution mode changes offered by user-space tools.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2009-12-03 at 14:38 +0100, Egbert Eich wrote:
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution.
(scared)
(sounds interesting, but I'm scared)
...
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets.
The nouveau driver is not included with the distro since 11.1 at least. There is no maintainer. See the thread where I asked about it a few days ago.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future.
:-(
- -- Cheers, Carlos E. R.
On Mon, Dec 07, 2009 at 02:38:31PM +0100, Carlos E. R. wrote:
On Thursday, 2009-12-03 at 14:38 +0100, Egbert Eich wrote:
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution.
(scared)
(sounds interesting, but I'm scared)
We didn't have a deep technical discussion so far. So no worries ;)
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets.
This is again such a thing: we need volunteers to do this. The three people at Novell who are dealing with X Window System related stuff are totally swamped with other stuff - I can rest everybody assured of that. It's not only openSUSE we need to deal with - there are also enterprise products to worry about so that Novell can earn the money that it needs to support openSUSE.
And people are not exactly sitting at their computers and surf the web all day.
Cheers, Egbert.
2009/12/7 Egbert Eich eich@suse.de:
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA
chipsets.
This is again such a thing: we need volunteers to do this. The three people at Novell who are dealing with X Window System related stuff are totally swamped with other stuff - I can rest everybody assured of that. It's not only openSUSE we need to deal with
So are AMD/ATI beneffitting from having released documentation, with work towards better FOSS support?
With time since the Direct Render 3D stuff came in, I've noticed less and less stuff working well with non-proprietary drivers (usually Nvidia) though I don't have any decent Intel Integrade boxen where I do read about improvements. In past, I could point out when folk found proprietary driver were legacied, that FOSS driver stuff was supported for longer.
Now is frustrating time, as the newer ATI cards haven't got FOSS 3D support yet, and the older ones not supported by AMD/ATI are also keenly waiting on FOSS 3D drivers. Ironically, I've got more use out of ATI card upgrade on Windows, rather than the original intention of supporting Linux driver development.
Totally understand there have to be priorities, and displaying 2D desktop has to come first, it'd just be good to know the way things are heading, when the rants start on forums.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2009-12-07 at 17:26 -0000, Rob OpenSuSE wrote:
...
With time since the Direct Render 3D stuff came in, I've noticed less and less stuff working well with non-proprietary drivers (usually Nvidia)
My new computer can not hibernate with the open nv driver, only with the closed nvidia driver. I wanted to try nouveau, but is it no more.
Bad bad.
- -- Cheers, Carlos E. R.
Hi Egbert,
might be a stupid question, but I'll ask it anyway ;)
Running plain FACTORY (without your fancy kernel package etc.), I can boot with "vga=0", then when the system is running (in runlevel 3), I can "modprobe radeon modeset=1" and I will get a beautiful 1400x1050 framebuffer.
Then I can start X ("X :0 -retro") and get a nice X server. However, switching back to the text console seems to blank the screen shortly, and I still get the occasional "synchronization loss" on the built-in panel (Matthias knows what I'm talking about). Switching VT to X and back still solves this (phew! we anticipated that with kms, once the pll is screwed there would be no way to recover short of a reboot).
So I guess that KMS is not working well in this setup, since some PLL is still reprogrammed (and sometimes this fails).
All on an oldish ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Now I wanted to put the module in the initrd, however, loading it from "init=/bin/bash" (I tried that first, just to make sure) gives me a kernel backtrace and basically kills the box.
Is this all the fault of me not running your pimped packages or is there something more fundamentally borken on this old and incredibly slow radeon card? (the driver is so slow, that I hoped I could use KMS and then fbdev X server - it can only get faster).
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com:
Then I can start X ("X :0 -retro") and get a nice X server. However, switching back to the text console seems to blank the screen shortly, and I still get the occasional "synchronization loss" on the built-in panel (Matthias knows what I'm talking about). Switching VT to X and back still solves this (phew! we anticipated that with kms, once the pll is screwed there would be no way to recover short of a reboot).
So I guess that KMS is not working well in this setup, since some PLL is still reprogrammed (and sometimes this fails).
Alex is working on PLL now and commited some patches already. Probably would be worth trying git and if that still happens, then report bug.
On Thu, 10 Dec 2009 20:27:55 +0100 Rafał Miłecki zajec5polish@gmail.com wrote:
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com: Alex is working on PLL now and commited some patches already. Probably would be worth trying git and if that still happens, then report bug.
git what? git kernel? git X? git Mesa?
I might consider building a kernel, but not the X server and its myriad of dependencies ;)
I was wondering if KMS was used AT ALL on this machine, since at least when I tried it on intel, it looked like the X server was "using the same frame buffer" as the console. No backlight flickering when switching from console to X and back.
With the radeon driver, it looks like this is different. This is where my doubts come from ;)
The PLL problem has been there forever on those machines, so It is nothing new.
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com:
On Thu, 10 Dec 2009 20:27:55 +0100 Rafał Miłecki zajec5polish@gmail.com wrote:
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com: Alex is working on PLL now and commited some patches already. Probably would be worth trying git and if that still happens, then report bug.
git what? git kernel? git X? git Mesa?
I might consider building a kernel, but not the X server and its myriad of dependencies ;)
We talk about KMS, so I've meant kernel of course :)
On 14/12/09 06:39, Rafał Miłecki wrote:
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com:
On Thu, 10 Dec 2009 20:27:55 +0100 Rafał Miłecki zajec5polish@gmail.com wrote:
2009/12/10 Stefan Seyfried stefan.seyfried@googlemail.com: Alex is working on PLL now and commited some patches already. Probably would be worth trying git and if that still happens, then report bug.
git what? git kernel? git X? git Mesa?
I might consider building a kernel, but not the X server and its myriad of dependencies ;)
We talk about KMS, so I've meant kernel of course :)
I thought the subject line and the copious details in the texts would have been a dead giveaway to anyone staying awake. Regards Sid.
On Thu, Dec 10, 2009 at 01:41:57PM +0100, Stefan Seyfried wrote:
Hi Stefan,
sorry for the late answer.
Hi Egbert,
might be a stupid question, but I'll ask it anyway ;)
Running plain FACTORY (without your fancy kernel package etc.), I can boot with "vga=0", then when the system is running (in runlevel 3), I can "modprobe radeon modeset=1" and I will get a beautiful 1400x1050 framebuffer.
Then I can start X ("X :0 -retro") and get a nice X server. However, switching back to the text console seems to blank the screen shortly, and I still get the occasional "synchronization loss" on the built-in panel (Matthias knows what I'm talking about). Switching VT to X and back still solves this (phew! we anticipated that with kms, once the pll is screwed there would be no way to recover short of a reboot).
This is strange and shouldn't happen at least when using the radeon driver. Since we don't support KMS for anything but Intel at this moment I have not looked into this more deeply. If X and the console have the same resolution there shouldn't be any flicker.
So I guess that KMS is not working well in this setup, since some PLL is still reprogrammed (and sometimes this fails).
All on an oldish ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Now I wanted to put the module in the initrd, however, loading it from "init=/bin/bash" (I tried that first, just to make sure) gives me a kernel backtrace and basically kills the box.
Also strange. Is this because you still need to load an AGP module?
Cheers, Egbert.
Egbert Eich wrote:
Since we don't support KMS for anything but Intel at this moment I have not looked into this more deeply.
As I have now read that the 2.6.33 kernel includes the nouveau driver and supports KMS for it as well, is there a plan for shipping at least the 2D driver for X as well? (though I read that with some cards, X.org server 1.7 is recommended for nouveau - do we have plans for that in 11.3?)
From what I gather, other distros seem to have been shipping nouveau for some time now, and we would be able to support KMS for all major cards, which might be a good idea overall.
Of course, I'm just a humble Factory and NVidia user, spending my time on an unrelated upstream project (SeaMonkey), so I can only ask, hope and watch - but as a project manager, I understand that things aren't always as easy as they sound in the first place. ;-)
Robert Kaiser
On 13/01/10 12:31, Robert Kaiser wrote:
Egbert Eich wrote:
Since we don't support KMS for anything but Intel at this moment I have not looked into this more deeply.
As I have now read that the 2.6.33 kernel includes the nouveau driver and supports KMS for it as well, is there a plan for shipping at least the 2D driver for X as well? (though I read that with some cards, X.org server 1.7 is recommended for nouveau - do we have plans for that in 11.3?)
From what I gather, other distros seem to have been shipping nouveau for some time now, and we would be able to support KMS for all major cards, which might be a good idea overall.
Of course, I'm just a humble Factory and NVidia user, spending my time on an unrelated upstream project (SeaMonkey), so I can only ask, hope and watch - but as a project manager, I understand that things aren't always as easy as they sound in the first place. ;-)
Robert Kaiser
I have been looking up what chipsets the nouveau driver supports and it seems limited, e.g the GeForce 8600 (G84) and 8800 (G92) are not supported. I shall have to ask upstream if they can provide a list as it takes quite a lot of digging through google to discover what nv?? driver equates to what cards. I haven't checked the other distros, but presumably they still rely on the closed source NVidia driver to support these other cards and chipsets. I eventually found a list at http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units#... Regards Sid.
Sid Boyce wrote:
I have been looking up what chipsets the nouveau driver supports and it seems limited, e.g the GeForce 8600 (G84) and 8800 (G92) are not supported.
From what I read on http://nouveau.freedesktop.org/wiki/FeatureMatrix that's not true, as those are NV50 series chips and those are well-supported in 2D - which is not worse than what we ship by default right now (the old open nv driver), with the difference that KMS is supported and an experimental (or highly experimental) 3D driver does exist.
Jakub 'Livio' Rusinek wrote:
What's funny when it comes to KMS on nVidia, is the fact, that nouveau gives you only KMS and nice splash appearance (Fedora, Mandriva), while closed blob driver gives you all other features.
Nouveau is just useless eye candy at the moment :/ .
It's not worse than what openSUSE currently ships as a default, on the contrary, by supporting KMS and therefore potentially being able to run X as user instead of root and possibly making startup somewhat faster and less flickery, it's already better now than our default. Of course, the closed driver gives 3D support, but that one is not what openSUSE can ship by default, now or in the future, so there's no change with respect to that - but even if nouveau's 3D support is highly experimental not not shippable as a default right now, we can go some part of the way and give the stable part to users (and help making it even better by having more people run it and potentially report remaining problems) and pave the way for adding the 3D part when it becomes usable (and make it easier for the bold bleeding-edge type who wants to test it).
Robert Kaiser
On 13/01/10 22:30, Robert Kaiser wrote:
Sid Boyce wrote:
I have been looking up what chipsets the nouveau driver supports and it seems limited, e.g the GeForce 8600 (G84) and 8800 (G92) are not supported.
From what I read on http://nouveau.freedesktop.org/wiki/FeatureMatrix that's not true, as those are NV50 series chips and those are well-supported in 2D - which is not worse than what we ship by default right now (the old open nv driver), with the difference that KMS is supported and an experimental (or highly experimental) 3D driver does exist.
In the FeatureMatrix I see no mention of those cards and what I posted was from wikipedia which cross referenced cards and codenames and from that deduced that those cards weren't supported to date.
Jakub 'Livio' Rusinek wrote:
What's funny when it comes to KMS on nVidia, is the fact, that nouveau gives you only KMS and nice splash appearance (Fedora, Mandriva), while closed blob driver gives you all other features.
Nouveau is just useless eye candy at the moment :/ .
It's not worse than what openSUSE currently ships as a default, on the contrary, by supporting KMS and therefore potentially being able to run X as user instead of root and possibly making startup somewhat faster and less flickery, it's already better now than our default. Of course, the closed driver gives 3D support, but that one is not what openSUSE can ship by default, now or in the future, so there's no change with respect to that - but even if nouveau's 3D support is highly experimental not not shippable as a default right now, we can go some part of the way and give the stable part to users (and help making it even better by having more people run it and potentially report remaining problems) and pave the way for adding the 3D part when it becomes usable (and make it easier for the bold bleeding-edge type who wants to test it).
Robert Kaiser
I always like to join in the effort as a tester of new stuff. Thanks & Regards Sid.
Sid Boyce wrote:
On 13/01/10 22:30, Robert Kaiser wrote:
Sid Boyce wrote:
I have been looking up what chipsets the nouveau driver supports and it seems limited, e.g the GeForce 8600 (G84) and 8800 (G92) are not supported.
From what I read on http://nouveau.freedesktop.org/wiki/FeatureMatrix that's not true, as those are NV50 series chips and those are well-supported in 2D - which is not worse than what we ship by default right now (the old open nv driver), with the difference that KMS is supported and an experimental (or highly experimental) 3D driver does exist.
In the FeatureMatrix I see no mention of those cards and what I posted was from wikipedia which cross referenced cards and codenames and from that deduced that those cards weren't supported to date.
Click on the "NV50" column header link leading to the code names document and look at what is listed in the "NV50 family" section.
Robert Kaiser
On 13/01/10 23:38, Robert Kaiser wrote:
Sid Boyce wrote:
On 13/01/10 22:30, Robert Kaiser wrote:
Sid Boyce wrote:
I have been looking up what chipsets the nouveau driver supports and it seems limited, e.g the GeForce 8600 (G84) and 8800 (G92) are not supported.
From what I read on http://nouveau.freedesktop.org/wiki/FeatureMatrix that's not true, as those are NV50 series chips and those are well-supported in 2D - which is not worse than what we ship by default right now (the old open nv driver), with the difference that KMS is supported and an experimental (or highly experimental) 3D driver does exist.
In the FeatureMatrix I see no mention of those cards and what I posted was from wikipedia which cross referenced cards and codenames and from that deduced that those cards weren't supported to date.
Click on the "NV50" column header link leading to the code names document and look at what is listed in the "NV50 family" section.
Robert Kaiser
Thanks, so that's where they were hiding. Regards Sid. P.S:- Apologies for the reply sent direct, I hit reply instead of reply to list.
On Wed, Jan 13, 2010 at 01:31:46PM +0100, Robert Kaiser wrote:
Egbert Eich wrote:
Since we don't support KMS for anything but Intel at this moment I have not looked into this more deeply.
As I have now read that the 2.6.33 kernel includes the nouveau driver and supports KMS for it as well, is there a plan for shipping at least the 2D driver for X as well? (though I read that with some cards, X.org server 1.7 is recommended for nouveau - do we have plans for that in 11.3?)
From what I gather, other distros seem to have been shipping nouveau for some time now, and we would be able to support KMS for all major cards, which might be a good idea overall.
Of course, I'm just a humble Factory and NVidia user, spending my time on an unrelated upstream project (SeaMonkey), so I can only ask, hope and watch - but as a project manager, I understand that things aren't always as easy as they sound in the first place. ;-)
Luckily I'm not a project manager either :) I would like to ship the nouveau driver as an alternative. Presently the only free software solution is the nv driver which has its issues and is not 3d capable. Being that the drm part is in the mainline kernel now is going to make this a lot easier.
Cheers, Egbert.
Hi,
What's funny when it comes to KMS on nVidia, is the fact, that nouveau gives you only KMS and nice splash appearance (Fedora, Mandriva), while closed blob driver gives you all other features.
Nouveau is just useless eye candy at the moment :/ .
So everyone who's got nVidia's hardware has got to choose: nice splash or OpenGL features, among with desktop effects, media center and others.
Funny.
On Wed, Jan 13, 2010 at 09:28:57PM +0100, Jakub 'Livio' Rusinek wrote:
Hi,
What's funny when it comes to KMS on nVidia, is the fact, that nouveau gives you only KMS and nice splash appearance (Fedora, Mandriva), while closed blob driver gives you all other features.
Nouveau is just useless eye candy at the moment :/ .
So everyone who's got nVidia's hardware has got to choose: nice splash or OpenGL features, among with desktop effects, media center and others.
The third alternative would be the nv driver neither gives you a bootsplash nor OpenGL at all.
Funny.
Not really. The NVIDIA folks have their own driver design. In fact the driver replaces a lot of infrastructure that other drivers take from the X Window System and other components. Migrating this design to another surrounding API (as KMS provides) is a huge amount of effort. With KMS still somewhat in the flux I can imagine that NVIDIA is hesitent to jump ship right now. Until this is done you will be missing those features that nouveau offers. nouveau on the other hand has been done mostly by reverse engineering. If you look how much man power went into the proprietary NVIDIA driver suite (and this with both access to documentation and the hardware engineers) it's pretty clear why nouveau is not equal to the proprietary driver.
Cheers, Egbert.
Hi Egbert,
On Wed, 13 Jan 2010 12:25:21 +0100 Egbert Eich eich@suse.de wrote:
On Thu, Dec 10, 2009 at 01:41:57PM +0100, Stefan Seyfried wrote:
panel (Matthias knows what I'm talking about). Switching VT to X and back still solves this (phew! we anticipated that with kms, once the pll is screwed there would be no way to recover short of a reboot).
This is strange and shouldn't happen at least when using the radeon driver. Since we don't support KMS for anything but Intel at this moment I have not looked into this more deeply. If X and the console have the same resolution there shouldn't be any flicker.
Yes, that's why I guessed that something was not working correctly ;)
So I guess that KMS is not working well in this setup, since some PLL is still reprogrammed (and sometimes this fails).
All on an oldish ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
Now I wanted to put the module in the initrd, however, loading it from "init=/bin/bash" (I tried that first, just to make sure) gives me a kernel backtrace and basically kills the box.
Also strange. Is this because you still need to load an AGP module?
I'm not sure, I have intel_agp loaded in the running system and it is used, so this might be the issue. (Even though I think something as trivial as intel_agp would not have escaped me... but you never know). Iwill try this again from init=bash once we get a new kernel for FACTORY (the 2.6.32 that's in there is soooo old, that there are hopefully tons of radeon fixes in 2.6.33 that surely will come soon ;)
I still hope that the abysmal 2D performance of radeon with RV350 will get a bit better with newer kernel drivers etc...
Thanks,
seife
Hi Seife!
On Thu, Jan 14, 2010 at 02:36:14PM +0100, Stefan Seyfried wrote:
Hi Egbert,
On Wed, 13 Jan 2010 12:25:21 +0100 Egbert Eich eich@suse.de wrote:
I'm not sure, I have intel_agp loaded in the running system and it is used, so this might be the issue. (Even though I think something as trivial as intel_agp would not have escaped me... but you never know). Iwill try this again from init=bash once we get a new kernel for FACTORY (the 2.6.32 that's in there is soooo old, that there are hopefully tons of radeon fixes in 2.6.33 that surely will come soon ;)
Are you sure that intel_agp has been loaded before the radeon drm driver?
I still hope that the abysmal 2D performance of radeon with RV350 will get a bit better with newer kernel drivers etc...
2D acceleration is still handled in user space. Only the functions which send the commands down to the engine are in the kernel.
Cheers, Egbert.
Hi Egbert,
On Fri, 15 Jan 2010 09:26:14 +0100 Egbert Eich eich@suse.de wrote:
Are you sure that intel_agp has been loaded before the radeon drm driver?
As much as I would like to claim "of course, because I would never make such a stupid mistake!!1!", I can't, simply because I'm not totally sure.
Will test on next reboot, whenever this machine crashes (wich is a very rare occurence lately) or a new kernel turns up for FACTORY (even more rare, it seems ;)
I still hope that the abysmal 2D performance of radeon with RV350 will get a bit better with newer kernel drivers etc...
2D acceleration is still handled in user space. Only the functions which send the commands down to the engine are in the kernel.
I feared that you would say that... so it's probably time to ditch this machine and buy one with a recent intel chipset (I have another one with intel, but that's i855, and it only has 1024x768 on a 15" display) :-(
Have fun,
seife
On Fri, 15 Jan 2010 13:00:59 +0100 Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Hi Egbert,
On Fri, 15 Jan 2010 09:26:14 +0100 Egbert Eich eich@suse.de wrote:
Are you sure that intel_agp has been loaded before the radeon drm driver?
As much as I would like to claim "of course, because I would never make such a stupid mistake!!1!", I can't, simply because I'm not totally sure.
Will test on next reboot, whenever this machine crashes (wich is a very rare occurence lately) or a new kernel turns up for FACTORY (even more rare, it seems ;)
I finally rebooted, even though there was no new kernel in FACTORY (because I had updated everything else and KDE4 had made my .xsession-errors fill up my whole home partition... ;()
With intel_agp loaded, while in init=/bin/sh, "modprobe radeon modeset=1" still fails, probably because the firmware loading through udev is not yet set up. I did not investigate further, nor did I dare putting radeon with modeset into my initrd ;)
When booting to runlevel 3, I can "modprobe radeon modeset=1" and it gives me a nice 1400x1050 framebuffer, but it still flickers when switching to X.
The xorg.log is pretty small, so I'll simply attach it, maybe you can see something from it. If you'd rather have a "proper" bugreport for this old and obsolete hardware, you just need to tell me.
Have fun ;)
seife
On Thursday 03 December 2009 14:38:29 Egbert Eich wrote:
Folks -
In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution. Furthermore test packages are available to try things out on Factory.
Egbert, what is the status of all your patches? Is everything now in Factory? What can we tell our users?
Andreas
-
Andreas Jaeger -
Carlos E. R. -
Egbert Eich -
Felix Miata -
Greg KH -
Jakub 'Livio' Rusinek -
Jeff Mahoney -
Karsten König -
Ken Schneider - Factory -
Martin Schlander -
Petr Baudis -
Rafał Miłecki -
Rob OpenSuSE -
Robert Kaiser -
Sid Boyce -
Stefan Dirsch -
Stefan Seyfried -
Takashi Iwai