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