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

[Jeremy Huddleston Sequoia]

> On Oct 10, 2016, at 10:16, Adam Jackson <ajax at nwnk.net> wrote:
> 
> On Sun, 2016-10-09 at 12:51 -0700, Jeremy Huddleston Sequoia wrote:
>> Failure to do so causes an overvlow in glxClientCallback
> 
> This patch makes no sense at all. glxClientCallback is only added to
> the call chain _after_ we check for a GL-capable visual. If that check
> is preventing GLX from initializing, then it also prevents
> glxClientCallback being called.
> 
> More to the point, the check is still correct, Mesa still needs a TC/DC
> visual to work. I suppose non-Mesa systems might not have that
> property, but a) OSX doesn't support pseudocolor GL rendering I am like
> 99% sure and b) that just means the check belongs in screen init
> instead of being deleted entirely.
> 
> What are you trying to do here?

As I mentioned in the other thread, I agree that this shouldn't do anything wrt to ASan report, so I'm a bit confused by that and will dig into it.

However, from a correctness standpoint, I think this is still the right approach.

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.

I agree with you that these should probably be moved into RRScreenInit / __glXScreenInit and will make such a change in the next round.  I want to spend some more time trying to figure out what was going on with the ASan report because indeed it doesn't make sense that this should cause it to go away.

--Jeremy