Backing out DRI2 from server 1.5
eric at anholt.net
Mon Aug 11 10:40:24 PDT 2008
On Sun, 2008-08-10 at 19:11 -0400, Kristian Høgsberg wrote:
> On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie <airlied at gmail.com> wrote:
> > On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg <krh at bitplanet.net> 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.
For GEM I don't need tiling or swizzling information. I just ask the
kernel what the answer is, since the DDX hadn't been telling me the
information I needed in the past.
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the xorg