The Thinkpad T30 BIOS includes a 'display sleep' setting to save battery life & screen backlight life. This appears to be independent of the X screensaver settings. Unfortunately if this display sleep kicks in, X does not recover properly. When you click any key (e.g. SHIFT) to 'wake up' the screen, it comes up in a scrambled, jumpy, unuseable condition. I have found that logging out and logging in X do not fix it. The only solution that appears to fix it (other than a reboot) is to blindly type /usr/bin/apm -s The only way I have found to avoid this problem is to use BIOS settings to disable sleep entirely. But this has the unfortunate side effect of losing a useful feature, and it impacts other setups (e.g. on a dual-boot machine). I have set the severity of this bug to "major" because the system suffers this condition "as installed" and it can very easily cause data loss. Version-Release number of selected component (if applicable): xorg-x11-6.8.2-1.FC3.13 & IBM BIOS 2.08 How reproducible: Always Steps to Reproduce: 1. Boot laptop into BIOS setup screen 2. Adjust display sleep (both AC and battery) to short but different durations (e.g. 1 minute and 3 minutes) 3. Save settings and boot into Linux 4. Wait with AC power until display sleeps, hit shift to wake up, notice scrambling 5. Recover using sleep or reboot 6. Repeat 4 with battery power Actual Results: Display wakes up in a scrambled, unuseable mode Expected Results: Display wakes up normally Additional info: Note, this problem also seems to be affected by the existence of a 2nd monitor in dual-head mode. I have not seen the problem when I have two monitors plugged in - for some reason, in this configuration, the LCD does sleep, and it does wake, properly. I always see the problem when I only have the internal laptop monitor. My system is a ThinkPad T30 running FC3, pretty much up-to-date. It has a radeon 7500 and the displays are the internal 1400x1050 and an external VGA dell 2000fp (1600x1200). I originally filed this bug as <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153744>
*** Bug 2975 has been marked as a duplicate of this bug. ***
The 'display sleep' is presumably an ACPI function. I am not sure that xorg supports ACPI sedation.
*** Bug 4436 has been marked as a duplicate of this bug. ***
*** Bug 3844 has been marked as a duplicate of this bug. ***
FWIW, I'm not sure if those other two bugs are duplicates. 4436 refers to an X crash after the laptop sleeps (or perhaps hibernates). In this bug, X is not crashed; You can move the mouse around, type, etc. and see things going on (through the garbled display). 3844 refers to a problem with dynamic clocks after suspend. In this bug, the system has not slept, suspended, or hibernated. The system is awake, it's just that the screen has been disabled (by the bios) to save energy. Please don't get me wrong, I'm glad to see that the radeon 7500 issues are getting some attention. Just want to make sure that distinct issues aren't getting mixed together.
I totally agree on Stadler on this one. Firstly I don't use ACPI Secondly I don't experience any garbled screen just a xorg crash the moment I open the lid. (In reply to comment #5) > FWIW, I'm not sure if those other two bugs are duplicates. > > 4436 refers to an X crash after the laptop sleeps (or perhaps hibernates). > > In this bug, X is not crashed; You can move the mouse around, type, etc. and see things going on > (through the garbled display). > > 3844 refers to a problem with dynamic clocks after suspend. > > In this bug, the system has not slept, suspended, or hibernated. The system is awake, it's just that the > screen has been disabled (by the bios) to save energy. > > > Please don't get me wrong, I'm glad to see that the radeon 7500 issues are getting some attention. Just > want to make sure that distinct issues aren't getting mixed together.
Bug submitter, any improvements using a current version of xorg? Are you using the radeon framebuffer at the same time?
> Bug submitter, any improvements using a current version of xorg? I'm afraid I have not upgraded past FC3 so I am still using the same versions of everything. I will update this bug when I upgrade to FC5 (soon). > Are you using the radeon framebuffer at the same time? I'm not sure what you mean, can you clarify this question please?
(In reply to comment #8) > > Bug submitter, any improvements using a current version of xorg? > > I'm afraid I have not upgraded past FC3 so I am still using the same versions of > everything. I will update this bug when I upgrade to FC5 (soon). > > > Are you using the radeon framebuffer at the same time? > > I'm not sure what you mean, can you clarify this question please? Of course. Normally you can choose in the linux kernel which framebuffer that is to drive the screen. In your case you have the choice of a standard vesa framebuffer or the radeon framebuffer. Using the radeon framebuffer gives better performance in consolemode _but_ may introduce bugs when running X as the framebuffer and the X driver may change hardware states behind each others backs. I had a similar problem before where resuming caused a garbled screen. Disabling the radeon framebuffer resolved this issue for me and might do the same for you.
I'm seeing what appears to be the same issue, but slightly different on my IBM ThinkPad T42, using X.org 7 (Fedora Core 5). I'm using gnome power manager to suspend system to ram, but on resume - although the system is up, i'm getting a blank black screen with a few pitches of "noise like lines" on the screen every now and again (twice a sec perhaps). In order for me to regain control of the system, I need to blindly ctrl-alt-f1, login and reboot. I'm using radeonfb on my console, but tried without it, with same result. I had a T30 before where this actually worked perfectly. The chipset in my T42 is: VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Let me know what you need me to provide to narrow this down
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.