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

[Adam Jackson]

On Fri, 2016-03-11 at 11:12 -0700, Kyle Brenneman wrote:
> 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
                                                ^^^^^^^^^^^^^^^^^^^^^^^^
Should be glXGetFBConfigAttrib.

>          redundant, because a client can already find the screen number for a
>          GLXFBConfig using glXGetVisualFromFBConfig and indirectly using
>          glXGetFBConfigs.

Other than that I think we can say these are all RESOLVED.

- ajax