Bug 496761
| Summary: | Dualhead only works properly if external monitor is plugged in at boot. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gideon Mayhak <gnafu_the_great> |
| Component: | xorg-x11-drv-nouveau | Assignee: | Ben Skeggs <bskeggs> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 12 | CC: | airlied, amlau, awilliam, bskeggs, mcepl, mcepl, steve |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | card_NV4E | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-12-05 06:56:11 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
Gideon Mayhak
2009-04-21 01:01:01 UTC
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! 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 Created attachment 341261 [details]
Output of xrandr with monitor attached at boot.
Created attachment 341262 [details]
Xorg.0.log with monitor attached at boot
Created attachment 341263 [details]
Output of xrandr with monitor absent at boot
Created attachment 341264 [details]
Xorg.0.log with monitor absent at boot
Created attachment 341265 [details]
Output of xrandr with monitor attached and configured after boot without
Created attachment 341266 [details]
Xorg.0.log with monitor attached and configured after boot without
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. 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 :-). 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? 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). 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 Any thoughts? Anything else you'd like me to try to help narrow it down? 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). 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! 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 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 ;-).
Ok, switched version to rawhide :) Will keep looking at this. Your work on nouveau has been awesome, Ben. Seriously awesome :-D. 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. 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! 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. 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. 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. 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 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 <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 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 :-). 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.] 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! (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. 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 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. 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 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. |