So default command like

 glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)

 never worked quite right on tcl.

(In reply to comment #1)
>  So default command like
> 
>  glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE)
> 
>  never worked quite right on tcl.

How did you arrive at this conclusion?
You could try some things (like throwing out the dlist stuff) and see if that improves things. Or figure out if actually all of the subtests don't pass to narrow it down.

Created attachment 73222 [details]
swtcl

Created attachment 73223 [details]
swtcl

Created attachment 73224 [details]
tcl

Created attachment 73226 [details]
tcl

 Supertuxkart game use irlicht engine and ECM_DIFFUSE_AND_AMBIENT command for the material color, which use vertex color for both diffuse and ambient light. That irlicht command is actualy glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE).

 mb->getMaterial().ColorMaterial = video::ECM_DIFFUSE_AND_AMBIENT;

 http://sourceforge.net/apps/trac/supertuxkart/browser/main/trunk/src/graphics/material_manager.cpp

 And i get this results (see attached pictures) when i use tcl or tcl_mode=0. It get correct lighting with swtcl and incorrect with tcl.

 Fails on ambient light and that check_material hack from r200_state. If i excluded that material check this test passed and supertuxkart get correct colors.
But performance is like swtcl without that check... that need to be fixed somehow
as comment there says ;).

 Also infinite-spot-light piglit test fails because of this, it also pass if i exclude that material check.

(In reply to comment #8)
>  Fails on ambient light and that check_material hack from r200_state. If i
> excluded that material check this test passed and supertuxkart get correct
> colors.
> But performance is like swtcl without that check... that need to be fixed
> somehow
> as comment there says ;).

When you say you excluded the test did you assume always true or always false?
If it works both ways then the fallback itself would cause the trouble (wouldn't be terribly surprising).
I think fixing this to not require a fallback would require quite a bit of work, the wiring necessary is probably ugly. I think not many apps actually change materials inside begin/end.

 
 With always true it pass or opside out, with always false or what is now it fails.

 I think most if not every racing games fail to render correctly because of this, bugs like missing wheels will be there i guess, or loosed color somewhere, etc. Anyway proper lighting is broken there.

Hmm maybe there are bugs in lighting model state somewhere I dunno. But since for this test case the material doesn't actually matter and the wiring looks ok to me (everything wired to vertex color 0) there must be some error elsewhere.

 I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3, 6.5.1 mesa - that is oldest i could run, and this never worked :(.

(In reply to comment #13)
>  I agree... will be hard to find what is it, i've now tested 7.5.2, 7.0.3,
> 6.5.1 mesa - that is oldest i could run, and this never worked :(.

Yes, the test was fixed fairly recently in core Mesa:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1bc16bf98a1b5a4cca0c0ae2a80ba7982c6e4651

 Thanks Marek, i already run these piglit tests with current (today) mesa master and current piglit, they does work and pass but on swtcl only. On tcl they fail, and supertuxkart gives incorrect colors.

 I just go to debian stable to test supertuxkart in hope that with some older UMS mesas somehow i can get correct colors, but nope :(.

 OMG, i managed to fix it somehow :). I put in the end of r200UpdateMaterial function r200ColorMaterial( ctx, 0, 0 ); call and removed it from case GL_COLOR_MATERIAL:

 That fixed supertuxkart colors and dlist-color-material now passed ;).

 Clean mesa up to git-commit 1ec1b577f726a70dd787227260e61928e97474e5

 No regression with piglit quick-driver.tests, just passed dlist-color-material
and fix supertuxkart colors;).

Created attachment 73272 [details] [review]
proposed patch

This looks very fishy to me, I can't see how this could be the right fix (you never know though since apparently some tcl regs have ordering requirements).

 Honestly i don't beleve it is right solution neither (but at least, we are on the right track). I just know that r200ColorMaterial must also somehow in touch with tnl->Driver.NotifyMaterialChange for this to work.

 If i just inited that down in r200InitTnlFuncs that also worked... i know fishies, no way it's proper fix maybe, bla, bla... just idea, but those must be maked in conjuction somehow for this to work;).

 But must say, this patch however worked perfectly here for supertuxkart ;), no issues spotted in any other games i tried these few days. 

 Maybe someone who use r200 driver can test:

 http://supertuxkart.sourceforge.net/Downloads

 0.8 version with or without patch, without patch whole olivermath track have broken colors and lights are broken but not always can be easely spoted. Anyway you can immediately broke lights if do one skid/ding on any single track. With a patch all these lighting/color issues should be fixed.

 And of course dlist-color-material piglit test should pass ;).