Description of problem: Without any xorg.conf the ati driver is selected automatically, but unfortunately it doesn't work and doesn't fall back to fbdev - which works. The display just goes black (similar to bug 726143 with KMS). Expected results: Ideally a working ATI mode, but falling back to fbdev would be ok too. Additional info: Booting with EFI and grub2 efi_gop, using nomodeset because of bug 726143 . Version-Release number of selected component (if applicable): kernel-3.0.0-1.fc16.x86_64 xorg-x11-drv-ati-6.14.1-1.20110504gita6d2dba6.fc16.x86_64
Created attachment 515565 [details] Xorg.0.log with nomodeset - ati, display remains black Forgot to mention: http://www.smolts.org/client/show/pub_65553f8d-4168-44cc-a5de-8b98df90fc2c
Created attachment 515566 [details] dmesg - with nomodeset
We don't fix non kms path
I understand and agree with the decision to focus 100% on KMS and not try to also fully support non-KMS. I also understand that modern video coding is very complex and often not well documented. Things occasionally break because of bugs or change in the hardware or firmware. For that reason some kind of "safe mode" is a "must". An indication of that need is that the Fedora installers do have a boot option for starting with nomodeset. That was what got me so far that I could get the system up and running so I could report the issues. I don't expect any kind of acceleration, and I guess a fallback to vesa or fbdev would work for most video cards, both those that currently have flaky support and future (and thus yet unsupported) cards. So all I ask is that you take the consequence of the 'no support for non kms' policy to the extreme in the (ati) driver and let it fall back to vesa and fbdev in non kms mode.
We are yet unsure on this, some people still have use for non kms and it works for them. What we are sure of is that we won't fix non kms bug unless someone give us an insane amount of money.
The inconvenient naming of "nomodeset" and the frozen feature set for a moving target indicates that it really is a "temporary" workaround. Some kind of more long term "dumbvideo" (marketing people would call it "safevideo") kernel parameter that both disables KMS and cleverness in X drivers could be handy. I guess that is what I was asking / hoping for here. I will file that under "wibni".
(In reply to comment #7) > Some kind of more long term "dumbvideo" (marketing people would call it > "safevideo") kernel parameter that both disables KMS and cleverness in X > drivers could be handy. I guess that is what I was asking / hoping for here. I > will file that under "wibni". Basically, what you are asking for is called VESA driver (and yes, I believe, it is called “Basic safe mode” in the anaconda ;)). However, in the last year or so we are observing that hardware manufactures are less and less careful with keeping their hardware VESA compliant.
Yes, a way to ensure VESA from the boot loader would be fine. The problem here is that that ati driver is too optimistic and prevent the VESA X driver from being used. Apparently there is no boot loader / kernel parameter option for this - which is why live CDs has to work around it by introducing an xdriver parameter that writes a xorg.conf. (AFAIK EFI machines doesn't have VESA but has UFA or GOP instead - which are handled by fbdev. The issue is the same, but it indicates that it could be nice to have an option that tried to be safe without requiring the user to know if it is VESA or not.)