A recent 3.19.0 kernel with radeonfb and KMS results in hang and corrupt video display after Xorg loads. It seems that radeonfb and KMS together will not work (?), but I could not find any information about this apart from this discussion: "I believe we will enforce to either have radeon KMS or radeonfb the latter being depreciated. Note we need to wait few years (5 maybe more) before we can do rm radeonfb at least this is my understanding of kernel rules." http://www.phoronix.com/forums/showthread.php?14828-KMS-and-radeonfb So KMS and radeonfb should be mutually exclusive build options, or perhaps radeonfb should be finally removed as suggested (the suggestion to remove it in a few years was made in 2009)?
Just found bug #10259 which confirms that radeonfb and DRI are incompatible on r300: "This will probably never be fixed without KMS, which should provide more or less the same features as radeonfb anyway." Solution would be either a runtime error "this is unsupported and does not work" or compile time mutually exclusion or drop radeonfb.
I think you're jumping to conclusions here. The conflict between radeonfb and radeon KMS is such that one being active prevents the other one from initializing at all. "Hang and corrupt video display" sounds like a different problem. Please provide /var/log/Xorg.0.log and the output of dmesg corresponding to the problem.
I retested and it isn't an actual hang. It is this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762047 (not sure why I saw some kind of pink corrupt image before, but now it is just black). When both radeonfb and KMS are in the kernel, lightdm will boot to a black screen. As you said in the Debian bug, this can be worked around by forcing X to another colour depth (/etc/lightdm/lightdm.conf [SeatDefaults] xserver-command=X -depth 24) - If KMS is now preferred, would it be more useful to default to using it rather than have to manually specify 'video=radeonfb:off' ? - With radeonfb and KMS, dmesg shows: [ 4.292750] [drm] Initialized drm 1.1.0 20060810 [ 4.292866] [drm] radeon kernel modesetting enabled. This is confusing given that KMS isn't enabled. It would be more informative to print a warning like "KMS disabled because you have radeonfb enabled". - Is there any point in having CONFIG_FB_RADEON on a modern kernel? If not, it would be informative if the kernel config for CONFIG_FB_RADEON stated that it was deprecated, and enabling it will cause KMS to be disabled. It isn't obvious that it isn't desirable to enable that config option, or that enabling it will cause KMS to be disabled by default.
(In reply to Chris Bainbridge from comment #3) > I retested and it isn't an actual hang. It is this issue: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762047 So it's a lightdm bug, resolving accordingly. > - With radeonfb and KMS, dmesg shows: > > [ 4.292750] [drm] Initialized drm 1.1.0 20060810 > [ 4.292866] [drm] radeon kernel modesetting enabled. > > This is confusing given that KMS isn't enabled. It would be more informative > to print a warning like "KMS disabled because you have radeonfb enabled". This message is printed by the radeon driver, which I'm not sure has that information. > - Is there any point in having CONFIG_FB_RADEON on a modern kernel? Yes, e.g. radeon KMS doesn't support suspend/resume yet on Apple PowerPC laptops.
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.