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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
