[RFC 1/1] Add color manager calibration protocol v1
Pekka Paalanen
ppaalanen at gmail.com
Tue Apr 16 12:35:45 UTC 2019
On Tue, 16 Apr 2019 13:14:58 +0200
Erwin Burema <e.burema at gmail.com> wrote:
> 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)
Hi,
the Wayland presentation-time extension is much better for latency
measurements as it delivers a flip timestamp hopefully from the
hardware. You can trivially compute the delay from client update to
hardware flip, and with a measurement device you can measure from flip
to light if you can synchronise the clocks.
But to use that you need a wl_surface.
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190416/adc05050/attachment.sig>
More information about the wayland-devel
mailing list