On Sun, 2008-08-10 at 19:11 -0400, Kristian Høgsberg wrote: > 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?
There are so many possibilities here. I'd rather see something that didn't require a secret agreement between the server and client though. That seems prone to versioning failures. One answer would be to have a version number and then a random collection of bytes; that at least would let us change the encoding in a reasonably compatible fashion. Another alternative is a sequence of name/value pairs, where each value was a homogenous array of values. A third alternative is to have driver-specific requests to return this kind of data. That would let us completely document what was on the wire, although it would consume one request ID for each driver. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
