Hi folks,
Just a quick query about the state of the Radeon driver, as it appears
in XFree86-4.2. Seems to work like a dream, unless you have
simultaneous rendering to multiple contexts/windows, in which case
there's huge corruption. It's easy to see, at least on my system
(Mobility 7500/M7,
If you're running XFree86 4.1,
No, I'm running 4.2. Yesterday I bit the bullet and downloaded the
entire source tree (quite an adventure down a phone line ...) and
built from source. All worked fine this time, so there perhaps some
problem with the binary packages on SF? Perhaps there's a
Dear Keith -
This is interesting. The code to cope with multiple contexts there
hasn't had a huge amount of testing. If I download your code, how
can I exercise this problem?
Thanks for offering to look at this. Here's how to reproduce the
problem. First download the i386 executable from:
Dear Jose,
I've disabled the merge with the XFree86 4.2.0 code to see if that
helps and fired up a new build. Please check if the next binaries
are ok.
Sorry to report that the latest SF binaries (well, at least
radeon-20020623-linux.i386) are still broken. Same problem, X server
catches a
In http://dri.sf.net/snapshots/cf are binaries produced by the
SourceForge compiler farm. These were intended to replace the ones
made on my workstation but I never actualy did that because I wasn't
so confident with all the hacks that were necessary to get them to
compile. Could you
Hi all,
Well, experimenting with my own build suggests that if you include
/usr/X11R6/lib/modules/extensions/libdri.a
in the binary packages, everything works fine again.
ie. radeon works if you install the following on top of a standard
XFree86 4.2 distribution:
drm kernel module
Jens -
Can you try with the old libdri.a, but the new libdrm.a. That's where I
would expect the dependency for the new drmCommand interface to be
resolved.
But that's exactly what the SF binary packages give you - they give
you a new libdrm.a as a matter of course, but not libdri.a.
