Bug 726159 - [RV730] ATI driver fails, fbdev works, "9488" (HD 4670?) on iMac11,2 1.0 in EFI mode, nomodeset
[RV730] ATI driver fails, fbdev works, "9488" (HD 4670?) on iMac11,2 1.0 in E...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-27 13:35 EDT by Mads Kiilerich
Modified: 2011-07-29 09:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-27 16:58:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log with nomodeset - ati, display remains black (72.84 KB, text/plain)
2011-07-27 13:38 EDT, Mads Kiilerich
no flags Details
dmesg - with nomodeset (104.10 KB, text/plain)
2011-07-27 13:39 EDT, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2011-07-27 13:35:15 EDT
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
Comment 1 Mads Kiilerich 2011-07-27 13:38:42 EDT
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
Comment 2 Mads Kiilerich 2011-07-27 13:39:35 EDT
Created attachment 515566 [details]
dmesg - with nomodeset
Comment 3 Jérôme Glisse 2011-07-27 16:58:46 EDT
We don't fix non kms path
Comment 5 Mads Kiilerich 2011-07-28 15:55:29 EDT
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.
Comment 6 Jérôme Glisse 2011-07-28 16:32:07 EDT
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.
Comment 7 Mads Kiilerich 2011-07-28 18:00:36 EDT
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".
Comment 8 Matěj Cepl 2011-07-29 09:11:15 EDT
(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.
Comment 9 Mads Kiilerich 2011-07-29 09:29:38 EDT
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.)

Note You need to log in before you can comment on or make changes to this bug.