[argyllcms] Re: CGGetDisplayTransferByTable number of entries mismatches screen depth
From: Graeme Gill <graeme@xxxxxxxxxxxxx>
To: argyllcms@xxxxxxxxxxxxx
Date: Tue, 31 Oct 2006 17:28:57 +1100
Michael Grigoriev wrote:
I tracked the problem down to the following line in spectro/dispwin.c:
if (nent != (1 << p->pdepth)) {
on my system nent is 256, but p->pdepth is only 6.
Seems like a bit of a problem then. I'm not sure how
such sytems typically work, but it makes no sense that
the RAMDAC doesn't match the screen depth, after all,
each pixel value indexes into the RAMDAC. Are there
really 256 entries, or is XF86VidModeGetGammaRampSize()
confused ? If there really is 256 entries, then you need
to figure out how pixel values index into it. Do they
index into the first 64 locations ? Do they index into
every fourth location ? If every fourth, starting at
0 ? 1 ? 2 3 ?
If it is the first (that is it only using the first 64
entries), then you could try setting nent to (1 << pdepth),
and see if it works, but I'm not sure how carefully I allowed
for non 8 bit per component color depths in the rest of the
code.
I think this is because radeon drivers don't support 32 bit mode, but use 24
bit mode instead:
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 6 bits
Is this 24 bits then, with a 6 bit alpha mask (ie. 6/6/6/6 ?)
Also, if I switch to 16 bit mode, it might work, but will a profile
generated in such way be accurate when I switch back to 24 bit mode?
I really have no expectation that someone would want to color profile
a system, if they're not running it in a quality mode. 6 bits per component
really isn't a quality mode, 8 bits is regarded as barely adequate (but
all that is possible on most systems). 5/5/5 is going to be worse,
and it's not coded to cope with 5/6/5. Are you sure you can't turn the alpha
plane off, and run 8/8/8 in 24 bits ?
