Commits on Source (13)
-
Pekka Paalanen authored
This is a completely new screenshooting protocol designed to support: - color management testing by adding the "blending" source - KMS testing by adding the "writeback" source - output decorations testing by adding the "full_framebuffer" source - proper buffer size negotiation instead of guessing from wl_output - compositor chosen pixel format, primarily for "blending" source - proper indication of screenshot failure - dmabuf target buffers, linear only This new protocol should be good enough to publish as a Weston public extension. Hence install it. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
d0eca43b -
Pekka Paalanen authored
This implements the basics of the new screenshooting protocol. The actual pixel operations will be implemented separately in the renderers and DRM-backend. See the previous commit "protocol: new screenshooter protocol" for why. If DRM-backend needs more from weston_capture_task when it implements writeback screenshooting, it will be easy to add user_data or expose weston_capture_task::link for the backend to use. Those were not added yet because it is uncertain what is actually needed. The DRM-backend no-damage optimization requires special handling here as well. See also 7f1a113c . Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
3700c781 -
Pekka Paalanen authored
This will be useful for client code that wants to create a wl_shm buffer with a DRM format code. The test suite will be using this. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
c7f5de6d -
Pekka Paalanen authored
This services output capture tasks for the 'framebuffer' and 'blending' pixel sources. Just like the old screenshooting path, the 'framebuffer' pixel source is the hardware buffer, whether a shadow is used or not. This may not be the best for performance, but you do get the real framebuffer contents. Maybe it's rgb565, or even less. When the shadow buffer is used, I realized it is effectively the same as the intermediate blending buffer in GL-renderer when color management is used. Pixman-renderer does non-linear blending only, so the shadow buffer is in the blending space. The shadow buffer is also always 8 bpc regardless of the hardware framebuffer, so the read-back may be different from the hardware framebuffer. Read-back from the shadow is optimal for performance, but not what the hardware gets. 'full-framebuffer' source cannot yet be implemented, because backends do not tell Pixman-renderer about the margins where the wayland-backend blits the output decorations. The target "hardware" buffer handed to pixman-renderer does not allow accessing the decorations area. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
0c8c2c40 -
Pekka Paalanen authored
This services output capture tasks for the 'framebuffer' and 'full framebuffer' pixel sources. Both pixel sources come from the same source: the EGLSurface. The only difference is the area. The EGLSurface contains the borders used for output decorations, hence 'full framebuffer' is possible to capture. We use GL_ANGLE_pack_reverse_row_order extension to make glReadPixels return the image data in the layout we need for wl_shm buffers directly. Without the extension we have to flip manually. Another extension to the same effect is MESA_pack_invert, but this is not specified for GL ES. It also uses a different token value, so it cannot be directly substituted even if supported. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
f60c9cc1 -
Pekka Paalanen authored
Replicating the policy of the old screenshooting interface, allow all screenshot to anyone with the new interface as well when --debug is used. Looks like there was one stray trailing space in unrelated code that my editor deleted. Better this way. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
e40a7eae -
Pekka Paalanen authored
Instead of starting yet another hand-crafted pixel format mapping table, use the one we have. Following patches want to be able to create XRGB8888 buffers, and later even other formats. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
c93b18ea -
Pekka Paalanen authored
For exercising various code paths in the server side protocol implementation. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
e3046b12 -
Pekka Paalanen authored
Migrate the tst suite to using the new screenshooting protocol. This ensures the new protocol and implementation work, and removes a user of the old protocol so that the old protocol can be removed in the future. Now that the compositor chooses the pixel format, capture_screenshot_of_output() needs to convert to the expected format in the tests when necessary. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
849b87e2 -
Pekka Paalanen authored
This is necessary in order to convert clients/screenshot.c into the protocol. We authorize a client the same way as before: if the wl_client is the one we spawned, it's allowed. Allowing screenshots on --debug was authorized by an earlier patch in compositor/main.c. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
93a94e76 -
Pekka Paalanen authored
The functionality of this screenshooting helper client is kept exactly the same as before: if you have multiple outputs, some transformed, some scale, in any layout, this will create a "multi-image" where the framebuffer (the physical image) of each output is pasted into a row of images in the order the outputs were advertised thrugh wl_registry. Output transform or scale are not accounted for. If you have a monitor rotated sideways, the screenshot will have the image of that monitor reverse-sideways. Otherwise the client is almost completely re-written, so trying to read the diff is not that useful. The old screenshooting protocol is replaced with the new weston-output-capture protocol. This makes it unnecessary to listen for wl_output information (since we do not handle output transform or scale anyway). The buffer sizes and formats are dictated by the compositor, which also means we cannot hardcode the format. Hence, use Pixman for the blitting, in case it needs to do format conversion. It is good to get rid of hand-crafted pixel data manipulation code too. For that reason we also need a pixel format database to convert between DRM fourcc, wl_shm and Pixman codes. We link to libweston to borrow its database instead of inventing another partial copy of it. It's weird to use compositor library private API in a client, but better than the alternative. The original code had no tear-down code at all. Now, if everything succeeds, the program ends with no unfreed memory according to ASan. If something fails, it still YOLO's it (doesn't free stuff). That's how far my pedantry carried. I also did not bother taking output transform or scale into account, since the old code did not either. It would be nice to create a seamless image of the desktop with shots rotated and scaled to align, in the max scale over all outputs. Meh. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
949b2eb7 -
Pekka Paalanen authored
There are no internal users left for this protocol, they have been migrated to the new weston-output-capture protocol. There are no external users, because this protocol was private and never installed. Remove this dead code. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
17df553b -
Pekka Paalanen authored
Nothing in-tree uses this function, and its functionality has been replaced with the weston-output-capture protocol extension which is implemented in libweston core. Users of this function should migrate to weston_compositor_add_screenshot_authority() and replace custom screenshooting protocols with weston-output-capture.xml installed by libweston. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
fdaf4cf3
libweston/output-capture.c
0 → 100644
This diff is collapsed.
libweston/output-capture.h
0 → 100644
protocol/weston-output-capture.xml
0 → 100644
protocol/weston-screenshooter.xml
deleted
100644 → 0