Keith Packard <[email protected]> writes: > On Mon, 22 Feb 2010 23:56:59 +0100, Francisco Jerez <[email protected]> > wrote: > >> Discussed here [1], in short, the point of the PreConfigureWindow hook >> is that it's executed before any ConfigureNotify events get queued up, >> we want this to avoid a race condition. > > If you want a specific event order to be required, then I'd suggest > putting that requirement into the DRI2 protocol spec as well. In > particular, it looks like you want the InvalidateBuffers event delivered > before the client receives any other notification that the buffers might > be invalid. > Agreed, we should be guaranteeing this to clients.
> I note that the DRI2 protocol spec doesn't say when or how clients might
> express interest in the events -- I assume you just get them when you
> start using DRI2 requests on a drawable, but it would be nice to have
> that nailed down.
>
OK, I'll cook a new dri2proto patch to clarify this a bit.
>> + if (ds->PreConfigureWindow) {
>> + pScreen->PreConfigureWindow = ds->PreConfigureWindow;
>> + (*pScreen->PreConfigureWindow)(pWin, x, y, w, h, bw, pSib);
>> + ds->PreConfigureWindow = pScreen->PreConfigureWindow;
>> + }
>
> You need to reset pScreen->PreConfigureWindow here, otherwise you've
> just lost your hook...
>
Yeah, sorry for that, it's already fixed on v7.
> Thinking about this a bit more, could you call this a ConfigNotify hook?
> It seems like this is the desired semantic -- notification without any
> option to change the operation or even cause it to
> fail. PreConfigureWindow seems like a function which might need to do
> something.
Sounds good to me, I'll resend 1/5 and 4/5 updated to the new naming
later today.
pgpzY9oVOtJQm.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
