On Sun, Feb 4, 2018 at 11:19 PM, Keith Packard <kei...@keithp.com> wrote: > Giuseppe Bilotta <giuseppe.bilo...@gmail.com> writes: > >> Ah, good point. So Compton wouldn't break anyway, at worst it couldn't >> use the feature reliably. > > Having any reasonable Compositing Manager not work is a sign that the > design isn't quite right.
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). > A key part of the design is that the Auto List be tied to a specific > presentation on the screen; geometry for the Auto List windows is > reserved in that image. So, we need to synchronously update the Auto > List and the presented image, hence tying them together. Given that the > Auto List is a (probably small) subset of the top-level windows, sending > it each time is probably simpler than creating a new resource to hold > it. Even sending a few hundred window IDs per frame wouldn't be > terrible. [...] >> Then if I understand correctly Mode 1 could be implemented by delaying >> the geometry change requests that happen after a Present request to >> after the actual page flip (or whichever other time is deemed “safe”), > > You raise a good point here -- we want the client geometry change to be > presented without any intermediate partial frames. I think the easiest > way to manage that is to have the Compositing Manager take control of > the display before the resize happens. It could be something as simple > as blocking any resize request for a window in the Auto List and sending > an event to the Compositing Manager to deal with the situation. > > How about this -- any configuration change (by a client other than the > Compositing Manager) affecting a member of the Auto List would be > blocked until a PresentPixmap request removes that element of the > AutoList. Adding a member to the AutoList is sufficient to register an > interest in the event. That would let us continue to allow arbitrary > windows in the AutoList and ensure that no configuration changes occur > while windows are on the Auto List. 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? 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? 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); 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? 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. -- Giuseppe "Oblomov" Bilotta _______________________________________________ firstname.lastname@example.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel