Pekka Paalanen <ppaala...@gmail.com> 于2019年7月27日周六 下午8:10写道： > > On Fri, 26 Jul 2019 13:31:47 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Pekka Paalanen <ppaala...@gmail.com> 于2019年7月26日周五 上午3:30写道： > > > > 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? > > Hi, > > first, I am surprised to hear kmsgrab exists or can even work > at all. I guess the superuser is allowed to do all kinds of nasty > things. > > I think synchronization issues are unavoidable with kmsgrab. > > There is no way to know when Weston flips the FB, right? That means > you will be polling and randomly sampling the KMS state, so you > don't know what frames you'll be getting. I imagine that causes > jerky animation. Or you have to be polling very frequently to > observe FB changes. > > Weston will be using hardware planes. This means that it is not > enough to sample the primary plane, you have to sample all planes > and the full KMS state including the active areas of each FB. Then > you get to composite those various FBs together before you have a > single picture. > > You will probably also have problems with buffer content > synchronization: you may be reading the content while Weston is > already flipped to another FB and is half-way repainting the buffer > you are reading. This will cause artifacts in the image. > > So I cannot really recommend that approach at all, based on a > theoretical analysis.
as said in the other email, independent clone mode has been resolved by hacking weston damage tracking system. i am looking for a solution to support remote screen mirroring. the current idea is making the pipewire display work as a duplicated display which shows the same content with the physical display. this will probably resolve the screen mirror issue. would you like to think it is the right direction? > > > Thanks, > pq -barry _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
