On Tue, Jan 18, 2011 at 3:21 AM, Brian Paul <[email protected]> wrote: > On 01/16/2011 04:50 PM, Dave Airlie wrote: >> >> From: Dave Airlie<[email protected]> >> >> 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<[email protected]> >> --- >> 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. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
