Bug 496761 - Dualhead only works properly if external monitor is plugged in at boot.
Dualhead only works properly if external monitor is plugged in at boot.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
12
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
card_NV4E
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-20 21:01 EDT by Gideon Mayhak
Modified: 2010-12-05 01:56 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:56:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of xrandr with monitor attached at boot. (1.52 KB, text/plain)
2009-04-24 20:55 EDT, Gideon Mayhak
no flags Details
Xorg.0.log with monitor attached at boot (137.62 KB, text/plain)
2009-04-24 20:55 EDT, Gideon Mayhak
no flags Details
Output of xrandr with monitor absent at boot (271 bytes, text/plain)
2009-04-24 20:56 EDT, Gideon Mayhak
no flags Details
Xorg.0.log with monitor absent at boot (46.86 KB, text/plain)
2009-04-24 20:57 EDT, Gideon Mayhak
no flags Details
Output of xrandr with monitor attached and configured after boot without (1.52 KB, text/plain)
2009-04-24 20:58 EDT, Gideon Mayhak
no flags Details
Xorg.0.log with monitor attached and configured after boot without (374.77 KB, text/plain)
2009-04-24 20:58 EDT, Gideon Mayhak
no flags Details
Output of dmesg after appending drm.debug=1 to kernel line. (123.24 KB, text/plain)
2009-08-26 20:27 EDT, Gideon Mayhak
no flags Details

  None (edit)
Description Gideon Mayhak 2009-04-20 21:01:01 EDT
Description of problem:
When configuring dualhead with gnome-display-properties, the external monitor is only correctly initialized if it is plugged in at boot.  If I attach an external monitor after logging in, it seems to receive a signal (it comes out of power saving mode), but the screen is black.  If it's plugged in before I turn my laptop on, it gets an image and I can configure it as desired.

Version-Release number of selected component (if applicable):
xorg-x11-drv-nouveau-0.0.12-29.20090417gitfa2f111.fc11.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Boot without external monitor plugged in
2. Login
3. Attach external monitor
4. User gnome-display-properties to mirror display or extend desktop, turning on the external monitor in some fashion
  
Actual results:
External display turns on, but is all black.

Expected results:
External display turns on and displays an image.

Additional info:
http://www.smolts.org/show?uuid=pub_756eb268-2829-425c-a491-206445797a73
Comment 1 Gideon Mayhak 2009-04-22 21:12:16 EDT
Let me know of anything I can provide you with for this.  Output of commands, logs, etc.  I really wasn't sure what you might need for this type of thing.  Thanks for making dualhead work in the first place.  I look forward to helping make it better!
Comment 2 Adam Williamson 2009-04-23 22:46:23 EDT
The output of 'xrandr' run at a console in both cases, and the /var/log/Xorg.0.log files from both cases, would be a good start :) Thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Gideon Mayhak 2009-04-24 20:55:13 EDT
Created attachment 341261 [details]
Output of xrandr with monitor attached at boot.
Comment 4 Gideon Mayhak 2009-04-24 20:55:50 EDT
Created attachment 341262 [details]
Xorg.0.log with monitor attached at boot
Comment 5 Gideon Mayhak 2009-04-24 20:56:28 EDT
Created attachment 341263 [details]
Output of xrandr with monitor absent at boot
Comment 6 Gideon Mayhak 2009-04-24 20:57:03 EDT
Created attachment 341264 [details]
Xorg.0.log with monitor absent at boot
Comment 7 Gideon Mayhak 2009-04-24 20:58:01 EDT
Created attachment 341265 [details]
Output of xrandr with monitor attached and configured after boot without
Comment 8 Gideon Mayhak 2009-04-24 20:58:54 EDT
Created attachment 341266 [details]
Xorg.0.log with monitor attached and configured after boot without
Comment 9 Gideon Mayhak 2009-04-24 21:00:21 EDT
Also of note, choosing to mirror in gnome-display-properties after attaching the external monitor doesn't want to work.  I have to select something else, such as turning on the external monitor and setting it to 1280x960.  After that, the screen turns on and I can do other things like mirroring.
Comment 10 Gideon Mayhak 2009-05-16 16:21:00 EDT
Just a little nudge as I go through my open bug reports.  Have I provided enough information to get started investigating, or is there anything else I can get you?  I know you (Ben Skeggs) are most likely very busy getting more critical bugs in shape for the F11 release, but I thought I'd check in :-).
Comment 11 Ben Skeggs 2009-05-17 19:38:52 EDT
You've provided enough information, thank you!  DDC doesn't appear to be working unless you boot with the display connected.  Not sure what's happening there.

I'm curious to know what happens if you select 1024x768 (xrandr --output VGA-0 --mode 1024x768) after plugging in the VGA monitor?
Comment 12 Gideon Mayhak 2009-05-17 23:03:26 EDT
Same behavior, unfortunately (unless that makes it easier for you to figure out :-)).  Laptop screen stays on and primary, external monitor turns on but is black.  gnome-display-properties shows the external monitor as being the same as the upper-left 1024x768 corner of the laptop's 1280x800 display.  I also tried setting it to 1280x960 and --right-of LVDS-0, but it remained black (but receiving a signal).
Comment 13 Bug Zapper 2009-06-09 10:15:49 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Gideon Mayhak 2009-07-08 19:47:23 EDT
Any thoughts?  Anything else you'd like me to try to help narrow it down?
Comment 15 Gideon Mayhak 2009-08-26 01:28:26 EDT
I'm now running F12 Alpha updated to rawhide and the situation is much worse, and yet better in some ways.  I hesitate to change this bug over to rawhide, but I guess it's pointless to leave it linger under F11.  Please let me know your thoughts on that after the following information:

KMS is now working: AWESOME!  Thank you so much for that.  Worked like a charm until today's updates, because now...

TV Out appears to be working: I haven't actually tested by connecting to a TV yet, but KMS now aligns Plymouth in the upper-left corner at 720x576, and GDM loads to be 1280x800 on my laptop's display and a phantom 720x576 on the right (which carries into GNOME)

Now to the fun part, which is directly related to this bug report:

The original problem is still present, but now I can't boot with the external display attached either.  If I do, my laptop display is off and the external monitor says it's out of range.  So, I now have no dualhead, rather than sometimes dualhead.

Anyway, after all that, I would like to know whether to update this bug report for rawhide or file a new one (as the situation is a bit different now).  Also, should those two regarding KMS and TV Out be reported as two new bugs, or can we change this one into a blanket bug for nouveau issues with my chipset?

Thanks for all your hard work.  A tear nearly came to my eye when I first saw that beautiful KMS on my old NVIDIA card!  And if TV Out ends up working in the end, that will just be awesome (I haven't used it in ages because it barely worked with the proprietary driver, but nouveau has proven much more useful for dualhead).
Comment 16 Ben Skeggs 2009-08-26 01:41:46 EDT
Hmm, for the phantom TV being detected could you please attach the output of the "dmesg" command after booting please?  Perhaps better still would be to boot with "drm.debug=1 3" in your kernel boot options, then "dmesg > dmesg.log" and then just reboot to go back to normal.

I'll see if one of my cards with TV-out is configured in the same way as yours tomorrow and see if I can reproduce the issue too.

I'd say not detecting VGA at all is probably related to a TV being detected instead, but I'll look more closely at that too.

I think the proper way of handling this would be to clone the bug, and set the new bug as "rawhide".  But, I'm not sure.  Adam, any input on that?

Thanks!
Comment 17 Adam Williamson 2009-08-26 11:27:05 EDT
kinda depends on Ben :) ben, if you have any chance of fixing the original bug for F11, that would be the best way to do it, yes. if not, then 'repurposing' this bug would be OK.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Gideon Mayhak 2009-08-26 20:27:50 EDT
Created attachment 358792 [details]
Output of dmesg after appending drm.debug=1 to kernel line.

It said it ignored drm.debug=1, so this may not be as useful as you'd like.

As far as F11 vs. rawhide: I would prefer we switch this to rawhide and keep chugging along.  Now that I have a rawhide install, I'm not looking back to F11 for added functionality.  Full speed ahead!  But seriously, I'm guessing what it would take to fix the original bug would not be pretty to get backported to F11.  So as far as I'm concerned, let's look to rawhide.

However, I'll leave it to one of you to change the bug or tell me to clone it ;-).
Comment 19 Ben Skeggs 2009-08-26 20:44:08 EDT
Ok, switched version to rawhide :)  Will keep looking at this.
Comment 20 Gideon Mayhak 2009-08-26 21:28:31 EDT
Your work on nouveau has been awesome, Ben.  Seriously awesome :-D.
Comment 21 Gideon Mayhak 2009-08-26 22:21:16 EDT
And on a positive note: I just tried TV Out, and it appears to be working!  I say appears, because I can only select a 50Hz refresh rate (whether in gnome-display-properties or using the xrandr command), but I need 60Hz (for NTSC).  Otherwise, I did get a crazy image on my TV that did look like the desktop background, so I imagine it'd work when connected to a PAL display.
Comment 22 Ben Skeggs 2009-08-26 22:53:49 EDT
For that, load the module with "modprobe nouveau tv_norm=NTSC-M" etc, you can see the full list of options with "modinfo nouveau".  To default to it on boot, add "nouveau.tv_norm=NTSC-M" to your boot options!
Comment 23 Gideon Mayhak 2009-08-28 21:34:42 EDT
If I have that added at boot, it says it is ignoring it.  However, gnome-display-properties does then show a 60Hz option.  But when I try to turn on the external display, nothing gets to my TV, and then going back to just the laptop screen locks up the computer and gives me a black screen.

So, still really cool that it's even working with a PAL signal, but kind of a bummer that it won't output NTSC.
Comment 24 Gideon Mayhak 2009-10-22 21:16:44 EDT
Just a quick update after doing a fresh install of F12 Beta:

TV-Out no longer interferes with my GDM width or anything, but adding nouveau.tv=1 and nouveau.tv_norm=NTSC-M to the kernel line does not allow me to use TV-Out either (no modes available to xrandr).  Since it wasn't working before, we'll just count that as better than it was.

Back to the original issue: the monitor still needs to be plugged in at boot.  One thing I noticed, and I'm not sure if this helps you get any ideas: the monitor needs to be plugged in *before* the BIOS screen is displayed.  Plugging it in at GRUB or Plymouth does not properly initialize the monitor.  So it seems like the VGA port needs to be initialized by the BIOS in order to work properly.  The proprietary NVIDIA driver did not have this issue, as I could easily update my configuration and restart X and the monitor would come on as expected.  So, food for thought.
Comment 25 Gideon Mayhak 2009-10-22 21:23:21 EDT
One other quick thing that may or may not be your jurisdiction:

With the change to GDM spanning displays instead of cloning, the login window now falls on my external display instead of the internal laptop display.  I thought that the goal was to make sure the internal laptop display (when using a laptop) remained the primary display with this change.  Anyway, not sure if that needs to be filed against GDM or if it's an identification issue on nouveau's side, but just thought I'd throw it out there.
Comment 26 Adam Williamson 2009-10-26 16:35:42 EDT
I think that may be the server's jurisdiction. The standard answer is that it's impossible to know which display is the 'primary' as far as the user's concerned, but I think for the laptop case it should be an exception. I think it'd be correct to usually consider the LVDS (laptop internal) display as the primary one, as you suggest. I'll poke the X.org devs about that.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Adam Williamson 2009-10-26 16:38:10 EDT
actually, on second thoughts, I can imagine a user who thinks 'well, of course the reason I plugged an external monitor into my laptop is so I can use it instead of the crappy/broken internal monitor. duh.'

trying to guess defaults is fun!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 28 Adam Williamson 2009-10-26 16:42:07 EDT
<ajax> the driver should normally try to bubble lvds to the front of the output list
<ajax> whether it considers it _connected_ should be a function of acpi lid status
<ajax> whether gdm displays on it is, iirc, a function of which head the initial root cursor is on; which i think is a simple x/2 y/2 centering, so.
<ajax> i don't think there's any way to set a primary for gdm atm.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 29 Gideon Mayhak 2009-10-28 22:25:38 EDT
That makes sense.  X defaults to 1280x800 on the laptop display and 1280x1024 on the external display, with the external display to the right.  The cursor just barely ends up on the external display, which would explain the login screen being over there.  I guess it would be on the laptop display if I was plugged into, say, a 1024x768 projector.  Not a big deal for me, but I wanted to put it out there :-).
Comment 30 Matěj Cepl 2009-11-05 12:12:54 EST
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 31 Gideon Mayhak 2009-11-05 22:05:38 EST
The main issue is still occurring (I just verified with today's updates).

I just want to say thanks to all of you who work so hard on maintaining and improving a Free Software product.  Fedora has literally changed my life over these past couple years!
Comment 32 Matěj Cepl 2009-11-07 19:45:39 EST
(In reply to comment #31)
> I just want to say thanks to all of you who work so hard on maintaining and
> improving a Free Software product.  Fedora has literally changed my life over
> these past couple years!  

Thanks a lot.
Comment 33 Bug Zapper 2009-11-16 04:56:32 EST
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 34 Steven Bularca 2010-02-24 18:50:25 EST
Hi,

I have spoken with curro about this.  As you all know it has to do with the nouveau.tv option, and he has submitted another patch to make it work through suspend/resume cycles.  I think the fixes should be in rawhide now.  PM me for e-mail logs and such.
Comment 35 Bug Zapper 2010-11-04 07:19:53 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 36 Bug Zapper 2010-12-05 01:56:11 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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