On 11/11/2013, Pekka Paalanen wrote :
Hi Axel
On Fri, 08 Nov 2013 23:49:25 +0100
Axel Davy <[email protected]> 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).
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
