[RFC v.2] Extend wl_surface protocol

[Pekka Paalanen]

On Mon, 11 Nov 2013 18:26:45 +0100
Axel Davy <davy at clipper.ens.fr> wrote:

> 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.

That is not a reliable way to count the scanout cycles or screen
refreshes. None of the protocol existing or discussed here so far
offers that.

You might only estimate it by multiplying the presentation time
deltas with the refresh rate.

If you really want an accurate count, we have to write protocol to give
you exactly that. Should we add the refresh cycle count to the events
that also report the presentation time?

To be able to target one in the very near future, you could compute the
wanted presentation time from the framerate and the last realized
presentation time.

Another question is, is it worth to add stuff into the protocol just
for XWayland? There is still the option to run an X server on bare
hardware, if such features and accuracy are needed. Could XWayland do
with a bit less?

Are there applications that cannot work with timestamps, and need
refresh counts instead, and will be ported as native Wayland clients?

We once discussed about NVidia's GSYNC, which is something like an
on-demand or variable refresh rate display. We are not going to support
that in this proposal, but if we add refresh cycle counters, I think we
make supporting that harder in the future.


Thanks,
pq

> >> 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
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel