Is a GLXFBConfig's type really XID?

[nwnk]

(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?

[cubanismo]

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:

• FBConfig IDs are unique and persistent across a given X server instance, so logical programs that span multiple processes can look up an FBConfig XID in one process and reliably retrieve the same FBConfig when talking to the same X server in another process.

• GLVND may also rely on FBConfigs being unique across vendors on a given X display connection, but I'd have to ask Kyle or dig through the source to be sure. You probably know more about any related server-side GLVND requirements (if any) than me.

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.

[cubanismo]

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.

[pdaniell-nv]

@nwnk What's next for this issue?

[nwnk]

[W]e require at least that:

• FBConfig IDs are unique and persistent across a given X server instance, so logical programs that span multiple processes can look up an FBConfig XID in one process and reliably retrieve the same FBConfig when talking to the same X server in another process.

Agreed.

• GLVND may also rely on FBConfigs being unique across vendors on a given X display connection, but I'd have to ask Kyle or dig through the source to be sure. You probably know more about any related server-side GLVND requirements (if any) than me.

It does indeed require this.

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, [...]

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.

[nwnk]

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.

[oddhack]

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.