[Mesa-dev] [PATCH] mesa: EXT_framebuffer_sRGB interface additions.

[Dave Airlie]

On Tue, Jan 18, 2011 at 3:21 AM, Brian Paul <brianp at vmware.com> wrote:
> On 01/16/2011 04:50 PM, Dave Airlie wrote:
>>
>> From: Dave Airlie<airlied at redhat.com>
>>
>> This adds the get/enable enums and internal gl_config storage
>> for this extension.
>>
>> In theory this is all that is needed to enable this extension
>> from what I can see, since its not mandatory to implement the
>> features if you don't advertise the visuals or the fb configs.
>>
>> Signed-off-by: Dave Airlie<airlied at redhat.com>
>> ---
>>  src/mesa/main/enable.c |   11 +++++++++++
>>  src/mesa/main/get.c    |    5 +++++
>>  src/mesa/main/mtypes.h |    5 +++++
>>  3 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
>> index d047586..c4c4e1b 100644
>> --- a/src/mesa/main/enable.c
>> +++ b/src/mesa/main/enable.c
>> @@ -968,6 +968,12 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap,
>> GLboolean state)
>>           }
>>           break;
>>
>> +      /* GL3.0 - GL_framebuffer_sRGB */
>> +      case GL_FRAMEBUFFER_SRGB_EXT:
>> +        CHECK_EXTENSION(EXT_framebuffer_sRGB, cap);
>> +        ctx->Color.sRGBEnabled = state;
>> +        break;
>
> I think we may need to signal a state change here (_NEW_COLOR or
> _NEW_BUFFERS).
>

At the moment I haven't needed it, but I've only got swrast working at all here.

The problem I've had to solve so far is I need a derived internal
Color._sRGBEnabled,
that we only turn on around the rendering and clear paths and leave
off around the
pixel paths, as swrast uses the same codepaths to fetch from FBO for
all operations.

So I've had to derive correct state around the span code, I'll get
that cleaned up a bit
once I get this bit merged.

http://cgit.freedesktop.org/~airlied/mesa/commit/?h=framebuffer_srgb
has the completed swrast driver I'm cleaning up.

Dave.