http://bugzilla.novell.com/show_bug.cgi?id=628039 http://bugzilla.novell.com/show_bug.cgi?id=628039#c1 Achim Gratz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Stromeko@NexGo.DE --- Comment #1 from Achim Gratz 2010-08-05 06:29:09 UTC --- I've also tried to boot with "nomodeset" now. That seems to help also, however the dreaded several-second pauses in KDE (mostly when switching between virtual desktops) is then back and compositing becomes unstable. With this setting no permanently blank screens are produced, but in FrozenBubble for instance I get sporadic half-second screen blanks. Another observation: if the display goes blank after the first KMS on boot, the DVI signal is still there (the monitor does not say "no signal, going to sleep"), but I still get a completely black screen. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c3 Achim Gratz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|Stromeko@NexGo.DE | --- Comment #3 from Achim Gratz 2011-08-31 21:13:48 UTC --- Thank you for asking. I've since switched to Tumbleweed and it is still an issue even with the latest kernel and driver. Linux 3.0.3-42-pae #1 SMP Thu Aug 25 02:17:07 UTC 2011 (026eef6) i686 athlon i386 GNU/Linux It has gotten better with the newer drivers, but all manifestations of the problem persist: 1) blank screen on DVI output after power-save or mode-switching a) mostly with the monitor still indicating a signal b) sometimes with the monitor saying "no signal, going to sleep" c) very seldomly switching between a) and b) at roughly 20 second intervals 2) sporadic 1..2s of screen going blank in the middle of things My current workaround is to set a very short (3min) DPMS power-off limit, since the DPMS related problems I was experiencing in the beginning seem to be resolved. If I let that limit expire and then re-activate the monitor it will most of the time work again. If I'm in more of a hurry, I connect/disconect VGA and that will usually resolve it, too (if not I can work for a while on VGA). I think that the DVI transmitter PLL is not locking correctly in all these instances (the problem seems to be slightly modulated with temperature) and that the original ATI driver either does a better job of a) checking the lock and resetting the PLL if necessary or b) using a more stable PLL switching sequence. If there's anything I can do to help fix this problem, let me know. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c5 --- Comment #5 from Achim Gratz 2011-08-31 21:28:58 UTC --- Who would that be and how to contact them? Is this the correct address: https://bugs.freedesktop.org/ (oh looky, yet another login/registration needed...)? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c7 --- Comment #7 from Achim Gratz 2011-11-19 14:06:19 UTC --- I did post to the development list, but did not get an answer - but maybe someone did read it. Anyhow, since the last two 3.0 kernels from Tumbleweed this issue has become quite rare for me (or maybe I'm getting better at avoiding it). It is not completely gone, however. I've found three different workarounds for those rare occasions: 1. If I know I'm still in a shell window, I just issue an

xset dpms force off

Contrary to what you'd expect, that gets the screen switched back on (I don't know why, maybe it detects that the card is in some strange state). If you issue this command while the screen is still working, the video is switched off as expected and the monitor shuts down. 2. I have my console window running at a different pixel clock than the X (mainly because I haven't bothered to tell X to use a mode with reduced blanking and the monitor doesn't offer that in EDID). Switching between to console and back to X also recovers the display. 3. Doing a suspend to RAM and then immediately waking up the computer also resets the card and gets the display back. This is actually not much slower than the other two methods... :-) HTH. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c9 Achim Gratz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|Stromeko@NexGo.DE | --- Comment #9 from Achim Gratz 2012-03-06 06:12:11 UTC --- Actually, I switched to Tumbleweed due to this issue and things have gotten much better with newer kernels, so I'm some place between 12.1 and 12.2 currently: Linux 3.2.9-12-pae #1 SMP Thu Mar 1 17:31:01 UTC 2012 (ba1cb50) i686 athlon i386 GNU/Linux The bug originally reported (display going blank directly on boot with no way to recover) hasn't happened with any of the 3.2 kernels. The display very rarely goes blank when X starts up and the display switches from tty1 to tty7. I'm not running 3.2.9 long enough to say if that still happens with that version, but I know that in 3.2.5 it still did (again, very rarely). There is still an issue when the monitor has just switched off when DPMS kicks in, but I can reliably recover by switching to tty1, waiting for the monitor to switch back on and then switching back to tty7 (X). I'll leave it to you to decide whether to keep this bug open or close it. If you keep it open, the severity should be reduced since the newer kernel have made it a minor nuisance rather than a critical issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|eich@suse.com |xorg-maintainer-bugs@forge. | |provo.novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c10 --- Comment #10 from Achim Gratz 2012-03-19 19:49:06 UTC --- Both 3.2.9 and 3.2.10 still show the behaviour sometimes and all three workarounds are still effective. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=628039 https://bugzilla.novell.com/show_bug.cgi?id=628039#c12 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #12 from Stefan Dirsch 2012-06-15 08:31:44 UTC --- Ok. Thanks for the feedback! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.