>>
>>
>> -Original Message-
>> From: Hoosier, Matt
>> Sent: Monday, June 17, 2024 8:28 AM
>> To: Pekka Paalanen
>> Cc: 'Marius Vlad' ;
>> 'wayland-devel@lists.freedesktop.org' ;
>> 'Daniel Stone'
>> Subject: RE: Full-motion zero-copy screen capture in Weston
>>
>> > -Original Message-
>> > From: Pekka Paalanen
>> > Sent: Monday, June 17, 2024 3:28 AM
>> > To: Hoosier, Matt
>> > Cc: 's...@cmpwn.com' ; 'cont...@emersion.fr'
>> > ; 'Marius Vlad' ;
>> > 'wayland-devel@lists.freedesktop.org' > > de...@lists.freedesktop.org>; 'Daniel Stone'
>> > Subject: Re: Full-motion zero-copy screen capture in Weston
>> >
>> > On Fri, 14 Jun 2024 18:36:57 +
>> > "Hoosier, Matt" wrote:
>> >
>> > >
>> > > Hmm. As I read through the history of the original support for
>> > > writeback screenshots
>> > > (https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/458)
>> > > and get some initial results just trying to drive a steady stream of
>> > > writeback composition, I'm not sure this can work effectively.
>> > >
>> > > MR 458 has a fairly long discussion about the restriction that no
>> > > further commits must be made to the source CRTC or any of the other
>> > > KMS objects reachable on its graph, while a writeback composition
>> > > referencing that CRTC is still in flight.
>> > >
>> > > Daniel Vetter confirmed that interpretation.
>> > >
>> > > I think this means that unless you are extremely lucky that:
>> > >
>> > > (a) your hardware's writeback mechanism is synchronous with scanout,
>> > > and (b) the fence fd manages to fire and get dispatched immediately
>> > > upon scanout/writeback passing through the final scanline, and (c)
>> > > there's a really large vertical back porch
>> > >
>> > > , there will be no time left to enqueue a page flip for the
>> > > immediately succeeding vblank.
>> > >
>> > > Seems like this will almost always cut the frame achievable update
>> > > rate on the main connector in half.
>> > >
>> > > Did I misinterpret something in there? Early results look like the
>> > > kernel state machine gets confused (with VKMS anyway) if I queue up
>> > > two writeback operations in flight at the same time.
>> >
>> > Hi Matt,
>> >
>> > I really don't know. If hardware and drivers require that, and cannot
>> > stream at full refresh rate, then there is not much we can do.
>> >
>> > Not much, because I got one idea: Weston could repaint pre-emptively
>> > according to its own schedule, but KMS-flip only when the writeback
>> > situation allows. That should reduce the time needed between the
>> > writeback completion fence firing and the KMS deadline for the flip.
>> >
>> > VKMS might rely on the above rules, or maybe it's not fully developed,
>> > I'm not sure. You'd have to ask its developers. OTOH, if all hardware
>> > drivers need the above rules, then VKMS should too. Maybe it just
>> > needs to check and fail better.
>> >
>> >
>> > Thanks,
>> > pq
>>
>> Okay. I think maybe it makes sense to figure out who originally added this
>> kernel documentation and see whether the situation is really so grim.
>>
>> I'll see about writing something to whoever that was, perhaps with dri-devel
>> CC'ed.
>>
It turns out that the official interpretation of the documentation on the KMS
writeback connector's properties is that the framerate of the CRTC driving the
writeback operations will almost always be cut in half:
https://lists.freedesktop.org/archives/dri-devel/2024-June/458351.html
This isn't a hit that the use-cases I have in mind can afford, so I probably
won't continue trying to make an implementation of this Pipewire stream driven
by the writeback connector. Some of the responders to that thread over on
dri-devel are beginning to speculate about updated DRM uAPI properties that
would better support streaming of those writeback connectors whose hardware can
do it. Maybe I'll revisit if that discussion goes far and something new lands
in the framework.
Thanks to everybody for the advice along the way.
-Matt
