Backing out DRI2 from server 1.5

Kristian Høgsberg krh at
Sun Aug 10 16:11:16 PDT 2008

On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie <airlied at> wrote:
> On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg <krh at> wrote:
>> My plan is to included a device specific 32 bit bitfield per buffer in
>> the reply to DRI2Getbuffers, which is what the client calls to ask the
>> server for buffer info.  These bits can indicate properties such as
>> tiling.  In the DRI2Connect call, I'm sending back the DDX version, so
>> the DRI driver will know which bits are valid.
> I actually meant to cc the lists on this, I dislike device specific
> limited allocation bitfields
> as an API in general, can we add something with a pointer or length + array?

I debated whether to just use a bitfield or send along an arbitrary
sized device private block.  What's a little tricky about an opaque
block is that we can't byteswap it in the protocol; we don't need
that, of course, but it just feels a little icky.  More to the point,
I could not come up with anything that would require more than just a
few bits, and always including this bit field makes a lot of common
cases much easier - tiling, interlacing, swizzling... I dunno?  What
else might there be?  We can add another request if there ever is a
need for more data.


More information about the xorg mailing list