| Summary: | drmCheckModesettingSupported fails if X loaded radeon modeset=1 just before | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Brice Goglin <brice.goglin> | ||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | daniel | ||||
| Version: | git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Brice Goglin
2009-12-12 03:07:29 UTC
Created attachment 32981 [details] [review] Load kernel module before checking for KMS In fact kernel module is loaded after KMS support is checked. Attached patch is idea how to make ddx load kernel module before checking for KMS support. Code is a bit modified copy/paste from DRI initialization code that would normally handle kernel module loading. I didn't test if it really works because on my system radeon module is auto-loaded early in boot. I've experienced the same problem. Preloading the radeon module fixes it, here too. Also, intel (i915 drm module) has the same problem. My hw: rv570 (radeon) and i855gm (intel). According to Dave Airlie this isn't (easily) fixable completely. Current xf86-video-ati Git bails in this case, and then the next X server startup should work properly. This is becoming a problem for many people and distros now that KMS is mandatory. On Linux, if CONFIG_DRM_RADEON_KMS is not enabled, X loads (through the DRI interface I suppose) radeon.ko correctly but X initialization fails as pointed out 3 years ago by Brice Goglin. Otoh, forcing CONFIG_DRM_RADEON_KMS=y in distributed kernels makes fglrx users' life really hard. So, what are distributors supposed to do in your opinion? Do we really have to consider fglrx and radeon to be mutually exclusive at package manager level? That would be suboptimal as well. As of 6.14.3 the ddx will stop loading if the ddx is in UMS mode and the drm is in KMS mode to prevent display problems. UMS is no longer supported in the DDX on Linux. Support for UMS was removed in xf86-video-ati git last month. UMS only supported chips up through evergreen and the open source 3D drivers dropped UMS support a while ago. The open source radeon driver and fglrx are completely different driver stacks and require some system adjustments to switch between then (different kernel modules, different ddx, different 3D drivers, different libgl and libglx, etc.). It's probably easiest to have a script to switch the environments between the two drivers or something like that. Userspace is not a problem here, many distributions have GL implementation switch tools already. I have users reporting that 6.14.4 suffers from the problem reported here. Basically, radeon.ko is loaded by X with KMS enabled, (CONFIG_DRM_RADEON_KMS=n but modprobe.d/ contains "options radeon modeset=1") but X fails to start with: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] This chipset requires a kernel module version of 1.17.0, [dri] but the kernel reports a version of 2.16.0.[dri] Make sure your module is loaded prior to starting X, and [dri] that this driver was built with support for KMS. [dri] Aborting. The problem is that xf86-video-ati is built with KMS and radeon.ko loads with modeset=1 but still, X fails to load due to the initialization (bug?) issue reported by the OP. Restarting X fixes the problem. I do think there is something to fix here and it would be nice to at least fix this chicken/egg issue. (In reply to comment #6) > Userspace is not a problem here, many distributions have GL implementation > switch tools already. > Userspace is the problem. > > The problem is that xf86-video-ati is built with KMS and radeon.ko loads with > modeset=1 but still, X fails to load due to the initialization (bug?) issue > reported by the OP. Restarting X fixes the problem. I do think there is > something to fix here and it would be nice to at least fix this chicken/egg > issue. You need to have the kernel module loaded before starting X. The same is true of other KMS drivers (intel, nouveau, etc.). If the drm is not loaded, the ddx assumes UMS and tries to load the drm. If it loads in KMS mode, you don't want two drivers handling the same hw, so the ddx bails to prevent that. If you try and load the drm from X and assume that the kernel is in KMS mode, you break old systems with old kernels that don't support KMS. The other problem with having the ddx load the drm for KMS mode is that with KMS, the drm handles all of the chip init. With UMS when you load the drm in UMS mode, the kernel module doesn't do anything at load time; it just waits until userspace inits the hw and actually decides to use the drm. With KMS, we have no way of knowing when the KMS drm has finished loading or initializing the hw so we may end up trying to use the KMS drm before it's properly loaded. It's not a configuration we want to support. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/7. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.