Suspend/resume with i915.

I'm trying to fix resume on my T61, broken by some change several
months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated
Graphics Controller (primary)'.  It's running current CURRENT and
up to date packages.

Suspend and resume makes Xorg do something weird - there is screen
corruption, or rather window corruption.  The GNOME 3 desktop looks
pretty normal, except that gnome-terminal (launched before suspend)
window looks as if the buffer layout changed underneath it; for example,
instead of one flashing cursor there are several, horizontally, across
the window.  New windows are simply black.  No segv.

Setting kern.vt.suspendswitch=0 makes the behaviour disappear, replaced
by segmentation faults of gnome-shell.  With stock gdb it looks like this:

#0  0x000000081518d7b3 in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so
#1  0x00000008151353ef in __driDriverGetExtensions_i965 () from /usr/local/lib/dri/i965_dri.so
#2  0x0000000804dfe70c in cogl_framebuffer_clear4f () from /usr/local/lib/libcogl.so.20

With gdb from ports and graphics/dri port rebuilt with debug flags, using
'make CFLAGS="-O0 -ggdb" WITH_DEBUG=yes STRIP= clean all deinstall reinstall',
it makes more sense:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 804806400 (LWP 100123)]
0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80)
    at brw_misc_state.c:225
225        if (irb->mt->stencil_mt)
(gdb) where
#0  0x0000000805bb490b in get_stencil_miptree (irb=0x80483fe80)
    at brw_misc_state.c:225
#1  0x0000000805bb3cbd in brw_workaround_depthstencil_alignment (
    brw=0x804907028, clear_mask=18) at brw_misc_state.c:241
#2  0x0000000805b3355e in brw_clear (ctx=0x804907028, mask=18)
    at brw_clear.c:235
#3  0x000000080568309e in _mesa_Clear (mask=16640)
    at ../../src/mesa/main/clear.c:225

There are several suggested fixes for this, like those:

https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/media-libs/mesa/files/10.3-dri-i965-Return-NULL-if-we-don-t-have-a-miptree.patch
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-checkins/5HAd07ICk94

They don't seem to work, though, and the Mesa codebase doesn't exactly
look promising.

Now, what I've noticed is that if I switch to VT0 (ctrl-alt-f1) and then
suspend, the resume works flawlessly, and after switching to Xorg it runs
without any problems either.  This got me thinking...  Adding this:

/usr/sbin/vidcontrol -s 1 < /dev/ttyv0

to /etc/rc.suspend, with kern.vt.suspendswitch=0, prevents suspend with
Xorg from breaking things, with a drawback that one has to manually switch
back to Xorg after resume.

So, questions:

1. Are there any patches that could actually fix suspend/resume with Xorg,
   instead of working around it?

2. Does the rc.suspend workaround seem like a proper one?  My theory is
   that it works better than kern.vt.suspendswitch=1 because it gives
   Xserver a chance to properly release VT, or "deinitialize stuff".
   Does it make sense?  If so, I could add "vidcontrol -w" to return
   number of current console, and use it, together with "vidcontrol -s",
   in rc.suspend and rc.resume scripts, if kern.vty.suspendswitch is
   enabled.  That would provide a properly working workaround without
   need for any manual configuration.

3. This is a weird one - the workaround works when closing a lid, and
   when doing "acpiconf -s3" in gnome-terminal window, but does not work
   when suspend was initiated by Fn-F4.  Any ideas?

All feedback is welcome.