Hans de Goede wrote:
Build System wrote:
> * Sat Feb 25 2006 Mike A. Harris <mharris(a)redhat.com> 6.4.2-5
> - Disable the expeimental r300 DRI driver, as it has turned out to cause
> instability and system hangs for many users.
1) disable as in not enable by default / need manual config edit to
enable, or disable as in needs recompile to enable?
Disable as in, r300_dri.so is no longer included in the binary packages.
2) if disable as in needs recompile, does it cause problems even when
turned of by default.
Yes, it causes hangs on many systems, in particular X300 and higher ATI
hardware even if just the dri extension module is loaded and no OpenGL
software has been ran.
If not then why the disable?
Because it was turned on for a short time as an experiment, with the
goal being to disable it completely if there were any signs of severe
instability caused by it. That instability has been observed and
confirmed, so it is now disabled.
In my box the r300 drivers is one of the major features of the new X
(if and only if it works, agreed there)
That is one of the reasons the experiment was tried to begin with. A
number of people have requested r300 DRI support for a long time now,
and finally a very highly experimental driver was created by reverse
engineering. The upstream developers of the r300 driver claim straight
out that it is very experimental, and not ready for mainstream use,
and ATI has confirmed this as well.
There are a handful of people who have installed and tried the driver
and it has worked for them. The exact set of circumstances in which
the driver actually works, is not fully known, and so shipping a
driver that crashes or otherwise screws up one's display or locks up
their system by default, is not an acceptable thing to do.
Part of the experiment of including it in Fedora development was to
try and gauge just how well it worked, if at all, and also to see
the extent of instability it might cause. Since it /is/ experimental,
the intention was always that if we did decide to ship it, DRI would
be disabled by default on all of the chips it supports, requiring
manual override to enable it.
Unfortunately, the number of people it actually works for is very
small compared to the variety of hardware it attempts to cover, and
the majority of reports coming back are of the "my system is screwed"
nature. Doing a bit of investigation has shown that it isn't just the
r300 DRI driver that is instable, but even just loading the X server
DRI module with many r300 or newer cards causes the system to crash,
even if DRI is actually disabled, and even if the r300 DRI driver is
not even present on the system.
In order to resolve the remaining "My r300 or better class card locks
up when X starts if 'Load "dri"' is present in the xorg.conf, and the
problem does not go away if I use 'Option "nodri"', nor even if I
delete the r300_dri.so driver, but the problem goes away if I comment
'Load "dri"' out of the config file.", it looks like we're
have to debug what is causing the hang, and I have a good suspicion
that the kernel DRM is being loaded even if DRI gets disabled, and
that the kernel DRM is probably hanging the system.
Hardware support that is this buggy/unstable does not belong in the
OS until it is stabilized upstream *first*. I'm going to see if
removal of the r300 DRM kernel module resolves the remaining problem,
and if so, we might remove that too for now.
The extremely small subset of users for whom this driver actually
works, and is stable, are free to recompile things if they like, but
with the obvious caveat that we don't support it at all, and don't
support systems that have it loaded any more than we support 3rd
party proprietary drivers.
Mike A. Harris * Open Source Advocate * http://mharris.ca