-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam Jackson wrote:
On Tue, 2009-03-31 at 10:51 -0400, Colin Walters wrote:
> 2009/3/31 Adam Jackson <ajax(a)redhat.com>:
>> So let's list the cases that zap would actually recover from:
>>
>> 1: stuck grabs
>> 2: focus reverts to None and your window manager is dead
>> 3: X driver that's decided to stop rendering (or stop rendering
>> correctly)
> Let me add:
>
> 4: Randr configuration is either broken or out of date, and the system
> didn't detect it correctly
>
> More than a few times now I've forgotten I had set up an external
> monitor, suspended, and unsuspended later and faced with a black
> screen thought my machine had locked. Of course this is a system bug,
> but then all of these things are.
Yeah, this is hard.
Part of the problem here is that the X server doesn't really have a good
way of knowing when a suspend happens. For UMS drivers, we vt-switch
and hope that works, but that means you can't distinguish normal vt
switch from suspend. Maybe you always want to do an output rescan at vt
enter? Maybe not. Maybe just rescan and send config change events to
the desktop, but not actively change the topology.
For KMS drivers, we suspend in place now, which is pretty awesome since
it eliminates flicker on the way down and on the way back up. So the
kernel driver ought to be smart enough to send configuration changes
back through a uevent. I don't think we're doing anything with those
events yet though.
If X simply knew it was in an inconsistent state, could it initiate
recovery from there? It'd be nice if we could have a simple
/usr/bin/xreconfig so we could add this to the "easy fix from vt" cases.
- --CJD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org
iEYEARECAAYFAknUSkMACgkQIHOkVH4pLz5yQQCfe7A3yJMoGqkdqFnQIO4pTeva
yHsAoIx5k2MWnMbMBdkLaJ0Q/KloGur+
=lRs2
-----END PGP SIGNATURE-----