[PATCH xserver 0/7] Implement backing store's Always mode (version... something)

Adam Jackson ajax at redhat.com
Tue Jul 24 19:47:27 UTC 2018


This is a resend of a series I wrote forever ago and nobody dared
review. It probably needs some additional review and rethinking, but it
definitely shouldn't keep languishing on my hard drive.

The core issue is that Always windows need to have their pixels
allocated before the window is ever mapped; some (arguably pathological)
applications rely on this to the extent of using the unmapped window as
their "offscreen pixmap" and blitting from that to one that's actually
mapped. The window tree validation code isn't quite prepared for this,
it currently assumes only "viewable" windows need to have valid clip
lists (where "viewable" means "InputOutput, is mapped, and all ancestors
are mapped"). So this series adds a new "paintable" window state that is
effectively "viewable || Always", and adjusts clip list and pixmap
management to match.

I'm not totally convinced this approach works in combination with
overlays (the RGB kind, not the YUV kind); I think mi/mioverlay.c might
need to be made similarly aware of Always windows. But if that's the
rabbit hole we're going down, I'm not convinced any of ->ValidateTree is
factored correctly. I certainly don't like having three mostly-identical
copies of it (mi, mioverlay, rootless) nor do I like how xwin/xquartz
and xwayland do rootless entirely differently. The mi code certainly has
that "optimized for the sun3" smell to it, rewriting it to be
comprehensible might be worth whatever performance penalty that incurs.

fb/fboverlay.c might work with this approach, but the only driver using
that appears to be savage (and in NoAccel mode only! we should delete
that) so I might prefer dropping fboverlay in any case.

I have some test cases for this that I need to dig out of various
archives (and probably a more updated branch somewhere too), and I want
to be a bit more sure our tests really are covering this code before
merging. Still, any and all feedback appreciated.

- ajax




More information about the xorg-devel mailing list