[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