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
Please, advise users against choosing 24 bpp if they want to use 3d-
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
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
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
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