Pekka Paalanen <ppaala...@gmail.com> 于2019年7月26日周五 上午3:30写道： > > 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.
well. i'd like to continue in this way. another possible solution is using a way like ffpmeg kmsgrab: https://www.ffmpeg.org/ffmpeg-devices.html#Options-10 it is using get the DRM framebuffer outside the weston: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/kmsgrab.c by code like: static int kmsgrab_read_packet(AVFormatContext *avctx, AVPacket *pkt) { ... plane = drmModeGetPlane(ctx->hwctx->fd, ctx->plane_id); ... fb = drmModeGetFB(ctx->hwctx->fd, plane->fb_id); ... err = drmPrimeHandleToFD(ctx->hwctx->fd, fb->handle, O_RDONLY, &fd); ... desc = av_mallocz(sizeof(*desc)); ... } do you think if kmsgrab will have some serial synchronization or performance issues? > > > Thanks, > pq -barry _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
