Module parameters to override color management/dithering.

[Mario Kleiner]

Hi,

so these two patches add i915 module parameters to globally override
how the driver handles dithering and gamma/csc conversion.

They serve two purposes: First as debug aid and "airbag" for working
around potential precision problems in getting pixels from rendering
to the display outputs. This mostly for applications that critically
depend on getting pixels untampered from the fb to the outputs, e.g.,
scientific neuro-science/vision research/medical applications. Having
the ability to bypass parts of the pipeline can help a lot in debugging
such problems on remote user machines, and to allow such users to
work around the problems until proper fixes are made. I expect this
to become especially useful when dealing with all the Wayland compositor
implementations, which so far don't have a standardized application/user
controllable equivalent to RandR protocol / xrandr tools.

The second, short-term purpose is to enable true 10 bit output from
rendering, so people with urgent 10 bit precision needs can benefit
from the Mesa patches i started working on for i965 (rev 1 on the
mailing-list, rev 2 to come soon).

I realize the merge window for Linux 4.14 is almost over, but wanted
to ask if it would be possible to slip these patches into 4.14 if
they aren't considered too intrusive?

These are tested on Ironlake, Ivybridge, Haswell and Skylake, also
with a photometer to see what actually comes out of the display for
different settings.

The bigger plan is to enhance the gamma table support, so we could
also use > 8 bit precision gamma tables on Ironlake and later, both
for the legacy gamma ioctl and the new color mgmt. method. I do have
proof of concept patches for using the 1024->10 precision luts on
Ironlake and later. Tweaking the gamma tables i upload via RandR and
measuring with photometer showed my poc patches work. However, as
described in the 2nd patch, at least the tested legacy luts and
1024->10 precision luts seem to get mostly ignored/bypassed in the hw
when a XR30 fb is attached to the primary plane. Not sure if some setup
is missing, or if this is some hardware quirk? Couldn't find anything
in the PRM's so far.

What i'd actually like to implement for Ironlake+ instead of the
1024->10 bit luts is this:

If in dual-gamma lut mode, or if the input gamma table is not
monotonically increasing, do what is done now (legacy luts for legacy
gamma ioctl, split 512->10 big luts for new path).

If only a single gamma lut is requested (DEGAMMA_LUT == 0), and the
provided input lut is monotonically increasing, switch to the linearly
interpolated 512->12 bit lut instead, which exists on Ironlake+. Also
for the legacy gamma ioctl, so existing apps can benefit from the
higher precision. This would enable > 8 bit framebuffers to be output
properly and with high quality gamma correction.

Thanks,
-mario