-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is a GLXFBConfig's type really XID? #202
Comments
In our implementation we allocate them using FakeClientID(0) but never call AddResource() on them. Our visual IDs and FBConfigs are not currently numerically equal for equivalent visuals. I also don't know what application-visible qualities this imbues in them though. I think we require at least that:
I believe we map more than one FBConfig to a single X visual in some cases (as the spec seems to encourage), so I don't really like the idea of trying to make vid:fid map 1:1 for "equivalent" visuals/configs, but if it enables/simplifies some other useful feature we could probably find a way to rework things somehow. Our main motivation here I think was just reducing the number of visuals. We expose some horribly large number of visuals as it is, and I think it was starting to cause problems. |
Note we should be careful to disambiguate GLXFBConfig, the GL client API header type which is a pointer, and the GLXFBConfig protocol type, which is XID. I'm assuming we're talking about the protocol-level object here. |
@nwnk What's next for this issue? |
Agreed.
It does indeed require this.
That's fair. I think the conclusion is, fbconfig IDs are not resources. Their size on the wire is the same as an XID, but they're allocated from the same namespace as visual IDs, which means they ought not alias a visual ID. The X server might have a convention about which allocator to use, and we may well want to stop using FakeClientID() for that purpose, but that's an implementation detail. In terms of spec updates I think this just means changing the word "XID" to "int" or "ID" in a few places. I'll write the patch for that. |
Or, I would, but I don't know where the source to the GLX spec went. I can probably find it in the internal Khronos svn but it doesn't appear to be in any of the public repos. |
GLX and GL spec sources aren't public, and GLX has been updated so rarely I haven't even moved it out of SVN into internal gitlab, which will be required since we've made SVN read-only :-) That said if you want to send me a patch against ogl/trunk/specs/glx in SVN, I'll make the right stuff happen. |
(Incredibly low priority, spec-lawyer-y kind of issue, just writing it down for posterity.)
The GLX spec calls them XIDs, or at least, implies that the storage for a number describing an fbconfig is as big as an XID. But they don't really correspond to an XID inside the server, they're not in the resource database and they don't name an object. I think this is an artifact of the (X server) sample implementation, which allocates visual IDs with the same allocator as server-owned resource IDs, and then the GLX code probably copied that when fbconfigs were added. Certainly that's what X.org did when we finally got around to implementing 1.3 (the SGI SI only went through 1.2).
I'd like Xorg to stop doing the visual ID hack described above, and allocate visuals with their own allocator. I might like the ability to say fbconfigs are in that namespace, as it's unambiguous. I might especially like to say that fbconfig IDs and visual IDs are numerically equal if the visual supports GLX_WINDOW_BIT.
I guess the question here is, is the word "XID" in the GLX spec a comment about just the size of the integer, or about the namespace it came from? Is there any implementation that meaningfully differs, and could a change here possibly break an app?
The text was updated successfully, but these errors were encountered: