Ok, because even if it looks like a long journey.
I certainly will give it a shot during the holidays hehe.
Is it worth writing a script to do the whole thing ?
And what about an update-thewholebunch option ?
I got it compiled using ebuilds (the problem I posted before with pkgconfig was because the ebuild was not using the r6xx-r7xx-3d branch).
When I launch glxgears, I get a kernel oops (or something similar). If I try a second time, the system freezes. So obviously not quite ready yet :P. I'll post the trace tomorrow, in case it helps.
Yeah, this is roughly where we were with driver bring-up when we decided to jump across to the radeon-rewrite code base and define a new API for the mesa-to-drm interface.
There is code in the driver to do a lot more than glxgears, but we need to keep slogging through bringup work for a bit longer.
1. Does this work with 2.6.29 kernel?
2. Does this work with kde4.2, which seems to have qt4?
3. Does this work with 64 bit?
I'm trying all three and have not gotten any 3D with hd3200.
With radeon (ati) running, glxinfo or glxgears gives:
Code:Error: couldn't get an RGB, Double-buffered visual
The current drm code seems to work best with 2.6.27 and 2.6.28 right now. I have seen problems reported with 2.6.29 and 64-bit. Not sure whether the devs are mostly working in 32- or 64-bit, will ask. In terms of working with KDE, all I can say is "I would be really surprised if it did".
The devs are going through the bringup activity now, starting with the basic Redbook tests and fixing each of those first.
What exactly was implemented in kernel 2.6.30? Kernel modesettings?
Kernel modesettings for Radeon was never actually implented in the upstream 2.6.30 kernel source.
Yep. What went into 2.6.30 was the drm calls used by the X server for EXA and Xv acceleration on 6xx/7xx.
Direct rendering clients (eg Mesa, the 3D driver) use a different set of API calls; those are not yet supported in the kernel tree. Not sure if they will make it into 2.6.31 or not; it depends on 3D driver progress. Until the 3D driver is at a point where we think the mesa-to-drm API can be frozen it is not considered appropriate to put the API support into the kernel tree. This seems like a rule which could use a tiny bit of fine-tuning
Last edited by bridgman; 06-06-2009 at 01:27 AM.