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

[Kyle Brenneman]

All right, here's an updated draft of the Issues section. How does it look?

Issues
     1)  Should GLX_VENDOR_NAMES_EXT contain a single vendor name or a 
list of
         names?

         UNRESOLVED: Allow a list of names.

         Allowing multiple names would allow for multiple client-side 
drivers
         that work with a single server-side driver. With only a single 
name,
         selecting between multiple client drivers would require some 
form of
         additional configuration.

     2)  How are vendor names defined and interpreted?

         UNRESOLVED: The vendor names for a screen are defined based on the
         server's GLX implementation. Typically, a server will simply 
send the
         name of the driver that controls the screen.

         The GLX client library is responsible for translating the 
vendor name
         to a vendor library name. The details of the translation are 
part of
         the interface between the vendor library and the GLX client 
library,
         and so are not defined in this specification.

     3)  What order should the vendor names be returned in?

         UNRESOLVED: If there are multiple vendor names, then the client 
should
         use the names earlier in the list in preference to names later 
in the
         list.

         Specifically, the GLX client library will try to load and use each
         vendor name, in the order that the server lists them. It will 
stop when
         it finds the first vendor that works.

     4)  Does the vendor name list need a new enum? Could it be appended 
to the
         GLX_VENDOR string instead?

         UNRESOLVED: Use a new enum. The vendor-specific part of the 
GLX_VENDOR
         string is by definition arbitrary, even if in practice every 
most if
         not all GLX implementatinos leave it blank.

         In addition, using a new enum also makes parsing the string much
         easier. The client can simply pass the unmodified string to 
strtok or
         strtok_r.

     5)  Do we need to define the interaction with GLX_SGIX_pbuffer?

         UNRESOLVED. No. Any client or server that implements this extension
         will already support GLX 1.3, so using glXQueryDrawable to look 
up a
         screen number is sufficient.

         There's no harm if a server includes a GLX_SCREEN attribute in its
         GetDrawableAttributesSGIX reply, so a server is still free to 
use the
         same codepath for GetDrawableAttributesSGIX and
         glXGetDrawableAttributes.

     6)  Do we want to add GLX_SCREEN to the list of fbconfig attributes as
         well?

         UNRESOLVED: No. Adding GLX_SCREEN to glXGetDrawableAttributes 
would be
         redundant, because a client can already find the screen number 
for a
         GLXFBConfig using glXGetVisualFromFBConfig and indirectly using
         glXGetFBConfigs.

Revision History

     1. 8 March 2016
         - Initial draft.



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.
>>
>> - ajax
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev