Giuseppe Bilotta <[email protected]> writes: > Well, apparently Compton already has some issues with DRI3/Present already, > e.g. > https://bugs.freedesktop.org/show_bug.cgi?id=97916 but maybe that's > Compton not being reasonable (using the root window instead of the > typical overlay).
Oh, it should work drawing to the root window; looks like there's just a bug. > Wait, I'm confused: if the Auto List is associated with a specific > presentation on the screen, and are thus in some sense ephemeral, how > can windows be added/removed from it? Added/removed in the sense that the list provided for the next PresentPixmap contains/doesn't-contain the window. > Is this to be read in the sense that the configuration change is > blocked until the CM does a Present whose Auto List does not contain > the window? Yes. > So if I read it correctly, it would work this way: > > 1. CM does a Present with an AutoList; > 2. the server keeps the AutoList until the CM does a Present with a > different AutoList (or the CM connection is closed); The server is likely to need to keep two Auto Lists; the Auto List associated with the current scanout buffer and the Auto List associated with the queued scanout buffer, but yes, it will keep them associated with the Present for the window being swapped (root or other). > 3. if anything other than the CM requests a config change for a Window > w in the AutoList, the request is stalled, but the CM is notified; > 4. the CM gets notified of the pending config request, and on the next > Present it removes w from the AutoList; > 5. the pending config change gets processed using the normal mechanism; > 6. the CM is notified of the actual change, so it can put the window > back on the AutoList of the next Present; > > Is this the general idea? Yes, thanks for the nice outline of events. It's interesting to note that we could have done the same thing for all of the redirected window management requests in the core protocol, simplifying applications tremendously... > The biggest downside I see of this approach is that a CM can stall > config changes by keeping a window in the AutoList potentially forever > (either because of bugs or maliciously). This is particularly > important if any client can do Present requests with an AutoList. Well, only one client can be the Compositing Manager with the appropriate redirection of all window rendering, so we can probably restrict the Auto List to only affect windows that the Compositing Manager has redirected. I've a whole separate set of plans for making X more secure; I hope to start writing those up in a few months. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
