[RFC 1/1] Add color manager calibration protocol v1

[Erwin Burema]

On Tue, 16 Apr 2019 at 12:51, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Sun, 14 Apr 2019 12:57:48 +0200
> Erwin Burema <e.burema at gmail.com> wrote:
>
> > ---
> >  .../cm_wayland_calibration.xml                | 106 ++++++++++++++++++
> >  1 file changed, 106 insertions(+)
> >  create mode 100644 unstable/color-manager-calibration/cm_wayland_calibration.xml
> >
> > diff --git a/unstable/color-manager-calibration/cm_wayland_calibration.xml b/unstable/color-manager-calibration/cm_wayland_calibration.xml
> > new file mode 100644
> > index 0000000..be9bb4b
> > --- /dev/null
> > +++ b/unstable/color-manager-calibration/cm_wayland_calibration.xml
>
> > +  <interface name="zcm_output_cal_v1" version="1">
> > +    <description summary="Main calibration profiling interface">
> > +      With this interface an calibration/profiling application can send needed colors to the display, the compositors is responsible for placing the colors (with the help of the user since we can't know the physical location of the measurement device)
> > +    </description>
> > +
> > +    <enum name="bitdepth">
> > +      <entry name="8bit" value="0" summary="8 Bit display" />
> > +      <entry name="10bit" value="1" summary="10 Bit display" />
> > +      <entry name="12bit" value="2" summary="12 Bit display" />
> > +      <entry name="14bit" value="3" summary="14 Bit display" />
> > +    </enum>
> > +
> > +    <event name="display_depth">
> > +      <description summary="Event send to inform application of display depth"/>
> > +      <arg name="depth" type="uint" enum="bitdepth" />
> > +    </event>
> > +
> > +    <request name="set_color">
> > +      <description summary="Request a color to be set to an area within output">
> > +        This request is semd to set a specific color to an output, this color needs to be pushed to the screen as directly as possible (unless the bool use_profile is true and with the exception of the HW LUT of the graphics card or display itself) and preferably on top of everything else. The compositor is responsible to place the output area inside the output.
> > +      </description>
> > +      <arg name="red" type="uint" summary="Red component of color, only least significant n bit are used where n depends on bitdepth of display" />
> > +      <arg name="green" type="uint" summary="Green component of color, only least significant n bit are used where n depends on bitdepth of display" />
> > +      <arg name="blue" type="uint" summary="Blue component of color, only least significant n bit are used where n depends on bitdepth of display" />
> > +      <arg name="use_profile" type="bool" allow-null="true" summary="If profile should be applied, used to verify profile. If not set assume false"/>
> > +    </request>
>
> Hi,
>
> would you not need a corresponding event to know the compositor has
> shown the requested color?
>
> It could be as simple as a new_id argument with wl_callback interface.
>

Good point, will add that in the next version. Might also be an
interesting way to measure GPU/display latency (time from callback
received to actual change observed on screen although not sure how
accurate that will be)

> wl_display.sync would not do, because a compositor does not repaint as
> part of a request handler. Repaints happen asynchronously.
>
> You might also need an event for "user cancelled the operation",
> implying that what is on the screen is no longer what the client wanted
> and the client should start from scratch if it wants to continue.
>

Yes will need to add that as well

>
> Thanks,
> pq