[Mesa-dev] GLX extension for vendor name lookup in libglvnd

Kyle Brenneman kbrenneman at nvidia.com
Thu Mar 10 15:32:06 UTC 2016


On 03/09/2016 12:53 PM, Kyle Brenneman wrote:
> On 03/09/2016 12:21 PM, Adam Jackson wrote:
>> On Wed, 2016-03-09 at 11:15 -0700, Kyle Brenneman wrote:
>>> The current implementation of libglvnd uses a new X extension called
>>> x11glvnd to look up a vendor name for each screen and to find a screen
>>> number for a GLXDrawable.
>>>
>>> But, Adam Jackson pointed out that a GLX extension could do the same 
>>> job
>>> more cleanly: Looking up a vendor name is just querying a per-screen
>>> string, which GLXQueryServerString does. Looking up a screen number for
>>> a drawable could work by adding a GLX_SCREEN attribute to the
>>> GLXGetDrawableAttributes reply.
>>>
>>> Based on that idea, I've written up a rough draft of a GLX extension
>>> spec. Any comments, questions, or suggestions are welcome, of course.
>> Argh, you beat me to it, I'd written almost exactly the same thing. I
>> just an update to my serverstring branch on github implementing what
>> I'd spec'd, details below...
> Ah, sorry about that. I should have mentioned that I was working on it.
>>> New Tokens
>>>
>>>       Accepted by the  parameter of glXQueryServerString:
>>>
>>>           GLX_VENDOR_NAMES_EXT    0x????
>> Perhaps easier than getting an enum allocated here, I'd appended this
>> string to the end of the response for GLX_VERSION, in the form
>>
>>      glvnd:<list>
>>
>> where list is comma-separated, since that part of the string is already
>> "vendor-specific info".
> That could work, although I would expect "vendor-specific info" to 
> mean "random, arbitrary, and probably not machine-parsable". I'd be 
> hesitant to try to impose a structure on something that's never had 
> any structure before.
>>
>> Agreed with your rationale in the Issues section. I'd also had:
>>
>>      1) Do we need to define the interaction with GLX_SGIX_pbuffer?
>>
>>         UNRESOLVED.  Xorg uses the same code paths for the 1.3 and
>>         pbuffer versions of GetDrawableAttributes, but extra attributes
>>         are probably harmless.
> We probably don't need to -- as you say, extra attributes are likely 
> harmless. I'd guess that any system that supports libglvnd is going to 
> support at least GLX 1.3, so using glXQueryDrawable to look up the 
> screen number seems reasonable.
>>
>>      2) Do we want to add GLX_SCREEN to the list of fbconfig attributes
>>         as well?
>>
>>         UNRESOLVED.  glvnd does not need that information, but it would
>>         be a natural orthogonality, and GLX_SGIX_fbconfig mentions it
>>         though GLX 1.3 does not.
> Possibly, but that wouldn't change the protocol at all. The screen 
> number is included in the glXGetFBConfigs request, so it wouldn't make 
> sense to add it to the reply as well. It would be up to the client to 
> keep track of it instead.
Oh, wait. Now that I think about it, GLX already provides a GLXFBConfig 
to screen mapping in glXGetVisualFromFBConfig, and indirectly from 
glXGetFBConfigs.

So, unless someone feels strongly otherwise, I think it would make the 
most sense to leave glXGetFBConfigAttrib as it is.

>>
>> - ajax
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



More information about the mesa-dev mailing list