On 05/14/2012 08:51 AM, Kristian Høgsberg wrote: > On Thu, May 10, 2012 at 3:04 AM, Chad Versace > <chad.vers...@linux.intel.com> wrote: >> Bump dri2proto dependency to 2.7. >> Bump DRI2INFOREC_VERSION to 7. >> >> This new protocol request effectively allows clients to perform feature >> detection on the DDX. The request was added in DRI2 protocol 1.4. >> >> If I had DRI2GetParam in June 2011, when I was implementing support in the >> Intel DDX and Mesa for new hardware that required a new DRI2 attachment >> format, then I could have avoided a week of pain caused by the necessity >> of writing a horrid feature detection hack [1] in Mesa. In the future, when >> the work begins to add MSAA support to the Intel DDX, having a clean way >> to do feature detection will allow us to avoid revisiting and expanding >> that hack. > > Yeah, that looks fine, should make things simpler than trying to infer > from version numbers. If we expect to add many parameters or query > them often (per frame), we should think about how to query a batch of > parameters at a time to avoid multiple roundtrips. EGL uses xcb, so > it's not a big deal there, and for GLX, the protocol code is in mesa, > so we could just pipeline the request/reply code by hand if we have > to. > > Also, if I was painting this bikeshed I'd just drop the namespace arg, > and have a CARD32 be the param and put driver params above 0x1000 or > whatever. CARD64 for the value makes sense, at least some of the > crazy swap parameters are 64 bit. > > Kristian
You threw some paint on the bikeshed, and it stuck. I never liked the namespace argument, but it was only solution I arrived at; I like the idea of enum ranges better. And, if we really need 2^64 parameter names, something is terribly wrong. Let's let the high byte determine which component owns the paramter name. Parameter names 0x00------ are reserved for the server. Names 0x01------ are owned by the DDX. Other names are reserved for future use. I'll resubmit the patch series with the changes. Chad _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel