@sebsan : Bonjour breton !
My kernel is the last one provided by Ubuntu : 2.6.35-24
libdrm 2.4.21 for radeon is already installed
I run the mesa libgl1-mesa-dri (and glx) 7.9
I run xserver-xorg-video-ati 1:6.13.1
When I run glxinfo, I well get a "direct rendering: yes" saying that this is the mesa infrastructure. And finally, if I try to active the Compiz effecs, I get : "No 3D driver available".
Of course, with fglrx, this runs perfectly, but what an awful splashscreen !
I wasn't able to connect the "xorg-edgers-ppa", I get an error 404.
You don't have acceleration because some parts of your stack are too old. Direct Rendering is unimportant in this context.
I do not remember which versions exactly brought HD5xxx support, but I'm pretty sure that upgrading all these to the most recent version you can get will give you working 3d acceleration. In October 2010, it was NOT widely available in distributions.
I don't have experience with Ubuntu, but I'm sure that somebody else here can tell you exactly how to do this. Otherwise, ask on an Ubuntu forum how to add the latest drivers from xorg-edgers.
We are mid January, 11.04 is expected pretty soon, I can wait.
One more political question, and I hope Bridgman will participate: I read AMD hired some guys to develop the Open Source driver, so what's the need to maintain a closed source one?
Finally I couldn't wait and it was so simple to get it!!
I just added the ppa:xorg-edgers/radeon ppa, install the mesa and xserver-xorg-ati packages, disable fglrx and reboot. Done!! 3D, compiz and the nice Ubuntu splashscreen.
Thanks for all.
atombios in PCI expansion rom and endianess
Just to be sure:
from at least evergreen based boards, atombios header is right after the PCI data struct of the first code image of the PCI expansion rom?
atombios table endianness is what? (little/big/arch/depends on field types)
I got the answer from IRC then I answer to myself:
Originally Posted by sylware
- Yes location of the atombios header in the PCI is set in stone for PCB manufacturers.
- atombios table layout is little endian.
atombios command table parameter space
It seems the parameter space size in the command table header is broken.
Indeed it seems that some command tables (root or not) do have an empty parameter space (zero sized), but do use opcodes accessing the parameter space. Then, dynamically allocating that space from the size field from the command header won't work.
The current atombios interpreter does allocate statically the parameter space from structures in atombios.h. Then when the interpreter calls a sub command table, it uses the statically allocated space at the root level. A kind of pre-allocated stack.
What is the proper way to allocate the parameter space?
Random remark: why is this still stickied? The other drivers are dead and AtomBIOS is no longer a hot topic of confusion given that it "won."