-----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@xxxxxxxxxx>: >>> 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----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list