New version with smaller changes and clarifications and a new feature: * Introduce enum color_space_name to optionally name a color space object when the color space is well-known. Even if the color space object is describing one of the well-known color spaces it may not be tagged with the name and is purely an augmentation. The reasoning here is that figuring out if a profile describes a well-known color space is not trivial. This might be useful for HDR displays. * tighten the requirements on the accepted ICC profiles * disallow creating multiple zwp_color_management_output/surface objects from the same wl_output/wl_surface * zwp_color_management_output/surface become inert when their associated wl_output/wl_surface is destroyed * rename zwp_* to zwp_*_v1 * reorder rendering intents * add relative+bpc intent * allow to reset the color space attached to a surface by passing NULL in set_color_space and comming the state * clearify that the color space attached to a surface is reset when the associated zwp_color_management_surface is destroyed * getting the color space information event now requires sending the get_information request * restrict the client usage of the ICC fd to mmaping with MAP_PRIVATE * clearify that the ICC fd send in color_space.information may not be the same as the one used to create the object
There is two FIXMEs left for which I would also appreciate feedback * How exactly should the restriction on the ICC fd look like that gets send from the client to the compositor? In my Weston POC I use read and make sure the fd is O_NONBLOCK and construct a new independent fd representing the color space so the client fd can be released by the compositor. Mmaping would require handling SIGBUS again. Not sure what's better. * Should we actually mandate un-premultiplied data? I have to look at KMS plane blending, the graphics ROPs and custom blend shaders to figure out what they all do. The focus for the next version is probably going to be HDR. So I'd also appreciate if we can come to a concensus on the overall design of HDR support. I'm also still looking for people who want to become co-maintainers of the protocol. Previous version: https://lists.freedesktop.org/archives/wayland-devel/2019-March/040319.html Weston POC implementation: https://gitlab.freedesktop.org/swick/weston/commits/color-management-backend Sebastian Wick (1): unstable: add color management protocol Makefile.am | 1 + unstable/color-management/README | 4 + .../color-management-unstable-v1.xml | 300 ++++++++++++++++++ 3 files changed, 305 insertions(+) create mode 100644 unstable/color-management/README create mode 100644 unstable/color-management/color-management-unstable-v1.xml -- 2.23.0 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
