[PATCH xserver V3] use xcb struct in render

Peter Hutterer peter.hutterer at who-t.net
Sun Feb 1 13:44:44 PST 2015

On Fri, Jan 30, 2015 at 04:16:27PM +0100, Christian Linhart wrote:
> On 01/30/15 06:20, Peter Hutterer wrote:
> > On Sun, Jan 18, 2015 at 02:57:21PM +0530, Jaya Tiwari wrote:
> >> Replacing manually written proto headers for render extension with xcb
> >> generated structs
> >> Have changed simple requests without list/switch and replies
> >>
> >> Signed-off-by: Jaya Tiwari <tiwari.jaya18 at gmail.com>
> > Patch looks good minus the whitespace issue that Christian already pointed
> > out. Can I ask though: what's the longer-term plan here? Is this the only
> > extension to be changed, or are there others that work similarly? While this
> > is an improvement, it'd be nice to see a number of patches that do this go
> > in at the same time, having only one extension use xcb makes it stand out a
> > bit.
> The longer term plan is to change all extensions this way.
> Render is just the first extension to do this.
> The next step is to convert the rest of render in this way,
> e.g, handling of lists using xcb-access-functions,
> length-functions and iterators.
> This will replace constructs like
> * "&(stuff[1])"
> * and computing list lengths with handwritten arithmetics.
> For that, one part of the xml-definition of render needs to be fixed:
> The list in request SetPictureClipRectangles does not have a length-definition yet.
> Jaya is currently working on fixing the missing length.
> The length of the list depends on the request length.
> In theory, this can be solved with an expression using <op> elements,
> but right now, it does not work to access  the hidden "length" field
> of the request with a <fieldref> tag.
> So Jaya is working on changing the generator accordingly.
> So, this is done step by step until (hopefully) completion in all extensions.
> Of course, the first extension is more work because all the base stuff has to be solved there.

yeah, fair enough. I'd say for now the best approach is to keep the reviewed
patches in a tree and accumulate them until we have something resembling
critical mass. Then merge them all (plus, 1.17 is out very soon so we have
to wait until after that anyway).


More information about the xorg-devel mailing list