Making Composite better for interactive apps

[Keith Packard]

Giuseppe Bilotta <giuseppe.bilotta at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180204/de9886e8/attachment.sig>