No target had yet implemented gammamap until I started re-doing the X target, so this went unnoticed:
The current giGetGammaMap assumes a 24-bit visual. IIRC it is possible to have gammamaps on 16-bit visuals -- in fact from my reading it is possible to have both a gammamap and a palette at the same time on some chips. Most of the problem can be fixed up by patching the default/color/gamma.c without changing the API, however, we have to decide and document the behavior on e.g. 5-6-5 visuals where one color has more gammamap entries than others. I think the reasonable behavior (using the r5g6b5 to illustrate) is for any values in the red or green color channels at indexes greater than 31 to be ignored when set and to be undefined on read. This prevents people from trouncing on values lower in the list while programming the higher depth channel. And, I would like to make some internal changes: I would like to add gammalen_r, gammalen_g, and gammalen_b to the visual structure to reduce code complexity in common cases by caching the count of the number of values present in each channel. (Any fancier pixelformats would not use any stubs and keep their state entirely in vis->priv). Also I'd like to add a hook to keep the gamma colors on in cases where readback is slow/impossible, since they shouldn't go on vis->palette. (Or, another option is to kick gamma_* out of the visual structure and put these and the new values in a new internal structure which would be kept in the target's private area and linked to a priv->gamma hook, such that all visuals need not carry all the gamma information around.) Finally a convenience macro would be added to tell the user what gamma capabilities are available: ggiGammaMax(ggi_visual_t vis, uint32 bitmeaning, int &maxread, int &maxwrite); This checks the number of gamma entries for a channel. In the case that only the gamma constant can be set (rather than explicit map values), the value returned in maxwrite will be -1. The use of a bitmeaning (e.g. GGI_BM_COLOR | GGI_BM_SUB_BLUE) is merely to avoid hardcoding "r", "g" and "b" into any more API functions. Comments? -- Brian
