Several graphics driver seem to have trouble with XOrg 6.8.x. Currently, there are several postings in the forums about buggy driver (ATI fglx, for example). However, The problem seems to be more XOrg.6.8 related, since it does occurs with several cards (VIA KM400 and ATI testet, perhaps more). Both driver have been testet with XOrg6.7, no problem occured. GLX applications crash the Server or use software acceleration only. The Xorg log file contains several "No matching visual for __GLcontextMode with visual class = -1 (-1), nplanes = 0" Debug output of glxinfo contains drmOpenByBusid: drmOpenMinor returns -1003 for all cards in /dev/dri Does anybody know how to solve this problem? lines.
Sorry, I forgot sysinfo: both mentioned systems run Gentoo Xorg: 6.8.1 kernel: 2.6.8.1 VIA systems graphix driver: unichrome / via-binary only ATI Rage 3D Pro driver: dri.soruceforge.net's mach64-20041017-linux.i386.tar.bz2
The issue is that the old, sickening internal GLX API was changed to add support for "new" (i.e., from 1997) GLX features like fbconfigs. The interface between the DDX and the GLX subsystem is so intertwined that it makes the two look like some sort of perverted Siamese twins. Even with the changes the interface is still horrible. The real fix is to 'rm -rf programs/Xserver/GL' and start over. That's a pretty big project, and I haven't had time to do it. The fix to your problem is to modify the drivers to use the new interface and rebuild them.
fglrx is known to be broken due to GLX interface changes. This is something that ATI would need to fix for their distribution of the drivers. Similarly for old binary-only VIA drivers (you should be using current open-source versions). Care to explain the specific problems you have with mach64 snapshots on 6.8, so we can get this closed?
Perhaps you could give me something to start with (Interface Doc of old and new api, usesful links) to fix the ATI Rage driver. Maybe sperate support for both, new and old api, could also be a temporarely solution, although drivers supporting the new interface would be the much better way. The old glx api could be frozen in it's deprecated state seperately from the new api. However, most of the drivers are binary only. For example, the only "usable" driver for VIA unichrome KM400 is the binary one, since VIA doesn't offer the reg. description to the unichrome project. Thus, the Unichrome project seems to look for a needle in a haystack and is mostly busy with removing and reorganizing the early stage source code, offered once by VIA. As you posted, the fglrx has same problems. It seems the companies will prefer to distribute closed source drivers for the next (long) time. So a hybrid solution could be the fastest way for users (except NVidia users), although it would result in redundancy. Anyway, 3D cards could by used independent from the will of the closed source driver developers, since companies like ati develop their linux driver with very low priority. Even lesser priority has the compatibility with XOrg.
As far as we know, mach64 works. What specific issue are you seeing with the Mach64 snapshots on top of a clean X.Org 6.8.1 or CVS?
(In reply to comment #5) > As far as we know, mach64 works. What specific issue are you seeing with the > Mach64 snapshots on top of a clean X.Org 6.8.1 or CVS? > Huh?! As i mentioned above, it reports a lot of "No matching visual for __GLcontextMode with visual class = -1 (-1), nplanes = 0" I've installed a fresh mach64 snapshot (19.oct.2004). DRI seems to be more or less enabled, however, the funny log line remains... glxinfo prints out a lot of "libGL warning: 3D driver claims to not support visual 0xffffffff" and glxgears adds an "Error: couldn't get an RGB, Double-buffered visual" to it. (several color depths with a 640x480 resolution tested). I think, mach64 does not work correclty... I'll try XOrg CVS later, this may take some hours.
I finaly tested it, the CVS seems to work with the ati snapshot. However, what happens with all the other drivers? Where can I get the source for mach64?
(In reply to comment #7) > Where can I get the source for mach64? the DDX source is in xorg cvs. the 3d driver source is in mesa cvs.
I'm closing this as FIXED. In truth, it's somewhere between FIXED and NOTABUG. Either way, the problem no longer exists.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.