On Don, 2010-04-29 at 22:06 +0200, Albrecht Dreß wrote: > Am 29.04.10 09:39 schrieb(en) Michel Dänzer: > > Beware that CONFIG_DRM_RADEON_KMS=y requires also building the firmware > > needed by the radeon driver into the kernel, otherwise the radeon driver > > will time out trying to load the firmware before the root filesystem is > > mounted and then only work with acceleration disabled. > > > > What about CONFIG_AGP*? > > > > > > > CONFIG_FB_RADEON=y > > > > radeon KMS can't work with radeonfb. Does passing radeon.modeset=0 on > > the kernel command line help for now? > > > > In any case, please provide the output of > > > > dmesg|grep -e drm -e agp -e radeon > > O.k., here are some more encouraging test results. I now rebuilt the kernel > with > > r...@antares:~# zgrep -e DRM -e RADEON -e AGP /proc/config.gz > CONFIG_AGP=m > CONFIG_AGP_UNINORTH=m > CONFIG_DRM=m > CONFIG_DRM_KMS_HELPER=m > CONFIG_DRM_TTM=m > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > CONFIG_DRM_RADEON=m > CONFIG_DRM_RADEON_KMS=y > # CONFIG_DRM_MGA is not set > # CONFIG_DRM_SIS is not set > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > # CONFIG_FB_RADEON is not set > > The boot process now behaves a little strange, as the start screen > first looks like hanging in OpenFirmware, but then briefly the text > console comes up, and X starts.
As you booted with modeset=0, there's no driver usable for the console. Either try without modeset=0 (you may need radeon.agpmode=1 instead for AGP to work reliably with KMS) or re-enable radeonfb. > The strange effect in Xine is *completely* gone. So as I suspected probably bitrot in the non-DRI big endian paths. Does EXA also work without workarounds now? -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
