[PATCH 0/3] xrandr: fix misc --gamma bugs

[Andy Ritger]

As I understand it: the gamma-correction tables configured through
XRR[GS]etCrtcGamma store 16:16:16 X Colors.  An X Color has some number
of significant bits, stored in the MSBs of the X Color (reported
in Visual::bits_per_rgb, though the gamma-correction tables are
visual-independent).  The significant bits of the X Color dictate the
size of the gamma-correction table (XRRGetCrtcGammaSize() == 2^sigbits).

PATCH 1/3 corrects xrandr to do gamma *correction* (i.e., 1/gamma)
PATCH 2/3 removes an assumption that XRRGetCrtcGammaSize() == 256.
PATCH 3/3 adjusts gamma-correction computation to produce results in
    the range [0,2^sigbits) << (16 - sigbits).

I found these links helpful:
http://www.poynton.com/PDFs/TIDV/Gamma.pdf (Gamma in computer graphics, page 17)
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86cmap.c:ComputeGamma()

If you compare against the code in xf86cmap.c, note that
CMapScreenPtr::gamma[] is stored in the range [0,2^sigbits), and is
* converted from [0,65536) in ComputeGammaRamp()
* converted to [0,65536) in xf86GetGammaRamp()


Questions:

* PATCH 1 changes long standing behavior in xrandr(1).  While the patch 
  makes the semantics consistent with xgamma(1) and xorg.conf options, 
  maybe it would be better to keep the existing behavior and just document
  that behavior in the man page and --help?

* hw/xfree86/common/xf86cmap.c:xf86GetGammaRamp() makes up some values 
  to pack in the low bits of each component of each entry.  Only the MSBs
  should matter for hardware, but for consistency maybe xrandr(1) should 
  do something similar to populate the low bits?

Thanks,
- Andy



Andy Ritger (3):
  xrandr: use 1/gamma to compute gamma-correction
  xrandr: fix gamma == 1.0 && sigbits != 8
  xrandr: compute gamma-correction in [0,2^sigbits)

 xrandr.c |   52 +++++++++++++++++++++++++++++++++++++---------------
 1 files changed, 37 insertions(+), 15 deletions(-)

-- 
1.7.2.5