Compiz, Textured video and suspend/resume with X1600

[merkurial]

I'm using a macboook pro (X1600).

I finally found a stable setup on my system without any trace of fglrx.
I have compiz, textured video, and vblank, which means I can use Xv either full screen or in a window with no flickering while using compiz!

For this setup I'm mostly using stable releases of software or release candidates, but one, x11-drm, from git. The others are xorg-server 1.4.99.905, mesa 7.1_rc3 and xorg-video-ati 6.9.0. My libdrm is 2.3.1 and libpciaccess 0.10.3

Formerly I was using all git versions but was having some stability problems, hence I went back to stable releases as much as I could.

With these versions my system seems rock solid stable. With high activity of all manners (CPU, video, USB, wifi and hd), with NOHZ and PREEMT enabled: not a single hard or soft lockup, neither segfaults or segmentation faults, which were happening to me before.

The only thing I couldn't get to work is suspend/resume. With fglrx, with the simple acpi video flags s3 bios quirk, I could do it reliably from X over and over again with a simple 'echo -n mem > /sys/power/state'.

I already tried anything I could think of to suspend with this OSS driver, and nothing works. Does anyone have it working ? From X or VT? How exactly?

[d2kx]

I do not know how to help you, but I do know that once kernel modesetting is working suspend/resume no longer should be a problem

[c0un7d0wn]

I am using pretty much everything from git on x1600. I use pm-utils for suspend/hibernation with no problems so far.

[merkurial]

d2kx: the problem is waiting til that arrives, since I am now reluctant to go back to fglrx. XAA seems unbearably slow after having tried EXA, which really has given life back to my desktop

c0un7d0wn: by everything, you mean also xorg modules? Could you give me a more thorough list? I would be willing to update whatever I need if that means I could improve stability further and/or get suspend/resume to work.
Could you tell me which quirks does your pm-utils use? In case you?re not sure, just give me the output of ?lshal | grep quirk?.

[c0un7d0wn]

xserver, mesa, drm, xf86-video-ati, drm kernel modules.

$ lshal | grep quirk
  power_management.quirk.vbe_post = true  (bool)
  power_management.quirk.vbemode_restore = true  (bool)

Here is pm-suspend log if it helps:

$ cat /var/log/pm-suspend.log
Initial commandline parameters:
Mon Jul 21 06:44:31 EDT 2008: Running hooks for suspend.
/usr/lib/pm-utils/sleep.d/00clear suspend: success.
/usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
/usr/lib/pm-utils/sleep.d/50modules suspend: not applicable.
/usr/lib/pm-utils/sleep.d/90clock suspend: success.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
/usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: not applicable.
/usr/lib/pm-utils/sleep.d/99video suspend: success.
Mon Jul 21 06:44:36 EDT 2008: performing suspend
Mon Jul 21 07:54:08 EDT 2008: Awake.
Mon Jul 21 07:54:08 EDT 2008: Running hooks for resume
/usr/lib/pm-utils/sleep.d/99video resume: success.
/usr/lib/pm-utils/sleep.d/98smart-kernel-video resume: success.
/usr/lib/pm-utils/sleep.d/95led resume: not applicable.
/usr/lib/pm-utils/sleep.d/94cpufreq resume: success.
/usr/lib/pm-utils/sleep.d/90clock resume: success.
/usr/lib/pm-utils/sleep.d/50modules resume: success.
/usr/lib/pm-utils/sleep.d/49bluetooth resume: not applicable.
/usr/lib/pm-utils/sleep.d/10NetworkManager resume: success.
/usr/lib/pm-utils/sleep.d/05led resume: not applicable.
/usr/lib/pm-utils/sleep.d/00clear resume: success.
Mon Jul 21 07:54:09 EDT 2008: Finished.

[neuron]

Do you have framebuffer enabled? That's the only thing that doesn't work for me.

Without framebuffer I can do s2ram -f and it'll work no problem (X1650 card).

[c0un7d0wn]

No framebuffer. It is disabled.

[merkurial]

With all that in mind I'll definitely need to try with git versions of at least xorg-server, mesa, drm and ati.

Without framebuffer there was no way to get even once a VT survive a suspend cycle. Whereas with UVESAFB I got around twice a resumed system with a working VT (precisely with the exact two quirks you seem to use). Alas, only a couple times. Not at all reliably.

Indeed, what led me to insist on trying to get suspend working with framebuffer (UVESAFB, which was what best worked with fglrx) enabled, was that without FB, the few times I could s/r, I always got blank VTs, no matter what, and the success rate was about the same.