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. > > For case 1, you might be able to recover if you could just figure out > > which client was being obstreperous. So clearly the right thing is to > > dump active grab state to the X log on VT switch. If there's anything > > there, then you know who to blame and you can pkill just that and > > recover. If there's not, then the session is doomed. > > That's useful. A lot of the time I have a good idea of what app has a > stuck grab, but this is a bit easier. Ideally there would be a way to > forcibly ungrab but I suppose that may confuse application toolkits. We had an optional bit of config file magic at one point that would let you turn on a magic key combo to break the current grab. Plus a matching request in the XFree86-Misc extension to turn it back off, since otherwise you can defeat screen locking. Gone in 1.6 though, that extension was pretty much a mistake. [1] The problem with the notion of breaking grabs is that it's an arms race. X is just broken here. The only way to fix it is to break out to a wayland mini-app that does the moral equivalent of MacOS's Force Quit. (And in some sense, by the time you're running a whole new display system to fix your old one, it's time to just move on.) Since we can't _actually_ fix grabs, the right thing to do is punish apps that abuse them. Server zap doesn't do this. It punishes the whole session. Even just breaking the grab doesn't get things fixed, because the bug stays there in the app forever. You want the recovery path to be such that you can inspect the state of the broken app at the moment it's misbehaving. Grab state dump on VT switch accomplishes this better than either zap or grab-break. [1] - Not so much that the things it embodied were bad ideas - though they all were to some extent - but that the implementation showed a willful disregard for the rest of the server. GrabBreak could easily have been a new, possibly even privileged, XKB action, but instead it was a magic trapdoor. Why do anything in the existing design when you can add another layer of crap on top. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
