Skip to content

Protocol extension for display profiling and verification

Color management protocol extension wayland/wayland-protocols!14 is necessary but not sufficient for measuring physical monitor response. We need another protocol extension for the window management aspect of profiling. Profiling requires a window to show a color or image sample that will be measured by a hardware device.

The sample surface role has the following requirements:

  • guaranteed to be unoccluded, therefore shown on top, screensaver etc. inhibited
  • no compositor color effects (translucency, desaturation, night light, etc.)
  • assigned to a specific monitor, in practice to a specific wl_output
  • shown in a predictable position on the wl_output, but also end user movable somehow, and the position recallable by the client (could be simply a position offset on an output set by the client)
  • optionally show on top of even cursors
  • optional exclusive mode, where everything else on the wl_output is painted pure black
  • cancelable by the compositor (end user) and not abusable
  • override possible existing VCGT?

The extension does not need to care about:

  • surface content delivery; the usual ways of putting content into a wl_surface suffice
  • color space definitions or color bypass; the color management extension has all the necessary tools
  • signaling presentation; presentation-time can tell when the content is up
  • input; input events delivered through the usual interfaces if necessary
  • measurements or measurement devices; the client shall handle them on its own

Possible user story for profiling:

  1. End user launches a profiling tool (the client).
  2. The client creates any normal windows it needs to, asks the end user which output to profile etc.
  3. The client creates a surface with the sampling role and attempts to display it (not top-of-cursors, not exclusive).
  4. The compositor checks if the sampling surface is allowed to be shown (presumably yes), and shows it at the client indicated position on the given output.
  5. The client asks the end user to move the sampling window to a suitable position and size, if necessary. The end user does so, and indicates the profiling may begin.
  6. The client switches top-of-cursors on, and if wanted, exclusive mode on. (Without exclusive mode the client could show progress in a normal window, but also stray light might interfere with measurements.)
  7. The client takes the wl_output's image description and applies it on the sample surface with any colorimetric rendering intent. This bypasses any color conversions in the compositor.
  8. For each color code to be measured, the client commits an image on the sample surface, waits for presentation-time to indicate it has been displayed and also fully scanned out, and drives the measurement device to take a measurement.
  9. The client destroys the sample surface, and saves the profile.
  10. The end user configures the compositor to use the new profile.

Next, there could be another user story for verifying that the compositor performs color management correctly. It is practically the same as above, except instead of using the output's image description the client will use its own image description with either of the colorimetric rendering intents, and instead of creating a profile it verifies the resulting colorimetry matches the expected one.

Prior art:

Edited by Pekka Paalanen