-
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
Loading