On Monday, April 15, 2019 9:30 PM, Sebastian Wick <[email protected]> wrote: > On 2019-04-14 12:57, Erwin Burema wrote: > > Without a way to calibrate/profile screens an color management > > protocol looses a lot of its value. So to add this missing feature I > > wrote the following protocol. > > > > The idea is that the calibration/profiling SW only sets the RGB > > triplet and then the compositor is responsible to draw a rectanglular > > region on the selected output screen, since not all calibration tools > > will be at the center of the screen a user should be able to modify > > the placement of this rectanglular region. Unless specified the > > monitor profile (if any) should not be applied but the GPU curve > > should, currently to set a new curve the calibration tool should > > generate a new ICC profile with the wanted curve in the VCGT tag (I am > > not sure if this is the best option but would make the most universal > > one). In the end after profiling the last uploaded ICC could then be > > saved (although a compositor is not required to honor the request in > > that case it should send the not saved error). If the compositor > > doesn't save or the connection with this protocol is broken the > > compositor should restore previous settings. > > > > Currently no support to calibrate HDR screens since this will require > > direct access (no tonemapping or color correction should happen in the > > screen, with the potential exception if it is possible to upload > > custom LUTs to the screen), this will require something like the > > FREESYN2_GAMMA22 display mode as described here: > > https://gpuopen.com/using-amd-freesync-2-hdr-color-spaces/ if this is > > not available a HDR screen should be treated as if it is a rec2020+PQ > > or HLG since it will do its own compositing+color managing (which > > might or might not be correct) > > > > Erwin Burema (1): > > Add color manager calibration protocol v1 > > > > .../cm_wayland_calibration.xml | 106 ++++++++++++++++++ > > 1 file changed, 106 insertions(+) > > create mode 100644 > > unstable/color-manager-calibration/cm_wayland_calibration.xml > > The requirement to let the user position the patch makes me think that > using a normal surface in a special mode makes more sense.
This makes sense to me as well. Is there a guarantee that the surface is always a single solid color? > Maybe something like this would work: > > <?xml version="1.0" encoding="UTF-8"?> > <protocol name="color_measure_unstable_v1"> > > <description summary="color calibration and profiling"> > </description> > > <interface name="zwp_color_measure_v1" version="1"> > <description summary=""> > </description> > > <enum name="measure_mode"> > <description summary=""> > </description> > <entry name="standard" value="0" summary=""/> > <entry name="passthrough" value="1" summary=""/> > </enum> > > <request name="get_color_measurement_surface"> > <description summary=""> > </description> > <arg name="id" type="new_id" > interface="zwp_color_measure_surface_v1"/> > <arg name="surface" type="object" interface="wl_surface"/> > <arg name="output" type="object" interface="wl_output"/> > <arg name="mode" type="uint" enum="measure_mode" > interface="wl_output"/> Typo: not a wl_output. > </request> > > <request name="destroy" type="destructor"> > <description summary="destroy the color measure"> > </description> > </request> > </interface> > > <interface name="zwp_color_measure_surface_v1" version="1"> > <description summary=""> > The underlying surface has a state which indicates if it is shown on > the > output without further manipulation. > > In particular if the surface is in the state valid with mode standard > the > compositor guarantees that only the color correction pipeline and no > "special" effects are applied to the surface. > > In the state valid with mode passthrough the color values of the > surface are > gauranteed to reach the output as is (e.g. no color correction and no > vcgt > LUT gets applied). > > If the state is invalid there is no guarantee how the color values are > transformed before reaching the output. > </description> > > <enum name="state"> > <description summary=""> > </description> > <entry name="valid" value="0" summary=""/> > <entry name="invalid" value="1" summary=""/> > </enum> > > <request name="sync"> > </request> What would this be for? > <event name="done"> > </event> > > <event name="state_changed"> > <arg name="state" type="uint" enum="state"/> > </event> > > <request name="destroy" type="destructor"> > <description summary="destroy the color measure surface"> > </description> > </request> > </interface> > > </protocol> > > > I'd imagine the client to do something like this: > > 1. create a zwp_color_measure_surface_v1 for the surface and the output > to measure in the passthrough mode > 2. tell the user to position the surface correctly and wait for the > state to be valid (for example in gnome shell the state would be > invalid when the surface is shown in expose or not shown on the > output > at all) > 3. calibrate by filling the surface and applying the "vcgt" in software > 4. profile > 5. if the state changes to invalid in between go to 2 > 6. create the ICC profile and load it to the compositor via colord > 7. destroy the interface, create a new one in the standard mode > 8. wait for the state to be valid (as before) > 9. measure the colors and check if the profile works as intended How would the client "measure"? > 10. if the state changes to invalid in between go to 8 > > _______________________________________________ > wayland-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
