> On Oct 10, 2016, at 03:33, Emil Velikov <emil.l.veli...@gmail.com> wrote: > > Hi Jeremy, > > On 9 October 2016 at 20:51, Jeremy Huddleston Sequoia > <jerem...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
