Bug 530425

Summary: Garbled screen on Dell D620 with nvidia display.
Product: [Fedora] Fedora Reporter: Matthew Truch <matt>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: airlied, ajax, awilliam, bskeggs, mcepl, mcepl
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: card_NV46
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-21 19:47:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg log - normal boot - two screens attached
none
Xorg log - normal boot - one screens attached
none
Xorg log - nomodeset boot - two screens attached
none
Xorg log - nomodeset boot - one screen attached
none
rawhide 2009-10-27 snapshot - nomodeset - 2 screens
none
rawhide 2009-10-27 snapshot - modeset (default) - 2 screens
none
/var/log/messages
none
Digital Photo of computer (2 screens) during bootup
none
Digital Photo of computer (2 screens) while running.
none
Smolt Profile none

Description Matthew Truch 2009-10-22 18:28:48 UTC
While running Fedora 13 beta 2 KDE Live CD on a Dell Latitude D620.

With normal boot options, the laptop display is garbled and useless.  A secondary display plugged into the computer (VGA connector) is detected and attached as a secondary display and looks fine.   

With nomodeset kernel option, the laptop display is still garbled (in a similar, but slightly different way).  The secondary display is detected, but not at the correct size (it only shows the right most part of the screen, but on the left side of the display).  

lspci calls my display adapter a G72M [Quadro NVS 110M/GeForce Go 7300].

Comment 1 Matthew Truch 2009-10-26 23:08:01 UTC
Created attachment 366170 [details]
Xorg log - normal boot - two screens attached

/var/log/Xorg.0.log with normal (modeset) boot and two screens.

Comment 2 Matthew Truch 2009-10-26 23:08:52 UTC
Created attachment 366171 [details]
Xorg log - normal boot - one screens attached

/var/log/Xorg.0.log with normal boot (modeset) and just the laptop display attached.

Comment 3 Matthew Truch 2009-10-26 23:09:54 UTC
Created attachment 366172 [details]
Xorg log - nomodeset boot - two screens attached

/var/log/Xorg.0.log with nomodeset option boot, two screens attached.

Comment 4 Matthew Truch 2009-10-26 23:10:48 UTC
Created attachment 366173 [details]
Xorg log - nomodeset boot - one screen attached

/var/log/Xorg.0.log with nomodeset boot, just the laptop internal display attached.

Comment 5 Matthew Truch 2009-10-26 23:12:18 UTC
And in case it wasn't clear, this bug makes the laptop display useless in all of the above cases (modeset or nomodeset; external display attached or no external display attached).  In the best case (modeset, external display attached) the external display looks proper and the computer is useable as long as one opens (or moves) windows to the external display.

Comment 6 Matthew Truch 2009-10-28 16:53:12 UTC
Created attachment 366467 [details]
rawhide 2009-10-27 snapshot - nomodeset - 2 screens

Comment 7 Matthew Truch 2009-10-28 16:55:47 UTC
Created attachment 366468 [details]
rawhide 2009-10-27 snapshot - modeset (default) - 2 screens

Now tested with rawhide 2009-10-27 snapshot.  The situation hasn't changed with the nomodeset option (laptop screen is garbled, 2nd display only shows part of the image but that part is useable).  The situation has changed significantly with the default (modeset), where all screens are garbled and X continuously restarts during the login phase.  It took me about a long time to switch to a different virtual terminal (between X restarts) to log in and switch to runlevel 3 so I could copy the Xorg.log to a different machine.

Comment 8 Adam Williamson 2009-10-29 21:10:47 UTC
modesetting isn't really making a difference here, the difference you're seeing is normal since without modesetting, dynamic framebuffer allocation doesn't work so the screens will get set to clone, not span mode.

can you take a digital picture of the garbled laptop screen so we can see exactly what it looks like?

is 1440x900 the correct resolution for your laptop screen?

Can we get a look at /var/log/messages as well?

Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 9 Matthew Truch 2009-10-29 21:33:21 UTC
Created attachment 366715 [details]
/var/log/messages

Comment 10 Matthew Truch 2009-10-29 21:34:23 UTC
Created attachment 366716 [details]
Digital Photo of computer (2 screens) during bootup

Comment 11 Matthew Truch 2009-10-29 21:36:46 UTC
Created attachment 366717 [details]
Digital Photo of computer (2 screens) while running.

Note that the default setting has the external monitor to the right of the internal (laptop) monitor but this is not how I physically have my setup on my desk.  I placed the Konsole window so it overlapped the transition between the monitors.  

Yes, the laptop screen is 1440x900.  

The image is with the beta KDE live CD.

Comment 12 Adam Williamson 2009-10-30 00:12:42 UTC
Huh, interesting one. Thanks for all the info. Over to Ben.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 13 Matěj Cepl 2009-11-05 17:18:53 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 14 Matthew Truch 2009-11-05 19:21:46 UTC
This test was with the F12Beta; I'll be testing last night's rawhide compose shortly (or is there a way to actually try the F12RC that was scheduled to be done yesterday?).

Comment 15 Matthew Truch 2009-11-05 21:24:00 UTC
(In reply to comment #14)
> This test was with the F12Beta; I'll be testing last night's rawhide compose
> shortly (or is there a way to actually try the F12RC that was scheduled to be
> done yesterday?).  

I see no noticeable change with the rawhide live cd from 2009-11-04.  The screen is still garbled.

Comment 16 Matthew Truch 2009-11-13 03:07:48 UTC
For what it's worth, the problem still exists in F12RC4 as of today.

Comment 17 Bug Zapper 2009-11-16 14:04:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 Matthew Truch 2009-11-30 16:23:34 UTC
Created attachment 374805 [details]
Smolt Profile

I've attached the smolt profile from the computer in question if it helps (as requested on the debugging Xorg Fedora wiki page).

Comment 19 Fedora Update System 2010-03-29 06:10:44 UTC
kernel-2.6.32.10-92.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.32.10-92.fc12

Comment 20 Matthew Truch 2010-03-29 23:43:24 UTC
Awesome.  Is this fix also going to be ported to the rawhide (or is it F13 beta) tree (or some other place where a live-CD gets generated on a semi-regular basis?  I'd like to test before I upgrade my laptop (which is currently running super-old F-10).

Comment 21 Ben Skeggs 2010-03-29 23:53:15 UTC
It's a bit confusing now with two development trees (sigh), the fix is in the latest F12/F13 kernels in koji.  For rawhide (F14) my stance is that I'll send fixes through airlied to the upstream kernel, and let the updates get into rawhide that way.

The fix has been tested by someone from Ubuntu already, so should work for you if you were to update.

Comment 22 Fedora Update System 2010-03-30 02:21:46 UTC
kernel-2.6.32.10-92.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.32.10-92.fc12

Comment 23 Matthew Truch 2010-10-21 19:47:15 UTC
Works.  Should have closed this bug a long time ago.