A have a cocktail of i810 issues. Running the almost-latest i810 1.6.3, I currently have either one of two problems. 1) Without any further options set, upon S3 suspend/resume, the cursor is invisible. Aside from that the system seems fine. M. Dänzer suggested working around that problem by setting the SWcursor option, which brings us to the other bug. 2) With Option "SWcursor", I have the cursor back after s3 resume, but then the ghosting bug appears. And this time it seems to be happening every time. When I say "ghosting" I mean that upon resume when the X screen reappears, there is a faint blue aura over the top bar (gnome toolbar). This gives me a hint of worse problems: if I try to move a window, its repainting window stays where it was previously, so that as I move the frame to the side, it moves beyond the repainting frame, effectively become invisible. If I switch between workspaces, the contents of the previous space is still visible over the frame of the windows in the other workspace (in the xterm windows, for instance). I tried i810 1.6.1 a couple of days ago before upgrading to 1.6.3. 1.6.1 did not seem to have these problems, resume occurred correctly. My versions are: video card: 82852/855GM i810: 1.6.3 Xorg: 7.1.1 (i.e. 1.1.1) Linux kernel: 2.6.17 libdrm: 2.0.1 mesa: 6.5.0.cvs.20060524-1 We are in the middle of upgrading debian to X11R7.1, so let me know if there are any required library versions you want me to double check. I'll attach the 1.6.3 with SWcursor log. Tell me if you also want the log without SWcursor.
Created attachment 6512 [details] log when ghosting occurs (i810 1.6.3) Ghosting occurs after S3 resume when SWcursor is set. resume only works when the cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config echo -n mem > /sys/power/state cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 hack is used.
I'm giving up on using the current driver with suspend/resume. It's just unworkable given the BIOS has to do the work. Try the modesetting branch which should work much better with suspend/resume.
Oh, there is the alternative of looking at /usr/src/linux/Documentation/power/video.txt for other helpful issues with suspend . You might want to try using the s3_bios option to see if that helps.
Created attachment 6513 [details] log with good resume (i810 1.6.1) OK, I'll try various permutations and report back if I have any success. In the meanwhile, here is the log from 1.6.1 with normal (HW) cursor. After resume it works fine. Curiously, at resume it does give the blue aura over the top bar of the screen, but upon clicking the mouse button, the aura disappears and the system behaves normally. The cursor is in place and windows draw correctly. What changed between 1.6.1 and 1.6.3?
None of the S3 suspend-to-ram alternatives I've tried so far seem to help. Not s3_bios nor s3_mode not s2ram. Fortunately s2disk (new app for S4 suspend-to-disk) appears to work fine, so this is probably my best workaround. It's what I wanted all along, in fact, I've only been using S3 because S4 never worked before.
I can confirm accidental disappearing of cursor after S3 resume in modesetting branch. Sometimes (I did not figure out when exactly), after S3 resume, the cursor is shown at position 0,0 instead of current position. If this happen and I switch to console and back, then I got only blank screen. Dumping register shows that Pipe SRC is set to random value. If I cycle windows on desktop using [alt]-[tab] then cursor is back normal until it crosses border of any window. For me, it looks like accidental memory corruption.
Can you try the latest git repo.
Is vbetool being used in the suspend/resume scripts ?? If so, turn it off and report back.
The bug priority was upgraded (P2->high) with the bugzilla configuration change. I'm Changing the priority back to the normal one. Sorry for the spam.
Closing. Please use the new 2.0 driver.
Sorry for the bad news, S3 suspend is still broken under intel 2.0. The cursor is now fine (I've adjusted the bug title accordingly) but the ghosting windows are still in play. Running intel 2.0.0 (debian 2:2.0.0-1) under xserver 1.3 (debian 2:1.3.0.0.dfsg-4), for Intel 855GM (IBM Thinkpad R51). The same behaviour occurs using three alternate methods of suspend: the default method of the gnome-power-manager (2.18.2), clicking on "suspend"; and running the script mentioned earlier: cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config echo -n mem > /sys/power/state cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 or its variant with kbd console tools: curcons=`fgconsole` chvt 1 cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config sync sleep 2 echo -n mem > /sys/power/state cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 chvt $curcons (so vbetools is not being used).
Created attachment 9971 [details] log for intel 2.0 The X log obtained by entering S3 suspend from gnome-power-manager
The i810 Option VBERestore helps me with the ghosting windows. s2disk and s2ram use common workarounds for certain chipsets, which seems to have vbetool included for the 855gm. With the following option it works fine with normal suspend2ram: Option "VBERestore" "true"
Sascha, which version of the driver are you working with? The man page for the intel driver (2.0.0) does not have the VBERestore option, and indeed, when I add the option, the server log reports (WW) intel(0): Option "VBERestore" is not used Correspondingly, the problem of the ghost windows is still there upon S3 suspend/resume. Looks like VBERestore was removed last September in commit b6ba268d0d5f22c6a18ce45416452fce83438620
You could also try booting your kernel with 'acpi_sleep=s3_bios' to see if that helps.
acpi_sleep=s3_bios does not work, unfortunately (with linux kernel 2.6.22). Upon resume the display shows the last screen at point of suspending (with the message "Suspending") but goes no further with the system frozen. acpi_sleep=s3_mode works the same way as with no option, resulting in the ghosted windows. This is with linux 2.6.22, xserver 1.3.0.0 and X intel video driver 2.1.0.
Probably worth mentioning that the ghosted window problem seems to be fixed now. Invoking S3 suspend-to-ram via the Gnome suspend button (part of Gnome power management), the computer now enters suspend and resumes successfully. All windows (and mouse cursor) seem to be working correctly. Versions are intel driver 2.1.1 (Debian 2:2.1.1-4) Xorg 1.4 (2:1.4-3) Linux kernel 2.6.22 (2.6.22-3) gnome-powermanager 2.20.0 (2.20.0-1+b1) There is a problem that when switching to virtual console via Ctrl-Alt-F1, the virtual consoles come up blank, but I think that might be a different bug. Switching to Alt-F7 returns successfully back to the X session.
Ok, I'll mark this fixed then. You can file another bug or look for a DUP of the other problem. One thing to check with the VT switch problem is whether it works correctly before a suspend/resume cycle. If it works then but gives you a blank screen after you've done a suspend/resume, then it's possible the i915 DRM suspend/resume patch I posted to lkml and dri-devel@lists.sf.net will help you out. Thanks for filing the bug and testing.
Curiously about the VT switching problem, seems it only occurred after S3 suspend-to-ram. Resuming from S4 suspend-to-disk (suspending from the same session where VT switching was broken), the virtual consoles were restored again. Anyway, I'll follow this problem up separately in the VT bug reports.
Yeah, that means we're probably not saving & restoring VGA text mode properly. Can you give that DRM patch a try? Or just try the latest bits from the Mesa DRM tree (git://anongit.freedesktop.org/git/mesa/drm)? If that doesn't work, please file another bug or add to one of the existing ones... Thanks, Jesse
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.