[xserver patch v6 4/5] dri2: Support the DRI2InvalidateBuffers event.

Francisco Jerez currojerez at riseup.net
Tue Feb 23 03:30:53 PST 2010

Keith Packard <keithp at keithp.com> writes:

> On Mon, 22 Feb 2010 23:56:59 +0100, Francisco Jerez <currojerez at riseup.net> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100223/62db2f83/attachment.pgp>

More information about the xorg-devel mailing list