[RFC v.2] Extend wl_surface protocol

[Axel Davy]

On 11/11/2013, Pekka Paalanen wrote :
> Hi Axel
>
> On Fri, 08 Nov 2013 23:49:25 +0100
> Axel Davy <davy at clipper.ens.fr> wrote:
>
>> Hello,
>>
>> I've read carefully your new protocol proposition,
>> but I think it doesn't meet the requirements to implement
>> the X Present extension for XWayland.
>>
>> The problem is that I need to be able to use the frame
>> request too (I need the frame callback and the presentation time).
> Why do you need the frame callback? Is it to know when your one queued
> buffer gets into use? That's the idea got from below.
>
> And you specifically do not want to wait so long, that the presentation
> timestamp arrives?
I just want the frame callback to count the number of screen refresh, 
and be able to
target one.
>> Except this problem, I think your protocol proposition is fine.
>> I suggest to change the spec
>> to include the fact that queue is a more complete commit,
>> and will take into account a pending frame request,
>> and associate it to the wl_buffer we queue.
>> Since the frame request is linked to a callback, the client
>> can find to which buffer it is associated when it gets the
>> frame feedback.
> I don't think it makes sense to say, that "When the compositor
> applies a buffer from the buffer queue, it will also implicitly commit
> all pending frame requests." That's implicit behaviour across two
> different interfaces in a rather surprising way, IMHO.
>
> Stepping a bit into the unspecified(?) behaviour of the frame request,
> you could submit your wl_buffer via wl_buffer_queue, and then issue the
> normal wl_surface.frame with a wl_surface.commit. I believe the current
> Weston implementation will trigger the frame callbacks even without a
> new buffer, as long as something causes a repaint. Or the other way
> around, I'm not sure which order is better for you.
Yes, I think I just need the frame callback to work with a 
wl_surface.commit for XWayland,
so that protocol proposition is ok for it.

>
>> Note: to be able to get the presentation time, when the X client
>> doesn't ask a specific presentation time, I'll have to use a queue
>> of length one with a requested time of 0. Your spec says it should
>> behave correctly.
> Would you be using the queue length one only so that you know which
> wl_buffer corresponds to the frame callback?
>
> If you had frame callbacks tied to a particular submission of a
> wl_buffer by some other means, would things be easier for you in
> xwayland? Would be able to queue more buffers than just one? If yes,
> would it benefit anything?
>
> If it was really useful to know when each wl_buffer enters a
> compositor repaint (just like what the frame request offers for
> wl_surfaces), we could think about adding such an event to
> wl_presentation_time interface (and maybe rename it accordingly).
>