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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel