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