*edit: fixed screenshot links*

I have a weird problem with DRI on my Intel 810E chipset. The normal display stuff works just fine, but I can't get direct rendering to work properly. Hard to describe problem - see screenshot here: http://www.geocities.com/smith847be/DRI_Problem.html . Note that this is just a screenshot of TuxKart, but I have very similar looking screens for other programs (TuxRacer, TORCS, FlightGear, EgoBoo, etc.). Also, note that I've tried changing the screen resolution in XF86Config-4 to all sorts of different things - no effect. I've also been trying to get this working for a while, but to no avail. Feel free to suggest anything that may be a cause or any kind of help, though - I'm stumped. By the way, I'm running Debian Sarge (aka Testing). The Debian xfree86 packages have never worked quite right for me, so I'm running an XFree86 compiled from the 4.3.0 sources (from xfree86.org). Also, here are other files that may be of use:

/etc/X11/XF86Config-4: http://www.geocities.com/smith847be/XF86Config-4.txt
/var/log/XFree86.0.log: http://www.geocities.com/smith847be/XFree86.0.log
output of $ glxinfo : http://www.geocities.com/smith847be/glxinfo-output.txt
screenshot #1 : http://www.geocities.com/smith847be/DRI_Problem.html
screenshot #2 : http://www.geocities.com/smith847be/DRI_Problem2.html

Summary of those files:
XF86Config-4 : DRI enabled mode 0666, there are a whole bunch of extraneous comments in here from previous experiments to get DRI working
XFree86.0.log : reports no relevant errors that I can see, I can't see anything wrong
glxinfo : recognizes direct rendering as active, I can't see any problems

Thank you in advance for any help.

I didn't get to see the pics of the problem, everything looks right from config, the glxinfo and the log though, it looks brilliant actually. Thanks for all the info btw, damn good homework.

The "slow" listings on DRI are kinda spooky from glxinfo.

To describe around the problem, what're the bugs in the screen? Is it GL is getting thrown to software despite what the glxinfo says? artifacting? striping in the screen? double overlay?

First off that I can think of, the i810 does shared mem right? Might want to make certain that it actually has the 8Mb available that it thinks it does... then also you might want to run a X -configure and take a look at an X configured XF86Config instead of the anaconda created one, all of video card options that might fix this will be listed in the X created file... there's got to be a dozen or so... unfortunately I don't have an i810 around

Cheers,

Finegan

Alright,
1) Annoying free web space - Geocities apparently doesn't allow directly linking to .jpg files - anyway, fixed now, so you can see what the problem looks like in the two screenshot links. Sorry.
2) Interesting, 'X -configure' gave me this error:

(EE) LoadModule: Module dri-old.i810 does not have a dri-old.i810ModuleData data object
(EE) Failed to load module "dri-old.i810" (invalid module, 0)

I tried moving the three dri-old.i810.[whatever] files that 'locate' found. X -configure then gave no errors, but I got the same error as above, but with dri-old.i810 replaced with dri-old.libdri upon starting X with the new XF86Config file. I thought that all the dri-old things were for XFree86 3.x. But I have 4.3.0. Huh? Why does X -configure want dri-old modules? Here is the 'X -configure' generated XF86Config:
http://www.geocities.com/smith847be/XF86Config.new.txt

wheeeeew... no idea what that is. Pictures look like a lot of mess. Never seen that before.

I had an idea though. X logs horribly, but those GL programs will probably kick some useful errors. If you open up a Konsole (noticed KDE), and just launch the ap from there by typing the full path to it, then the konsole will end up with all of the debugging goo in that instead of it getting /dev/null'd.

I don't know about the -old.i810 mess. You could just replace the line in there with normal old DRI, add in a DRI subsection, sort the monitor settings a little, with a defaultdepth and then some Modes and ViewPort Settings and see how the X generated one goes, albeit the only differences really will be a few more modules loaded and static paths to fonts instead of using a font server. Also might want to hack into your old XF file all of those possible video card settings and just juggle them around a bit, but as to what to juggle, its most likely going to be helpful to get some feedback from the above trick.

Cheers,

Finegan

First, launching the programs from konsole, the only program that gave useful output (because it had a --verbose option) was FlightGear. First time I launched it (with original XF86Config-4) it gave me this stuff in the relevant output:

Opening a window: 800x600
Mesa DRI I810 20020221
Max texture size = 256
Depth buffer bits = 16
Segmentation fault
[then stopped loading]

I noticed the Mesa DRI 20020221. The xlibmesa <i>packages</i> that I have installed are all dated various times in 2003. So I 'apt-get --reinstall' ed the xlibmesa packages (which all had 2003 and 2004 dates) and then launched FlightGear again. Here's that output:

Opening a window: 800x600
Mesa DRI I810 20010321
Max texture size = 256
Depth buffer bits = 16
[then continued loading and gave me the same kind of screwed up display as screenshots]

And now I get an even earlier date on Mesa DRI. Huh?
Second, I made the changes you mentioned in the 'X -configure' XF86Config file, but it made no difference to DRI. Also, I could find no equivalent to the 'Load "dri-old.libdir"' line, so I just commented that out. X loaded fine with the config (no errors), but I got the same exact problem with direct rendering. Would it be worth it to just 'rm -r /etc/X11' and 'rm -r /usr/X11R6' just to clean out any extraneous stuff that may be in there, and then just completely recompile X? When I was first setting up Linux, I had display problems and did a whole bunch of 'apt-get' removing, installing, and reinstalling of X stuff - that shouldn't have left any extra stuff in there, but maybe?

P.S. the link in your signature for 'Is this your wireless card?' gives a 404 not found. You may wish to update that link.

Thanks for the info on the link. The linux-wlan.net link is toast too, so they must have done something not bright.

I've never known apt to mess up something like that, but you might indeed have a messy X install... I'd dpkg all of the X instead of just wipping the directory, what little experience I have with Debian, it really hates things not being where they should. At least, trying to use dpkg and apt to clean out those directories entirely first may be the best move. Debian's reticence to upgrade anything, even in Sarge has always made me a bit of a Deb neophyte. A hand compile of X is a pain if you've never done it, especially then splicing in all of those mesa libs too, and opengl... also, what kernel are you on? the i810 DRM driver has gotten a lot of work since Sarge's default, what's that ? 2.4.18 with 2 ptrace fixes?

We're into X-voodoo land no doubt. No debugging output, that sucks... but it thinks its displaying right, so I'm guessing DRM driver now, not the graphics lib.

Cheers,

Finegan

Alright, I did end up just completely blowing away /etc/X11 and /usr/X11R6 (as well as doing proper 'dpkg --purge' s of the packages). I then installed all the X packages from scratch. Same problem. I then upgraded the packages to the most recent in Sid (Unstable) (which, as you mention Debian's slow updating - yes, they purposely are slow for Woody and Sarge, but Sid usually gets new releases within a day or two if there are no complicated dependency problems). Same problem again. My kernel is direct from the Debian source package (I need to custom compile for some options not on by default for my 802.11b card) and is version 2.4.22. I have DRI for i810 all compiled into the kernel. By the way, yes the i810 stuff uses AGPGART, is built into the chipset (I know, puny graphics, but it works - kindof), and uses shared memory. This really is a weird problem with DRI - and you can see why it's been stumping me. This weekend I may try downloading a 2.6 kernel, maybe? that would make a difference for some reason. Also, maybe this could help something. It looks to me when I launch a DRI app that this is what it's doing (though it flickers so fast, it's hard to tell):

Normal Screen:
11111111
22222222
33333333
44444444
55555555
66666666
77777777
88888888

My screen:
11111111222222223333333344444444
55555555666666667777777788888888

Could that be possible? that maybe for some oddball reason the DRM driver thinks the screen is thinner than it is, essentially. Except that I get an identical looking DRI screen at any resolution and non-DRI stuff works fine. Maybe I'm just seeing things - it is hard to tell what's going on - but that's a possible interpretation.

Also, this is weird, I just looked at the most recent XFree86.0.log. I'll post it here: http://www.geocities.com/smith847be/...6.0-second.log . Notice there are a whole bunch of "Not loading .note.GNU-stack" messages - they aren't marked as errors or anything - after it looks like any *.a module load. This only appeared apparently after I upgraded to the Sid packages. Any idea what in the world that means? Google doesn't come up with anything that seems relevant. Finally, are there any other logs / configs / etc that I could post that could help at all (e.g. any of the stuff in /proc/dri/0/)? And, by the way, you are being very helpful, finegan - thanks.

I had a fun time with that chipset,too.I still get fragments like you have there under certain circumstances but it is manageable now - they only appear within apps that are automatically started when kde comes up and after I restart the app it's ok.Before that the whole x server went crashing and never got back until you reinstalled xfree - gave me some error about 'ring buffer'.
Bad news is that I got no idea what fixed it.
I did go to a 2.6 kernel and what was xfree CVS about a month ago - calls itself version 4.3.99
Got no idea how to get your hands on this with debian except compiling it yourself.
You might want to try the experimental version of xfree.
Used to be there: 'deb http://people.debian.org/~branden/packages/ sid/i386/'
in the apt sources but I don't think thats working anymore after the server compromise at debian.
You might want to check with the knoppix version if you got a fast connection.

THANK YOU crashmeister AND finegan!!!!! I upgraded to kernel 2.6, and DRI works now! I didn't have to change any settings, just install kernel 2.6! That's still really weird that kernel 2.4 would have such problems, especially since the i810 chipsets are not exactly rare. Anyway Thank You! And crashmeister, right that that xfree86 deb link doesn't work - but not because of the server compromise; http://people.debian.org/~branden/ is a working site. I guess he just doesn't maintain the packages any more. http://apt-get.org doesn't find any xfree86 cvs sites, either. Oh well, direct rendering works - I'm happy.

Good.It is strange that a well documented and very common chipset causes that much trouble though.