On Thu, 30 May 2024 13:40:15 +0000 "Hoosier, Matt" <matt.hoos...@garmin.com> wrote:
> Okay, interesting thoughts on all of that. > > I'm not sure how far I'm going to get toward a complete overhaul of > the capture mechanism. Maybe it would be useful to know a couple > things about the current one (weston_output_capture_v1), so that I > don't commit mistakes that somebody already considered and guarded > against: > > * Why was it explicitly picked only for still shots? I can image that > it wouldn't have been a whole lot more work to design this API with a > bounce-buffering scheme rather than a setup/do-it-once/destroy model. > There was no need for streaming, as it was purely for the test suite. The test suite is very particular about when and how the shot is taken: it must be produced by the defined source, and it must be produced on the very next repaint of the output, exactly once. Did you mean a buffer pool (queueing/dequeueing) rather than bounce-buffering? Sure. > * Why was wl_shm explicitly picked for the buffer type? I was > thinking here that it would have worked equally well to specify that > the client must supply a linear-layout buffer manufactured through > zwp_linux_dmabuf. This would be eligible for direct targeting by the > GL renderer/KMS writeback, but also can be mapped with gbm_bo_map() > in the compositor's Pixman backend and/or a client who wants to map > it to the CPU upon delivery. Because the test suite specifically needs CPU access to the screenshot. There was no use yet for dmabuf, and GL-renderer was already doing glReadPixels() for screenshots. IOW, all the limitations are just "was not needed yet". Note, that re-using or extending the protocol extension weston_capture_v1 for streaming outputs for non-test-suite use cases may not be the best idea. If the interface needs to be a Wayland extension, then maybe something from the wlr extensions would suit better. OTOH, for e.g. Pipewire there would not be a Wayland extension used at all. The internal API (weston_output_capture) is very much geared for weston_capture_v1 only. The internal API might take improving rather than weston_capture_v1. Thanks, pq
pgpGdEI0WVF9N.pgp
Description: OpenPGP digital signature
