Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2017-03-23 Thread Michel Dänzer 
On 23/03/17 07:59 PM, Hans de Goede wrote:
> On 20-09-16 03:58, Michel Dänzer wrote:
>> On 17/09/16 07:00 PM, Hans De Goede wrote:
>>> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma
>>> code")
>>> dropped the providing of a pScrn->ChangeGamma callback from the
>>> xf86RandR12
>>> code. Leaving pScrn->ChangeGamma NULL in most cases.
>>>
>>> This triggers the BadImplementation error in xf86ChangeGamma() :
>>>
>>> if (pScrn->ChangeGamma)
>>> return (*pScrn->ChangeGamma) (pScrn, gamma);
>>>
>>> return BadImplementation;
>>>
>>> Which causes X-apps using XF86VidModeSetGamma to crash with a
>>> X protocol error.
>>>
>>> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
>>> helper removed by the commit and adjusting it to work with the new
>>> combined palette / gamma code.
>>>
>>> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma
>>> code")
>>
>> I suspect you really want to fix the modesetting driver to call
>> xf86HandleColormaps, so it can actually benefit from that change and
>> e.g. gamma sliders in games start working.
> 
> Ok, so going through my TODO list I started looking at this,
> amdgpu does:
> 
> if (xf86_config->num_crtc) {
> xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO,
> AMDGPU_LOGLEVEL_DEBUG,
>"Initializing kms color map\n");
> if (!miCreateDefColormap(pScreen))
> return FALSE;
> /* all amdgpus support 10 bit CLUTs */
> if (!xf86HandleColormaps(pScreen, 256, 10,
>  NULL, NULL,
>  CMAP_PALETTED_TRUECOLOR
>  | CMAP_RELOAD_ON_MODE_SWITCH))
> return FALSE;
> }
> 
> Which seems like it should mostly work for modesetting to,
> except for the all "amdgpus support 10 bit CLUTs" part,
> any ideas what to put there for modesetting, or how to
> query this from the kernel driver ?

I'm not sure either, but hardcoding 10 might be fine for modesetting as
well. The table for mapping from the post-colormap values to the final
values will be larger than necessary for hardware which only really
supports 8 bits or even less, but other than that I think the behaviour
should be mostly the same.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2017-03-23 Thread Hans de Goede 

Hi,

On 20-09-16 03:58, Michel Dänzer wrote:

On 17/09/16 07:00 PM, Hans De Goede wrote:

Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.

This triggers the BadImplementation error in xf86ChangeGamma() :

if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);

return BadImplementation;

Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.

This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.

Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")


I suspect you really want to fix the modesetting driver to call
xf86HandleColormaps, so it can actually benefit from that change and
e.g. gamma sliders in games start working.


Ok, so going through my TODO list I started looking at this,
amdgpu does:

if (xf86_config->num_crtc) {
xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, AMDGPU_LOGLEVEL_DEBUG,
   "Initializing kms color map\n");
if (!miCreateDefColormap(pScreen))
return FALSE;
/* all amdgpus support 10 bit CLUTs */
if (!xf86HandleColormaps(pScreen, 256, 10,
 NULL, NULL,
 CMAP_PALETTED_TRUECOLOR
 | CMAP_RELOAD_ON_MODE_SWITCH))
return FALSE;
}

Which seems like it should mostly work for modesetting to,
except for the all "amdgpus support 10 bit CLUTs" part,
any ideas what to put there for modesetting, or how to
query this from the kernel driver ?

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-27 Thread Hans de Goede 

Hi,

On 25-09-16 09:51, Michel Dänzer wrote:

On 23/09/16 07:48 PM, Hans de Goede wrote:

On 09/23/2016 11:13 AM, Michel Dänzer wrote:

On 23/09/16 03:46 PM, Hans de Goede wrote:


Since this is a fallback which ideally should never get used (all
drivers should call xf86HandleColormaps) I believe it is not worth
the time to implement your (admittedly better) fallback suggestion.


Fine with me, but please at least change the comment to be more accurate
and clearer.


OK, the comment now reads:
/*
 * Compatibility pScrn->ChangeGamma provider for ddx drivers which do
not call
 * xf86HandleColormaps(). Note such drivers really should be fixed to call
 * xf86HandleColormaps() as this clobbers any per-crtc setup.
 */


As I mentioned before, "clobbers any per-CRTC setup" isn't accurate.
Only the gamma ramp of the CRTC assigned to the RandR compatibility
output is clobbered.


Ah I missed you had provided an improved comment and rolled my own.

I've fixed this in my personal tree now, and the fixed version
will be part of the updated pull-req for 1.19 I'm preparing.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-25 Thread Michel Dänzer 
On 23/09/16 07:48 PM, Hans de Goede wrote:
> On 09/23/2016 11:13 AM, Michel Dänzer wrote:
>> On 23/09/16 03:46 PM, Hans de Goede wrote:
>>>
>>> Since this is a fallback which ideally should never get used (all
>>> drivers should call xf86HandleColormaps) I believe it is not worth
>>> the time to implement your (admittedly better) fallback suggestion.
>>
>> Fine with me, but please at least change the comment to be more accurate
>> and clearer.
> 
> OK, the comment now reads:
> /*
>  * Compatibility pScrn->ChangeGamma provider for ddx drivers which do
> not call
>  * xf86HandleColormaps(). Note such drivers really should be fixed to call
>  * xf86HandleColormaps() as this clobbers any per-crtc setup.
>  */

As I mentioned before, "clobbers any per-CRTC setup" isn't accurate.
Only the gamma ramp of the CRTC assigned to the RandR compatibility
output is clobbered.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-23 Thread Hans de Goede 

Hi,

On 09/23/2016 11:13 AM, Michel Dänzer wrote:

On 23/09/16 03:46 PM, Hans de Goede wrote:

On 09/20/2016 04:58 AM, Michel Dänzer wrote:


If there are other drivers which can't call xf86HandleColormaps for some
reason, a better solution would be to combine the per-screen gamma set
via pScrn->ChangeGamma with the per-CRTC gamma set via
xf86RandR12CrtcSetGamma.


Hmm, I understand what you're getting at. The problem is not if drivers
can or cannot call xf86HandleColormaps though. The problem is that there
likely will be drivers which do not (even though they would be perfectly
fine doing so).

Although I agree that your proposal is an improvement, I would prefer to
just move forward with this patch-set to provide a fall-back to ensure
that we do not have any regressions caused by pScrn->ChangeGamma being
NULL.


Leaving it as NULL would probably flush out such drivers more quickly
though. :)



Since this is a fallback which ideally should never get used (all
drivers should call xf86HandleColormaps) I believe it is not worth
the time to implement your (admittedly better) fallback suggestion.


Fine with me, but please at least change the comment to be more accurate
and clearer.


OK, the comment now reads:
/*
 * Compatibility pScrn->ChangeGamma provider for ddx drivers which do not call
 * xf86HandleColormaps(). Note such drivers really should be fixed to call
 * xf86HandleColormaps() as this clobbers any per-crtc setup.
 */

REgards,

Hans

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-23 Thread Michel Dänzer 
On 23/09/16 03:46 PM, Hans de Goede wrote:
> On 09/20/2016 04:58 AM, Michel Dänzer wrote:
> 
>> If there are other drivers which can't call xf86HandleColormaps for some
>> reason, a better solution would be to combine the per-screen gamma set
>> via pScrn->ChangeGamma with the per-CRTC gamma set via
>> xf86RandR12CrtcSetGamma.
> 
> Hmm, I understand what you're getting at. The problem is not if drivers
> can or cannot call xf86HandleColormaps though. The problem is that there
> likely will be drivers which do not (even though they would be perfectly
> fine doing so).
> 
> Although I agree that your proposal is an improvement, I would prefer to
> just move forward with this patch-set to provide a fall-back to ensure
> that we do not have any regressions caused by pScrn->ChangeGamma being
> NULL.

Leaving it as NULL would probably flush out such drivers more quickly
though. :)


> Since this is a fallback which ideally should never get used (all
> drivers should call xf86HandleColormaps) I believe it is not worth
> the time to implement your (admittedly better) fallback suggestion.

Fine with me, but please at least change the comment to be more accurate
and clearer.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-23 Thread Hans de Goede 

Hi,

On 09/20/2016 04:58 AM, Michel Dänzer wrote:

On 17/09/16 07:00 PM, Hans De Goede wrote:

Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.

This triggers the BadImplementation error in xf86ChangeGamma() :

if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);

return BadImplementation;

Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.

This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.

Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")


I suspect you really want to fix the modesetting driver to call
xf86HandleColormaps, so it can actually benefit from that change and
e.g. gamma sliders in games start working.


Ah, good one. I'll take a look at this.



If there are other drivers which can't call xf86HandleColormaps for some
reason, a better solution would be to combine the per-screen gamma set
via pScrn->ChangeGamma with the per-CRTC gamma set via
xf86RandR12CrtcSetGamma.


Hmm, I understand what you're getting at. The problem is not if drivers
can or cannot call xf86HandleColormaps though. The problem is that there
likely will be drivers which do not (even though they would be perfectly
fine doing so).

Although I agree that your proposal is an improvement, I would prefer to
just move forward with this patch-set to provide a fall-back to ensure
that we do not have any regressions caused by pScrn->ChangeGamma being
NULL.

Since this is a fallback which ideally should never get used (all
drivers should call xf86HandleColormaps) I believe it is not worth
the time to implement your (admittedly better) fallback suggestion.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [xserver, 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-19 Thread Michel Dänzer 
On 17/09/16 07:00 PM, Hans De Goede wrote:
> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
> dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
> code. Leaving pScrn->ChangeGamma NULL in most cases.
> 
> This triggers the BadImplementation error in xf86ChangeGamma() :
> 
> if (pScrn->ChangeGamma)
> return (*pScrn->ChangeGamma) (pScrn, gamma);
> 
> return BadImplementation;
> 
> Which causes X-apps using XF86VidModeSetGamma to crash with a
> X protocol error.
> 
> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
> helper removed by the commit and adjusting it to work with the new
> combined palette / gamma code.
> 
> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")

I suspect you really want to fix the modesetting driver to call
xf86HandleColormaps, so it can actually benefit from that change and
e.g. gamma sliders in games start working.


If there are other drivers which can't call xf86HandleColormaps for some
reason, a better solution would be to combine the per-screen gamma set
via pScrn->ChangeGamma with the per-CRTC gamma set via
xf86RandR12CrtcSetGamma.


> +/*
> + * Compatibility with XF86VidMode's gamma changer.  This necessarily clobbers
> + * any per-crtc setup.  You asked for it...
> + */

At the very least though, this comment should be changed to something
along the lines of:

/* Fallback pScrn->ChangeGamma implementation for drivers which can't
 * call xf86HandleColormaps. This will clobber the per-CRTC gamma ramp
 * of the CRTC assigned to the RandR compatibility output.
 */


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-19 Thread Alex Deucher 
On Mon, Sep 19, 2016 at 11:31 AM, Alex Deucher  wrote:
> On Sat, Sep 17, 2016 at 6:00 AM, Hans de Goede  wrote:
>> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
>> dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
>> code. Leaving pScrn->ChangeGamma NULL in most cases.
>>
>> This triggers the BadImplementation error in xf86ChangeGamma() :
>>
>> if (pScrn->ChangeGamma)
>> return (*pScrn->ChangeGamma) (pScrn, gamma);
>>
>> return BadImplementation;
>>
>> Which causes X-apps using XF86VidModeSetGamma to crash with a
>> X protocol error.
>>
>> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
>> helper removed by the commit and adjusting it to work with the new
>> combined palette / gamma code.
>>
>> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
>> Signed-off-by: Hans de Goede 
>
> Not too familiar with the code in question, but it looks sane to me.

For the series:

> Reviewed-by: Alex Deucher 
>
>> ---
>>  hw/xfree86/modes/xf86RandR12.c | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
>> index 36767b3..7b3b97b 100644
>> --- a/hw/xfree86/modes/xf86RandR12.c
>> +++ b/hw/xfree86/modes/xf86RandR12.c
>> @@ -1916,6 +1916,34 @@ xf86RandR12LoadPalette(ScrnInfoPtr pScrn, int 
>> numColors, int *indices,
>>  }
>>  }
>>
>> +/*
>> + * Compatibility with XF86VidMode's gamma changer.  This necessarily 
>> clobbers
>> + * any per-crtc setup.  You asked for it...
>> + */
>> +
>> +static int
>> +xf86RandR12ChangeGamma(ScrnInfoPtr pScrn, Gamma gamma)
>> +{
>> +RRCrtcPtr randr_crtc = xf86CompatRRCrtc(pScrn);
>> +int size;
>> +
>> +if (!randr_crtc)
>> +return Success;
>> +
>> +size = max(0, randr_crtc->gammaSize);
>> +if (!size)
>> +return Success;
>> +
>> +init_one_component(randr_crtc->gammaRed, size, gamma.red);
>> +init_one_component(randr_crtc->gammaGreen, size, gamma.green);
>> +init_one_component(randr_crtc->gammaBlue, size, gamma.blue);
>> +xf86RandR12CrtcSetGamma(xf86ScrnToScreen(pScrn), randr_crtc);
>> +
>> +pScrn->gamma = gamma;
>> +
>> +return Success;
>> +}
>> +
>>  static Bool
>>  xf86RandR12EnterVT(ScrnInfoPtr pScrn)
>>  {
>> @@ -2115,6 +2143,7 @@ xf86RandR12Init12(ScreenPtr pScreen)
>>  rp->rrProviderDestroy = xf86RandR14ProviderDestroy;
>>
>>  pScrn->PointerMoved = xf86RandR12PointerMoved;
>> +pScrn->ChangeGamma = xf86RandR12ChangeGamma;
>>
>>  randrp->orig_EnterVT = pScrn->EnterVT;
>>  pScrn->EnterVT = xf86RandR12EnterVT;
>> --
>> 2.9.3
>>
>> ___
>> xorg-devel@lists.x.org: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-19 Thread Alex Deucher 
On Sat, Sep 17, 2016 at 6:00 AM, Hans de Goede  wrote:
> Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
> dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
> code. Leaving pScrn->ChangeGamma NULL in most cases.
>
> This triggers the BadImplementation error in xf86ChangeGamma() :
>
> if (pScrn->ChangeGamma)
> return (*pScrn->ChangeGamma) (pScrn, gamma);
>
> return BadImplementation;
>
> Which causes X-apps using XF86VidModeSetGamma to crash with a
> X protocol error.
>
> This commit fixes this by re-introducing the xf86RandR12ChangeGamma
> helper removed by the commit and adjusting it to work with the new
> combined palette / gamma code.
>
> Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
> Signed-off-by: Hans de Goede 

Not too familiar with the code in question, but it looks sane to me.
Reviewed-by: Alex Deucher 

> ---
>  hw/xfree86/modes/xf86RandR12.c | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
> index 36767b3..7b3b97b 100644
> --- a/hw/xfree86/modes/xf86RandR12.c
> +++ b/hw/xfree86/modes/xf86RandR12.c
> @@ -1916,6 +1916,34 @@ xf86RandR12LoadPalette(ScrnInfoPtr pScrn, int 
> numColors, int *indices,
>  }
>  }
>
> +/*
> + * Compatibility with XF86VidMode's gamma changer.  This necessarily clobbers
> + * any per-crtc setup.  You asked for it...
> + */
> +
> +static int
> +xf86RandR12ChangeGamma(ScrnInfoPtr pScrn, Gamma gamma)
> +{
> +RRCrtcPtr randr_crtc = xf86CompatRRCrtc(pScrn);
> +int size;
> +
> +if (!randr_crtc)
> +return Success;
> +
> +size = max(0, randr_crtc->gammaSize);
> +if (!size)
> +return Success;
> +
> +init_one_component(randr_crtc->gammaRed, size, gamma.red);
> +init_one_component(randr_crtc->gammaGreen, size, gamma.green);
> +init_one_component(randr_crtc->gammaBlue, size, gamma.blue);
> +xf86RandR12CrtcSetGamma(xf86ScrnToScreen(pScrn), randr_crtc);
> +
> +pScrn->gamma = gamma;
> +
> +return Success;
> +}
> +
>  static Bool
>  xf86RandR12EnterVT(ScrnInfoPtr pScrn)
>  {
> @@ -2115,6 +2143,7 @@ xf86RandR12Init12(ScreenPtr pScreen)
>  rp->rrProviderDestroy = xf86RandR14ProviderDestroy;
>
>  pScrn->PointerMoved = xf86RandR12PointerMoved;
> +pScrn->ChangeGamma = xf86RandR12ChangeGamma;
>
>  randrp->orig_EnterVT = pScrn->EnterVT;
>  pScrn->EnterVT = xf86RandR12EnterVT;
> --
> 2.9.3
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 2/2] xf86RandR12: Fix XF86VidModeSetGamma triggering a BadImplementation error

2016-09-17 Thread Hans de Goede 
Commit b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
dropped the providing of a pScrn->ChangeGamma callback from the xf86RandR12
code. Leaving pScrn->ChangeGamma NULL in most cases.

This triggers the BadImplementation error in xf86ChangeGamma() :

if (pScrn->ChangeGamma)
return (*pScrn->ChangeGamma) (pScrn, gamma);

return BadImplementation;

Which causes X-apps using XF86VidModeSetGamma to crash with a
X protocol error.

This commit fixes this by re-introducing the xf86RandR12ChangeGamma
helper removed by the commit and adjusting it to work with the new
combined palette / gamma code.

Fixes: b4e46c0444bb ("xfree86: Hook up colormaps and RandR 1.2 gamma code")
Signed-off-by: Hans de Goede 
---
 hw/xfree86/modes/xf86RandR12.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index 36767b3..7b3b97b 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -1916,6 +1916,34 @@ xf86RandR12LoadPalette(ScrnInfoPtr pScrn, int numColors, 
int *indices,
 }
 }
 
+/*
+ * Compatibility with XF86VidMode's gamma changer.  This necessarily clobbers
+ * any per-crtc setup.  You asked for it...
+ */
+
+static int
+xf86RandR12ChangeGamma(ScrnInfoPtr pScrn, Gamma gamma)
+{
+RRCrtcPtr randr_crtc = xf86CompatRRCrtc(pScrn);
+int size;
+
+if (!randr_crtc)
+return Success;
+
+size = max(0, randr_crtc->gammaSize);
+if (!size)
+return Success;
+
+init_one_component(randr_crtc->gammaRed, size, gamma.red);
+init_one_component(randr_crtc->gammaGreen, size, gamma.green);
+init_one_component(randr_crtc->gammaBlue, size, gamma.blue);
+xf86RandR12CrtcSetGamma(xf86ScrnToScreen(pScrn), randr_crtc);
+
+pScrn->gamma = gamma;
+
+return Success;
+}
+
 static Bool
 xf86RandR12EnterVT(ScrnInfoPtr pScrn)
 {
@@ -2115,6 +2143,7 @@ xf86RandR12Init12(ScreenPtr pScreen)
 rp->rrProviderDestroy = xf86RandR14ProviderDestroy;
 
 pScrn->PointerMoved = xf86RandR12PointerMoved;
+pScrn->ChangeGamma = xf86RandR12ChangeGamma;
 
 randrp->orig_EnterVT = pScrn->EnterVT;
 pScrn->EnterVT = xf86RandR12EnterVT;
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel