Created attachment 11149 [details]
test case

this is a simple test case

Created attachment 11150 [details]
test case

paste the wrong case last time

GL spec says,

Unlike other commands that transfer
        pixel data, "No pixel transform operations are performed" on
        the queried texture image.

So I am afraid mesa core follow the requirement.

But, according to the OpenGL spec:
'sRGB values are returned "as-is" without an sRGB-to-linear conversion.'

So, sRGB values should still be correctly returned for R, G, B, and A component respectively. Just sRGB-to-linear conversion is not performed.

So, I will reopen this bug

If this is suppose to be a bug, it is a mesa core bug.
mesa core code intent to do so.

to make things clear, following is what the test case done:
the texture is 4x4.
all texels' RGB components of the srgb texture are written to be 1
then we try to read back all the texels' RGB component, the result is as following (but we expect all the values it result to be 1s):
image2[0] = 1
image2[1] = 1
image2[2] = 1
image2[3] = 255
image2[4] = 1
image2[5] = 1
image2[6] = 1
image2[7] = 255
image2[8] = 1
image2[9] = 1
image2[10] = 1
image2[11] = 255
image2[12] = 1
image2[13] = 1
image2[14] = 1
image2[15] = 255
image2[16] = 1
image2[17] = 1
image2[18] = 1
image2[19] = 255
image2[20] = 1
image2[21] = 1
image2[22] = 1
image2[23] = 255
image2[24] = 1
image2[25] = 1
image2[26] = 1
image2[27] = 255
image2[28] = 1
image2[29] = 1
image2[30] = 1
image2[31] = 255
image2[32] = 1
image2[33] = 1
image2[34] = 1
image2[35] = 255
image2[36] = 1
image2[37] = 1
image2[38] = 1
image2[39] = 255
image2[40] = 1
image2[41] = 1
image2[42] = 1
image2[43] = 255
image2[44] = 1
image2[45] = 1
image2[46] = 1
image2[47] = 255

In comment #7, which driver are you using?

In any case, I think the test program has a bug.  I think you want to set the pixel pack/unpack alignment values to 1:

  glPixelStorei(GL_UNPACK_ALIGNMENT,1);
  glPixelStorei(GL_PACK_ALIGNMENT,1);

(In reply to comment #8)
> In comment #7, which driver are you using?
> 

I'm git tip mesa

> In any case, I think the test program has a bug.  I think you want to set the
> pixel pack/unpack alignment values to 1:
> 
>   glPixelStorei(GL_UNPACK_ALIGNMENT,1);
>   glPixelStorei(GL_PACK_ALIGNMENT,1);
> 
oh, yes, thanks for reminding.

Created attachment 14405 [details]
fixed test case

Created attachment 14406 [details]
fixed test case

Brian, any response to the new test case in comment# 11

The test program produces the expected output (all 1's) for me with Mesa/master and the 7.0.x branch.

(In reply to comment #13)
> The test program produces the expected output (all 1's) for me with Mesa/master
> and the 7.0.x branch.
> 

yes, it's working in software rendering. so it's a i965 specific issue.

Brian, that is because in _mesa_get_teximage sGRB texture is get by direct memcpy without pixel transfer. 
For of hardware limit SRGB is transfered to SRGBA format on 965.

If you modify the testcase to use GL_RGBA to get the image but GL_SRGB_EXT to store the image, you will see the same issue in software rendering.

To fix the issue, maybe we need something like add FetchTex2fRaw interface for TexImage. 

this issue also happen on mesa_7_0_branch now

this issue still exists with:
Kernel_version:         2.6.29-rc7
Libdrm:         (master)2e2e8575b1ed4703653a72ac2b60b75316c388d7
Mesa:            (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9
Xserver:         (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:      (2.7)238c2c40afd9f8b61479b8640d53f20d52fd7ddf
Kernel:       (for-airlied)dc529a4fe1ae4667c819437a94185e8581e1e680

(In reply to comment #17)
> Mesa:            (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9

should be fixed in mesa master however.

(In reply to comment #18)
> (In reply to comment #17)
> > Mesa:            (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9
> 
> should be fixed in mesa master however.

I believe that it is.  I was going to cherry-pick a few related commits to mesa_7_4_branch, but they all had many conflicts.  I didn't feel like sorting out all the conflicts, but I wouldn't stop someone else from doing it. ;)

This issue has gone

verified against:
Mesa:		(mesa_7_5_branch)fc7f92478286041a018ac4e72d2ccedeea7c0eca

Mass version move, cvs -> git