[PATCH 2/3] randr: Initialize RandR even if there are currently no screens attached

[Jeremy Huddleston Sequoia]

> On Oct 10, 2016, at 03:33, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 
> Hi Jeremy,
> 
> On 9 October 2016 at 20:51, Jeremy Huddleston Sequoia
> <jeremyhu at apple.com> wrote:
>> Failure to do so causes an overvlow in RRClientCallback().
>> 
> s/overvlow/overflow/

Doh, corrected the typo, thanks.

> Perhaps a slightly silly question:
> How can one end up in the callback if we haven't executed
> AddCallback(&ClientStateCallback, fooCallback... ?

Not silly at all, and actually quite pointed.  The same basic question applies to this and the third patch in the series.

From a correctness standpoint, it makes sense that GLX and RandR should initialize even when the first display hasn't yet been configured.  They should handle attachment of the first display in much the same way they'd handle attaching the second or third display.

Looking at the actual change, I agree with you that one should not expect the change to have any impact on the reported problem because the removed early-exit was before AddCallback() in both cases.  I developed these changes against the commit that introduced the regression (30ac7567980a1eb79d084a63e0e74e1d9a3af673), so I just took a look at the tree back at that time to see if maybe something else had changed between then and current master to explain this.  Nothing obvious stands out, which begs the question of why this had any impact whatsoever on this issue.

I'm curious and will trace through it more when I get some cycles to figure out what's actually going on there.

In the mean time, this is still valid for correctness reasons, so I'd like to get some feedback on it from that angle while I try to figure out what was really going on in those reported overflows.

Thanks,
Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161010/ad04996d/attachment.bin>