Hide Forgot
Anaconda (and Xconfigurator for that matter) offer 24 bpp as their berst color resolution. This resolution, however, is officially unsupported by DRI. This leads to unpredictable lock-ups using 3d-accelerated xscreensavers. I was able to get my ATI All-in-Wonder 128 pro working only with 16 bpp. I suggest adding a little disclaimer concerning this particular disadvantage of choosing 24 bpp. DRI officially suports 16 bpp and 32 bpp, Unfortunately, neither anaconda, nor Xconfigurator give 32 bpp option for sonme reason. Please, advise users against choosing 24 bpp if they want to use 3d- accelerated stuff.
Preston, Bill, or Trond: What is the answer to this so we can get it in the GUI X configuration?
24 bpp is the same mode as 32 bpp. Another factor to consider is that Matrox cards only have working DRI in 16 bpp.
Yes; while DRI will try and start in 24/32bpp, I'm not sure it actually *works* at that depth on any of the cards.
I'm pretty sure that the r128 and ati only really work with DRI in 16bpp right now, especially when you consider that a lot of these chips out there are in laptops which don't have the video ram you need to support 32bpp and DRI.
The problem is not r128 specific, see bug 33368 about G400/G450. Nor is it specific to laptops. I guess anaconda (and Xconfigurator) should just be more careful enabling DRI conditionally only for supported color depths! Right now it makes no distinction, which is wrong. Installer should also explicitly warn against 24 bpp, and give the choice of full 32 bpp.
Enabling DRI in usupported bit depths has no harm, 3D is just very slow (not accelerated). As for 24 vs. 32 bit, XFree 4 doesn't handle 32 bit so this is not an option. The current way is not doing anything wrong, but having 16 bpp as default for Matrox and possibly r128 would give more people accelerated 3D.
Please see bug 25920 and bug 28987 , they describe how harmful enabling of DRI on wrong colordepth is. In short, it causes X lock-ups on my Rage 128 PF.
These were fixed in the kernel - there was bug there which made the R128s very unstable.
Gareth Hughes's fixes to kernel's drm module probably fixed some cases but they never helped me. I can lock up X server in no time firing up Morph3D, Gears, or Atlantis with 24 bpp depth and DRI enabled! True, they slowly worked at this color depth and DRI disabled. First time I saw these screensavers properly working was yesterday when I reduced the colordepth to 16 bpp. I do have recent kernel and X from rawhide.
It's all about memory. 16 Mb card is supposed to work at 1280x1024x24bpp as long as it's not 3d accelerated. 3d stuff locks up X server because DRI requires 3-4 times more memory. I tried reducing to 1024x768x24bpp - 3d stuff works again! 1280x1024x16bpp works even better. Thus, anaconda and Xconfigurator should enable DRI only when there is enuf memory for it. Top 2d resolution is definately an overshot for DRI. Sorry for initially erroneous bug report. Anaconda and Xconf stell need fixing though.
Really the bug is in XFree86 because it should not allow stupid combinations of options like enabling DRI in high res on unsupported depths on cards with low memory constraints. Unfortunately X does allow these dumb configurations. So, it will definitely be looked into in the future for X configuration. I'm changing this from Anaconda to Xconfigurator.
I have fixed a similar problem in the tdfx driver. A similar fix might work ok in the r128 driver, but the r128 is significantly different since there are a lot more different r128 chips to cover, so it might take some fiddling to get just right. Not a high priority though since such problem is rarely reported on ATI hardware. The proper fix is twofold. 1) Fixing the driver to not allow unsensible combinations at runtime 2) Fixing the config tools to not allow nonsensical configuration. #2 will come first likely Deferring for future.
Through the last few releases I have not heard of any problems from any users with DRI being enabled on ATI hardware in bit depths that are unsupported. Any stability issues seem to be fixed now. I'm closing this out as I don't see it as a relevant issue any more. If someone experiences a problem similar to this using our latest distro release, please reopen a new bug report in bugzilla, and we can try to fix the root cause of the problem, rather than kludging it over in configuration tools. The driver source is the proper place to either fix a bug, or provide detection/workaround of a problem combination of depth/dri/memory/etc.