On Thu, 25 Jul 2019 13:06:02 +1200 Barry Song <21cn...@gmail.com> wrote:
> Pekka Paalanen <ppaala...@gmail.com> 于2019年7月24日周三 下午8:07写道： > > > > On Wed, 24 Jul 2019 14:02:43 +1200 > > Barry Song <21cn...@gmail.com> wrote: > > > > > Hi Esaki, > > > > > > Esaki Tomohito <e...@igel.co.jp> 于2019年7月24日周三 下午1:44写道： > > > > > > > > Hello Barry, > > > > > > > > The remoting plugin doesn't support mirroring. > > > > If the recently merged pipewire plugin doesn't support mirroring, > > > > I think that weston doesn't support remote mirroring. > > > > > > > > > > thanks for your reply. it seems pipewire is a good plugin which can > > > move gstreamer pipeline out of weston. so it makes remote-plugin more > > > flexible. > > > but it is probably another extended screen rather than mirroring. > > > > > > I am wondering if it is possible to make the "same-as" clone-mode > > > support remote screen as well: > > > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037946.html > > > > > > since remote screen has no real crtc, it should be able to simulate a > > > sharing-crtc scenerios which "same-as" clone-mode depends on? > > > > Hi, > > > > not the "same-as" directive specifically, because it is reserved > > for shared-CRTC cloning where the main feature is that the cloned > > outputs' timings are guaranteed to be synchronized in hardware. > > > > We need a new directive, "clone-of", or whatever, to denote > > independent outputs (meaning independent timings, pixel format, > > etc.) scanning out the same area of the desktop. > > > > The reason why that still has not been implemented is libweston's > > damage tracking framework. It needs to be re-designed, because > > currently it simply cannot have overlapping outputs - damage would > > be cleared too early when just the random first output repaints, > > leaving other overlapping outputs showing randomly old content. > > > > Another way could be to use the vaapi-recorder code paths and feed > > that video stream to a transmitter - or to pipewire, if the buffer > > reservation/release convetions allow (a real DRM output probably > > has only few buffers available, so the transmitter cannot keep a > > hold of very many at the same time). Another disadvantage is that > > the buffer domain, pixel format and modifier must be scanout-able, > > which may not be optimal or suitable for e.g. hardware video > > encoders. However, vaapi-recorder works, so it can obviously work > > at least on Intel. > > if vaapi-recorder is not available for an embedded system, do you > think if hacking libweston/screenshooter.c is an option? > i mean writing the frame to pipewire in screenshooter_frame_notify()? Hi, I don't think that would work too well, because eglSwapBuffers has not been called yet at that time, and using glReadPixels would hurt performance a lot. You don't need to use vaapi-recorder per se. You just hook up your sink exactly like vaapi-recorder does, and pay attention to synchronization. Thanks, pq
pgpOchHyioVtV.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
