the code list here:
	glActiveTexture(GL_TEXTURE0);
	glEnable(GL_TEXTURE_2D);
	glBindTexture(GL_TEXTURE_2D,texid);
	glEnable(GL_TEXTURE_GEN_S);
	glEnable(GL_TEXTURE_GEN_T);
	glEnable(GL_TEXTURE_GEN_R);
	glEnable(GL_TEXTURE_GEN_Q);

	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);	
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);	
	glTexEnvf (GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_EXT);
	glTexEnvf (GL_TEXTURE_ENV, GL_COMBINE_RGB_EXT, GL_REPLACE);

	glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);

	p[0] = 0.25f;
	p[1] = 0.0f;
	p[2] = 0.0f;
        p[3] = 0.25f;
	glTexGenfv(GL_S, GL_OBJECT_PLANE, p);
			
	glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);

	p[0] = 0.0f;
	p[1] = 1.0f;
	p[2] = 0.0f;
        p[3] = 0.0f;
	
	glTexGenfv(GL_T, GL_OBJECT_PLANE, p);

	glTexGeni(GL_R, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
	p[0] = 0.0f;
	p[1] = 0.0f;
	p[2] = 0.0f;
        p[3] = 1.0f;

	glTexGenfv(GL_R, GL_OBJECT_PLANE, p);
	glTexGeni(GL_Q, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
	p[0] = 0.0f;
	p[1] = 0.0f;
	p[2] = 0.0f;
        p[3] = 1.0f;
	glTexGenfv(GL_Q, GL_OBJECT_PLANE, p);
	
	glBegin( GL_QUADS );
		glVertex4f( 2.0f, 0.0f, 0.0f, 2.0f);
		glVertex4f( 2.0f, 2.0f, 0.0f, 2.0f);
		glVertex4f( 0.0f, 2.0f, 0.0f, 2.0f);
		glVertex4f( 0.0f, 0.0f, 0.0f, 1.0f);
	glEnd();

(In reply to comment #0)
> When I use texgen with glVertex4f(x, y, z, w) on r200(ATI Radeon Mobility 9000
> card), the s coord texgen use (px, py, pz, pw), but I found s coord always be
> px * x + py * y + pz * z + pw, not expected px * x + py * y + pz * z + pw * w
> as if w is always 1.0f.

Note that the r200 has some hw limitations wrt to texgen, so some cases (particularly if you enable texgen only on some coords) might not work correctly. That said, what you're doing should work - I assume it does if you use sw tnl (tcl_mode=0 or use driconf)? You've got a very old mesa version however, does this also happen with something newer?

(In reply to comment #2)
> (In reply to comment #0)
> > When I use texgen with glVertex4f(x, y, z, w) on r200(ATI Radeon Mobility 9000
> > card), the s coord texgen use (px, py, pz, pw), but I found s coord always be
> > px * x + py * y + pz * z + pw, not expected px * x + py * y + pz * z + pw * w
> > as if w is always 1.0f.
> Note that the r200 has some hw limitations wrt to texgen, so some cases
> (particularly if you enable texgen only on some coords) might not work
> correctly. That said, what you're doing should work - I assume it does if you
> use sw tnl (tcl_mode=0 or use driconf)? You've got a very old mesa version
> however, does this also happen with something newer?

Thank for replay,
I use the texgen function use with GL_OBJECT_LINEAR option and expexted tex coord as px * x + py * y + pz * z + pw * w, it looks like r200 set object coord to normalized (x/w, y/w, z/w, 1.0), so the result is px * x / w + py * y / w + pz * z / w + pw, is it a hw limitation or parameter setting bug?

(In reply to comment #2)
> (In reply to comment #0)
> > When I use texgen with glVertex4f(x, y, z, w) on r200(ATI Radeon Mobility 9000
> > card), the s coord texgen use (px, py, pz, pw), but I found s coord always be
> > px * x + py * y + pz * z + pw, not expected px * x + py * y + pz * z + pw * w
> > as if w is always 1.0f.
> Note that the r200 has some hw limitations wrt to texgen, so some cases
> (particularly if you enable texgen only on some coords) might not work
> correctly. That said, what you're doing should work - I assume it does if you
> use sw tnl (tcl_mode=0 or use driconf)? You've got a very old mesa version
> however, does this also happen with something newer?

or the default vertex shader program set the OBJECT coord to <x/w, y/w, z/w, 1.0f)?

(In reply to comment #3)
> Thank for replay,
> I use the texgen function use with GL_OBJECT_LINEAR option and expexted tex
> coord as px * x + py * y + pz * z + pw * w, it looks like r200 set object coord
> to normalized (x/w, y/w, z/w, 1.0), so the result is px * x / w + py * y / w +
> pz * z / w + pw, is it a hw limitation or parameter setting bug?
The hw should be able to handle it, so should the driver. You should try a newer mesa version.

(In reply to comment #5)
> (In reply to comment #3)
> > Thank for replay,
> > I use the texgen function use with GL_OBJECT_LINEAR option and expexted tex
> > coord as px * x + py * y + pz * z + pw * w, it looks like r200 set object coord
> > to normalized (x/w, y/w, z/w, 1.0), so the result is px * x / w + py * y / w +
> > pz * z / w + pw, is it a hw limitation or parameter setting bug?
> The hw should be able to handle it, so should the driver. You should try a
> newer mesa version.

The problem is solved by update mesa version. But I must DISABLE GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q to do it. If GL_TEXTURE_GEN_R or GL_TEXTURE_GEN_Q is enabled, R200 looks line to object coord to normalized (x/w, y/w, z/w, 1.0), it is same when I use with ATI's driver under windows XP, so it must be a limitation of R200. (and I get the same result on RADEON X300, X1300)

(In reply to comment #6)
> The problem is solved by update mesa version. But I must DISABLE
> GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q to do it. If GL_TEXTURE_GEN_R or
> GL_TEXTURE_GEN_Q is enabled, R200 looks line to object coord to normalized
> (x/w, y/w, z/w, 1.0), it is same when I use with ATI's driver under windows XP,
> so it must be a limitation of R200. (and I get the same result on RADEON X300,
> X1300)

I'm not sure I follow you there. If you get the same results on X300 and X1300 then possibly the results might be correct. Clearly if you disable GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q results are expected to be different.
In the example you gave, what coords do you get?
The coords after texgen for your four vertices should be
(1.0, 0.0, 2.0, 2.0)
(1.0, 2.0, 2.0, 2.0)
(0.5, 2.0, 2.0, 2.0)
(0.25, 0.0, 1.0, 1.0)
hence after the q divide (and ignoring the unused r coord)
(0.5, 0.0)
(0.5, 1.0)
(0.25, 1.0)
(0.25, 0.0)
Is that different to what you get?
Note that if you disable some of the texgen coords, the r200 _will_ produce bogus results in some cases, and I think it's generally a good idea to stay away from doing this

(In reply to comment #7)
> (In reply to comment #6)
> > The problem is solved by update mesa version. But I must DISABLE
> > GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q to do it. If GL_TEXTURE_GEN_R or
> > GL_TEXTURE_GEN_Q is enabled, R200 looks line to object coord to normalized
> > (x/w, y/w, z/w, 1.0), it is same when I use with ATI's driver under windows XP,
> > so it must be a limitation of R200. (and I get the same result on RADEON X300,
> > X1300)
> I'm not sure I follow you there. If you get the same results on X300 and X1300
> then possibly the results might be correct. Clearly if you disable
> GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q results are expected to be different.
> In the example you gave, what coords do you get?
> The coords after texgen for your four vertices should be
> (1.0, 0.0, 2.0, 2.0)
> (1.0, 2.0, 2.0, 2.0)
> (0.5, 2.0, 2.0, 2.0)
> (0.25, 0.0, 1.0, 1.0)
> hence after the q divide (and ignoring the unused r coord)
> (0.5, 0.0)
> (0.5, 1.0)
> (0.25, 1.0)
> (0.25, 0.0)
> Is that different to what you get?
> Note that if you disable some of the texgen coords, the r200 _will_ produce
> bogus results in some cases, and I think it's generally a good idea to stay
> away from doing this

Oh, I forget the texture coordinates is homogeneous coordinates too, so the
texture corrdinates is used with TEXTURE_2D is (s/q, t/q) actually.
with object coordinate (x, y, z, w), the s, q texture coord is:
s = s1 * x + s2 * y + s3 * z + s4 * w
q = q1 * x + q2 * y + q3 * z + q4 * w
if we normalized object coordinate to (x/w, y/w, z/w, 1.0)
s' = s1 * x / w + s2 * y / w + s3 * z / w + s4
q' = q1 * x / w + q2 * y / w + q3 * z / w + q4

s/q = s'/q'

R200 is correct, and you. The real world is 3D world, we can only use three 
indenpendent parameters talk with it.

But can I set q coordinate to 1.0f when I disable texgen Q?

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > The problem is solved by update mesa version. But I must DISABLE
> > > GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q to do it. If GL_TEXTURE_GEN_R or
> > > GL_TEXTURE_GEN_Q is enabled, R200 looks line to object coord to normalized
> > > (x/w, y/w, z/w, 1.0), it is same when I use with ATI's driver under windows XP,
> > > so it must be a limitation of R200. (and I get the same result on RADEON X300,
> > > X1300)
> > I'm not sure I follow you there. If you get the same results on X300 and X1300
> > then possibly the results might be correct. Clearly if you disable
> > GL_TEXTURE_GEN_R and GL_TEXTURE_GEN_Q results are expected to be different.
> > In the example you gave, what coords do you get?
> > The coords after texgen for your four vertices should be
> > (1.0, 0.0, 2.0, 2.0)
> > (1.0, 2.0, 2.0, 2.0)
> > (0.5, 2.0, 2.0, 2.0)
> > (0.25, 0.0, 1.0, 1.0)
> > hence after the q divide (and ignoring the unused r coord)
> > (0.5, 0.0)
> > (0.5, 1.0)
> > (0.25, 1.0)
> > (0.25, 0.0)
> > Is that different to what you get?
> > Note that if you disable some of the texgen coords, the r200 _will_ produce
> > bogus results in some cases, and I think it's generally a good idea to stay
> > away from doing this
> Oh, I forget the texture coordinates is homogeneous coordinates too, so the
> texture corrdinates is used with TEXTURE_2D is (s/q, t/q) actually.
> with object coordinate (x, y, z, w), the s, q texture coord is:
> s = s1 * x + s2 * y + s3 * z + s4 * w
> q = q1 * x + q2 * y + q3 * z + q4 * w
> if we normalized object coordinate to (x/w, y/w, z/w, 1.0)
> s' = s1 * x / w + s2 * y / w + s3 * z / w + s4
> q' = q1 * x / w + q2 * y / w + q3 * z / w + q4
> s/q = s'/q'
> R200 is correct, and you. The real world is 3D world, we can only use three 
> indenpendent parameters talk with it.
> But can I set q coordinate to 1.0f when I disable texgen Q?

The bit R200_TEXGEN_FORCE_W_TO_ONE of the register R200_SE_TCL_TEX_PROC_CTL_0  
may be used to set different Object coordinate for texgen.
for vertex coordinate (x, y, z, w), if R200_TEXGEN_FORCE_W_TO_ONE is set, texgen
get the texture coordinate as 
s = s1 * x + s2 * y + s3 * z + s4;
q = q1 * x + q2 * y + q3 * z + q4;
we set q1 = q2 = q3 = 0.0f and q4 = 1.0f and get q = 1.0f, thus we generate texture
coordinate to s = s1 * x + s2 * y + s3 * z + s4; and vertex coordinate as 
(x, y, z, w).
to do that, replace line 2421 of r200_state.c(mesa ver 7.2): 
   tpc = (rmesa->TexMatEnabled | rmesa->TexGenEnabled);
with
   tpc = (rmesa->TexMatEnabled | rmesa->TexGenEnabled) | R200_TEXGEN_FORCE_W_TO_ONE;   
any better result?   

(In reply to comment #8)
> R200 is correct, and you. The real world is 3D world, we can only use three 
> indenpendent parameters talk with it.
> 
> But can I set q coordinate to 1.0f when I disable texgen Q?
As said the chip might have problem with disabling only some texgen coords, though in this case if you don't need a texture matrix it might be fine.
You can play with R200_TEXGEN_FORCE_W_TO_ONE but this setting doesn't seem useful to generate OpenGL-compliant results.

(In reply to comment #10)
> (In reply to comment #8)
> > R200 is correct, and you. The real world is 3D world, we can only use three 
> > indenpendent parameters talk with it.
> > 
> > But can I set q coordinate to 1.0f when I disable texgen Q?
> As said the chip might have problem with disabling only some texgen coords,
> though in this case if you don't need a texture matrix it might be fine.
> You can play with R200_TEXGEN_FORCE_W_TO_ONE but this setting doesn't seem
> useful to generate OpenGL-compliant results.

Yes, I do the same operation under ATI's windows driver, and no problem with disabling texgen R or Q, (and when enable all of texgen STRQ, they looks like not set R200_TEXGEN_FORCE_W_TO_ONE), so I guess they maybe have another way to set q to 1.0 when disable texgen Q. To play with R200_TEXGEN_FORCE_W_TO_ONE is not a right way but a useful way sometimes.
And sometimes when we disable some of the texgen coords, the r200 produce unexperted results, this maybe we have no right way to generate q coord(for examples, q is zero), but ATI can do it!

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > R200 is correct, and you. The real world is 3D world, we can only use three 
> > > indenpendent parameters talk with it.
> > > 
> > > But can I set q coordinate to 1.0f when I disable texgen Q?
> > As said the chip might have problem with disabling only some texgen coords,
> > though in this case if you don't need a texture matrix it might be fine.
> > You can play with R200_TEXGEN_FORCE_W_TO_ONE but this setting doesn't seem
> > useful to generate OpenGL-compliant results.
> Yes, I do the same operation under ATI's windows driver, and no problem with
> disabling texgen R or Q, (and when enable all of texgen STRQ, they looks like
> not set R200_TEXGEN_FORCE_W_TO_ONE), so I guess they maybe have another way to
> set q to 1.0 when disable texgen Q. To play with R200_TEXGEN_FORCE_W_TO_ONE is
> not a right way but a useful way sometimes.
> And sometimes when we disable some of the texgen coords, the r200 produce
> unexperted results, this maybe we have no right way to generate q coord(for
> examples, q is zero), but ATI can do it!

An acceptable way maybe when user disable texgen Q, driver can enable it on R200, and set q1 = q2 = q3 = 0.0f, and q4 = 1.0f, and set the R200_TEXGEN_FORCE_W_TO_ONE, thus we can get q to 1.0f. it is OpenGL-compliant!

(In reply to comment #12)
> > Yes, I do the same operation under ATI's windows driver, and no problem with
> > disabling texgen R or Q, (and when enable all of texgen STRQ, they looks like
> > not set R200_TEXGEN_FORCE_W_TO_ONE), so I guess they maybe have another way to
> > set q to 1.0 when disable texgen Q. To play with R200_TEXGEN_FORCE_W_TO_ONE is
> > not a right way but a useful way sometimes.
> > And sometimes when we disable some of the texgen coords, the r200 produce
> > unexperted results, this maybe we have no right way to generate q coord(for
> > examples, q is zero), but ATI can do it!
> 
> An acceptable way maybe when user disable texgen Q, driver can enable it on
> R200, and set q1 = q2 = q3 = 0.0f, and q4 = 1.0f, and set the
> R200_TEXGEN_FORCE_W_TO_ONE, thus we can get q to 1.0f. it is OpenGL-compliant!

Maybe I'm missing something, but I fail to see how that can work. If you set R200_TEXGEN_FORCE_W_TO_ONE how can the result be correct if the incoming vertex w is != 1.0? I think that basically would just eliminate the w divide which can't possibly be correct.

(In reply to comment #13)
> (In reply to comment #12)
> > > Yes, I do the same operation under ATI's windows driver, and no problem with
> > > disabling texgen R or Q, (and when enable all of texgen STRQ, they looks like
> > > not set R200_TEXGEN_FORCE_W_TO_ONE), so I guess they maybe have another way to
> > > set q to 1.0 when disable texgen Q. To play with R200_TEXGEN_FORCE_W_TO_ONE is
> > > not a right way but a useful way sometimes.
> > > And sometimes when we disable some of the texgen coords, the r200 produce
> > > unexperted results, this maybe we have no right way to generate q coord(for
> > > examples, q is zero), but ATI can do it!
> > 
> > An acceptable way maybe when user disable texgen Q, driver can enable it on
> > R200, and set q1 = q2 = q3 = 0.0f, and q4 = 1.0f, and set the
> > R200_TEXGEN_FORCE_W_TO_ONE, thus we can get q to 1.0f. it is OpenGL-compliant!
> Maybe I'm missing something, but I fail to see how that can work. If you set
> R200_TEXGEN_FORCE_W_TO_ONE how can the result be correct if the incoming vertex
> w is != 1.0? I think that basically would just eliminate the w divide which
> can't possibly be correct.

Oh, It looks like we can't find a way to disable textgen Q on r200 and set q to 1.0f, using R200_TEXGEN_FORCE_W_TO_ONE can only provide a way to control texture coordinate for special task, but not an OpenGL-compliant way.