Jonathan Dieter wrote:
Mike, I've been following the fedora-devel mailing list, and I
understand why you removed r300 support in Mesa and the kernel. I was
working through a bug where OpenGL didn't work at all (even in indirect
mode), and, in the process, rebuilt both Mesa and the kernel after
removing your fixes. Apparently, I'm one of the lucky ones whose Radeon
9600 works with the experimental driver because it all started working.
I'm now thinking of putting together a package (similar to the
proprietary one in livna) that would give accelerated 3D to any Radeon
users willing to take the risk.
It seems that the only difference in Mesa when the r300 is enabled is
that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and
that the only difference in the kernel is the drm module is patched to
not recognize the r300 PCI ids.
Correct.
It seems that the Mesa problem could be easily fixed, but what is the
> easiest way to fix the kernel (aside from providing my own
> (un)patched kernel)?
The only way, is to unpatch the kernel and rebuild it, and modify Mesa
and rebuild it. Mesa drivers are not buildable outside of Mesa
currently.
> Will X even try to load the DRM module if Mesa doesn't provide
r300_dri.so
> but the kernel does provide the PCI id's?
Yep, the X server loads the DRM aparently, as long as Load "dri" is
present, which is broken in theory at least, although I don't know if
anyone has investigated if there is a good valid reason for that yet
or not.
Loading the radeon kernel module causes various R300 hardware to lock
up, which is prevented when DRM does not get loaded, which is why we
disabled R300 DRM support in the kernel. ;o)
If it doesn't, could we re-enable the r300 PCI ids in the
kernel and just ship Mesa without the r300 driver?
"If it doesn't" is the key here. Once someone who can reproduce
the failures figures out why and fixes the problem though, then we
should be able to re-enable R300 bits in the kernel, unless there
are further issues uncovered.
If it does, is there any other possible solution to the kernel that
> I'm missing?
Yeah, undo the kernel patch, add mesa r300 driver back, and then debug
why it locks up for people, produce a patch that fixes it, and submit
it to the kernel/dri/mesa/xorg projects as appropriate. ;o)
I've been using the fglrx driver in earlier version of Fedora for years
now and would love to take this chance to move off of it and helping
others move off in the process is a bonus.
Indeed. I really hope that in X11R7.1 we'll have a much stabler
2D radeon driver. Right now the open source radeon driver's
stability and reliability pretty much sucks rocks. The rate of
bugs being added to the driver seems to be faster than the rate
of bugs being fixed in the driver. Every time new hardware
support is added, or new features are added for existing supported
hardware, the driver seems to break in ways that don't get discovered
early enough to get fixed. The radeon driver source is currently
rather humongous and growing daily.
It's really quite a horrendous mess right now.
Shipping a 3D driver which works for some people but causes many
other people's 2D desktops to break is very bad. Given the choice
between buggy experimental 3D support and a broken 2D experience,
and working 2D and no 3D, we'll probably always choose to ship the
latter.
benh's fixes in the stable radeon branch improve things for some
people having certain problems. Once a new stable radeon driver
is released, we will probably throw it into updates-testing for
a week then FC5-updates.
If someone wants to make unofficial unsupported Mesa packages
and put them somewhere, that's fine IMHO. But Fedora Extras
is no more of a broken-driver playground than Core is IMHO.
Make an experimental repository somewhere and call it
"Fedora unsupported R300 driver", with a web page that clearly
informs people that while using the experimental driver, all
bug reports should be filed to X.Org bugzilla directly. That
will greatly help the X.Org/DRI/Mesa projects to get the driver
in better shape sooner than later.
Hope this helps!
TTYL
--
Mike A. Harris,
Systems Engineer, X11 Development team,
Red Hat Canada, Ltd.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
