On Sun, Aug 10, 2008 at 5:07 PM, Dave Airlie <[EMAIL PROTECTED]> wrote: > On Mon, Aug 11, 2008 at 5:46 AM, Kristian Høgsberg <[EMAIL PROTECTED]> 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. Kristian ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel