For some time since I bumped to F18, I've had an irritating problem on my desktop, using a GeForce 9600 GT (NV94, 10de:0622). On initial startup in 'runlevel 5', when I should see GDM, the display comes up (usually) completely garbled, showing garbage from the display buffer by the looks of it - either cut-up rectangular chunks of previous sessions, or the full display from the previous boot (so it looks like I'm seeing GNOME, but in fact it's not 'there' at all). I thought that https://bugzilla.redhat.com/show_bug.cgi?id=857300 had fixed this; after that patch was made available I built a scratch kernel with the patch in it, and I got several successful boots in a row. But in the last few days, the problem has come back even using that same scratch kernel or kernel-3.6.0-0.rc6.git0.2.fc18.x86_64 . halfline helped me do quite a lot of debugging on this. We eliminated gdm and plymouth as the problem - it also happens with lightdm, and it happens with plymouth.enable=0. We are now fairly sure it's an X problem, because I can 'fix' it like this: * leave the desktop showing the garbage * ssh into it from my laptop * as root, run 'DISPLAY=:0 xrandr --output DVI-I-1 --off', then 'DISPLAY=:0 xrandr --output DVI-I-1 --auto' The first command turns the right-hand screen off; the second causes it to come back on again, showing part of GDM more or less correctly. If I repeat the process with the other head, I wind up with a completely correctly rendered GDM cloned - showing on both heads. (Though in 'normal' orientation, not counter-clockwise rotated as I usually have X configured for). If I then actually log in to GNOME from the 'fixed' gdm, my left hand head - DVI-I-2, the second one I cycled with xrandr - comes up correctly, in counter-clockwise orientation, with all apps on it. My right hand head, DVI-I-1, doesn't come up (it's in power saving mode) and no amount of jiggery-pokery with xrandr or the GNOME Displays applet seems to fix it. I haven't yet tested the consequences of logging in with the heads in various 'interim' states in GDM, but the above seems to be enough to indicate there's still something screwy in nouveau even after the fix for #857300. Last week I seemed to be able to work around this bug by booting to runlevel 3 and doing 'systemctl start gdm.service', but that doesn't seem to work any more; it comes up glitched even doing that. The only 'workaround' apart from the xrandr jiggery pokery seems to be to first log in to a VT as myself and do 'startx -- vt01', let that Shell session sit for a bit, then log out of it and start GDM, at which point it works. Note, that when I do 'startx -- vt01', I see the same kind of buffer garbage for a few seconds, before it clears and I see the desktop.
of course, after all that debugging, I just did a build of 3.6.0-0.rc6.git2.1.fc18 with debugging symbols disabled - versioned 3.6.0-0.rc6.git2.1.1 - and my first two boots with that kernel have worked fine. i've no idea what causes the problem to come and go. it's very strange. i'll keep an eye on it.
It's come back since then, been broken for a couple of weeks. Still broken. I have a theory as to why startx 'fixes' it: because I have my monitor layout (dual headed, span, both monitors rotated 90 degrees) configured in GNOME's 'Displays' applet, which I believe writes it to ~/.config/monitors.xml (that file exists and describes my layout). So when I start a GNOME session as myself, gnome-settings-daemon reads that file and applies it, via xrandr. That would explain why startx 'fixes' the problem while GDM doesn't, and why it takes a few seconds before it's 'fixed' (that's how long it takes g-s-d to get to doing the RandR calls). I'm going to try copying ~/.config/monitors.xml to /etc/gnome-settings-daemon/xrandr/monitors.xml . According to the dconf org/gnome/settings-daemon/plugins/xrandr/default-configuration-file key, this should be read by the g-s-d xrandr plugin by default, so I'm hoping it'll get read and applied by g-s-d when GDM is running, which should work around the issue for me. But it's a workaround, not a fix. I'll report back on whether that helps. I could also try moving ~/.config/monitors.xml or disabling the xrandr g-s-d plugin to see if that makes startx *stop* working, but I'd rather not do that unless I have to as it'd make actually using the system much more difficult.
So this is still happening to me, and comment #2 didn't change anything. This is kind of annoying as I have to boot my system to runlevel and run startx, all the time. I just can't get in via gdm. Ben, have you had a chance to look at this? Can you reproduce it? It'd be great if I could get a fix...
This is still happening with current Rawhide. New data is that it seems only to happen if I have rotation in my X config. I have this file: Section "Device" Identifier "nouveau" Driver "nouveau" Option "Monitor-DVI-I-1" "Right Monitor" Option "Monitor-DVI-I-2" "Left Monitor" EndSection Section "Monitor" Identifier "Left Monitor" Option "Primary" "True" Option "Rotate" "left" EndSection Section "Monitor" Identifier "Right Monitor" Option "RightOf" "Left Monitor" Option "Rotate" "left" EndSection setting rotation and arrangement of my two monitors. If I leave it out of xorg.conf.d , GDM always comes up fine. If I put it in, I get the garbage. I have the same rotation and screen orientation configured in my GNOME session - GNOME will apply a user's screen preferences when that user logs in - and that works fine: GDM comes up sideways, but once I log in, GNOME applies the correct rotation and things look fine. _That_ operation doesn't cause the bug. So I think it's some kind of timing issue that happens when the rotation is applied too soon after X startup, or something like that? I can live with the 'let GDM come up sideways' workaround for now, but it'd be great to get this fixed some time...
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Still valid last I checked in F20, I'm on Rawhide now, will confirm it's still happening soon. I've been using a sideways GDM for like a year now. :)
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 EOL if it remains open with a Fedora 'version' of '23'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Don't think I've seen this for a while.