Pekka Paalanen <[email protected]> 于2019年7月24日周三 下午8:07写道： > > On Wed, 24 Jul 2019 14:02:43 +1200 > Barry Song <[email protected]> wrote: > > > Hi Esaki, > > > > Esaki Tomohito <[email protected]> 于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()? > > > Thanks, > pq -barry _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
