Pekka Paalanen <ppaala...@gmail.com> 于2019年8月3日周六 上午12:06写道: > > On Wed, 31 Jul 2019 10:20:22 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > 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? > > Hi, > > yes, that can work, and it is nicely orthogonal in implementation to > the real outputs. > > It will have the same problem as the remoting plugin already worked > around with the concept of DRM virtual outputs. Libweston currently > supports only one backend at a time, but we would really need to able to > have multiple input and output backends in use at the same time to > improve the internal architecture and make remoting independent of the > actual backends. Hi Pekka,
it seems the memcpy(spa_buffer->datas[0].data, ptr, size) is a big problem to limit the usage of pipewire. i am wondering if there is a zero-copy solution to share the drm_fb to pipewiresrc then to encoder? static void pipewire_output_handle_frame(struct pipewire_output *output, int fd, int stride, struct drm_fb *drm_buffer) { ... if (pw_stream_get_state(output->stream, NULL) != PW_STREAM_STATE_STREAMING) goto out; buffer = pw_stream_dequeue_buffer(output->stream); if (!buffer) { weston_log("Failed to dequeue a pipewire buffer\n"); goto out; } spa_buffer = buffer->buffer; ... ptr = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0); memcpy(spa_buffer->datas[0].data, ptr, size); munmap(ptr, size); ... pw_stream_queue_buffer(output->stream, buffer); } > > An alternative approach would be to hook up to a real existing output > and copy frames from it when the remote video pipeline is ready to > consume them. That could also side-step the issue of the video encoder > wanting to keep a hold of too many old frames for reference, that would > otherwise cause gbm_surface to run out of buffers. > > The screen-share plugin does the copying already through glReadPixels > from an existing output. That would be fine for a software video > encoder, but sub-optimal for a hardware video encoder. > > FWIW, I wrote down some ramblings here: > https://gitlab.freedesktop.org/wayland/weston/issues/268 > > > Thanks, > pq -barry _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel