[PATCH xserver] dix: Move {Change, Copy, Destroy}Clip from GCFuncs to Screen

Adam Jackson ajax at redhat.com
Wed Mar 1 21:05:04 UTC 2017


On Wed, 2017-03-01 at 00:07 -0800, Keith Packard wrote:
> > Eric Anholt <eric at anholt.net> writes:
> 
> > I tried to come up with a reason I would want a layer to be able to
> > change the funcs per-gc at runtime, and failed.  Yay for killing
> > boilerplate.
> 
> So, if we're changing wrappers, anyone want to consider a more
> outlandish plan, like replacing the current ad-hoc plan of stashing the
> current value away in a screen private and writing your own version?

Mmm. Maybe? I think I'd want to approach it with a clear idea of what
we're trying to improve though, and I suspect if we did that we'd
discover that the problem is not wrapping as a technique per se. The
discussion about dix-level damage, for example: the problem being
solved there is that you don't want to encapsulate that state in a
layer, you want it across layers.

> There are a bunch of places which end up with wrappers for things like
> CloseScreen, which should pretty obviously just be a notification chain
> for various server events; that would remove a bunch of icky wrapper
> code.

CloseScreen is an awful interface, yes. It's also one of the few screen
interfaces that every driver wraps, so it'll be a little painful to
clean up.

> For the real wrappers, I think we can start with some requirements:
> 
>  1) Remove wrappers at any time.
> 
>  2) Insert at the 'right place' in the chain, independent of where the
>     wrapping happens.
> 
>  3) "impossible" to get wrong, so no cult-n-paste code
>     needed for every step of wrapping

I'm not really sold on the need for 1. Where would that be useful?

I don't understand what you mean by 2.

3 is... probably good? We could at least have a standard set of macros
for the wrap/unwrap convention that would get things right like "be
sure to re-stash the fptr from the layer below every time".

> I wonder if we could specify a total order of wrappers in the server and
> then make that part of the ABI? In the current server, for drawing, I
> think we've got something like?
> 
>         damage
>         accel (exa/glamor)
>         fb
>         mi
> 
> (is that it?)

It's close. Xinerama wraps closest to dispatch, if it's enabled. vga
arb wraps in between damage and accel. rootless lives at the accel
layer, but all it does is coerce window planemasks to preserve alpha.
And 'fb' is fb or wfb or nest/dmx where the latter two don't hit mi at
all.

- ajax


More information about the xorg-devel mailing list