[PATCH 3/3] glx: Initialize glx even if there are currently no screens attached

Adam Jackson ajax at nwnk.net
Tue Oct 11 16:48:27 UTC 2016


On Mon, 2016-10-10 at 16:30 -0700, Jeremy Huddleston Sequoia wrote:

> Yes, GLX requires a GL-capable visual in order to work, but that
> doesn't mean that it needs to be present at the time that the
> extension is initialized.  We be able to start with 0 screens
> attached and then treat adding #1 the same as we would adding #2.

That's a noble goal and all, but there's a pile of work needed before
that's possible. Right now the ddx tells dix what kind of visuals it
supports, so with "zero" screens you would have zero visuals. You
probably don't want to change the visual list dynamically, because
there's no way to notify already-connected clients that it has changed.
We'd need to reorganize things so dix _declares_ what kind of visuals
it will support, and ddx conform to that. (Which is a bit awkward if
you declare 32bpp and then plug in a device that wants 16bpp... maybe
we just don't care about that case.)

Even then, GLX would make it complicated, because we can't peek ahead
to know what kind of 3D support we'll have, so we can't know to create
visuals that are stereo- or multisample-capable. Admittedly some of
this is a Mesa bug, in that things like the z/s buffer are allocated at
context creation based on the fbconfig rather than as needed, so you
want not to just make the root window visual all-capable.

All that said, if that's something you're working on, please don't let
me discourage you.

- ajax


More information about the xorg-devel mailing list