[PATCH 1/3] Skip xf86HandleColormaps() at color depth 30.

[Mario Kleiner]

On 12/27/2017 12:56 PM, Michel Dänzer wrote:
> On 2017-12-23 07:07 AM, Mario Kleiner wrote:
>> The hardware gamma luts get bypassed at color
>> depth 30 anyway, so skip their setup.
>>
>> Also skip drmmode_crtc_gamma_set() for a screen
>> with depth 30.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
>> ---
>>   src/drmmode_display.c | 10 ++++++++--
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>> index 7ad3235..e5f9dbe 100644
>> --- a/src/drmmode_display.c
>> +++ b/src/drmmode_display.c
>> @@ -1275,6 +1275,10 @@ drmmode_crtc_gamma_set(xf86CrtcPtr crtc, uint16_t *red, uint16_t *green,
>>   	RADEONInfoPtr info = RADEONPTR(scrn);
>>   	int i;
>>   
>> +	/* Hw gamma lut's are bypassed at color depth 30 */
>> +	if (scrn->depth == 30)
>> +		return;
> 
> It's better to set xf86CrtcFuncsRec::gamma_set = NULL in this case, to
> prevent the X server from wasting work calculating gamma tables that
> will never be used.

I looked at that, but as far as i understand, wouldn't NULL'ing that 
entry affect all active X-Screens, not only the depth 30 ones, as each 
screen only references the same shared static struct with function 
pointers in the driver? At least for the use cases of many of "my" 
users, two separate x-screens, with ZaphodHeads and different color 
depth wouldn't be an unexpected setup.

Or maybe i just overlook something (not with my code/test-machine atm.)?
-mario