[gradinaruvasile]

I just want to say thank you for posting such a great howto. I was able to get this working on my main HTPC last night running Debian (Jessie).

CPU: AMD A8-5500 APU
GPU: [AMD/ATI] Trinity [Radeon HD 7560D]

xbmc gotham alpha9 running vdpau on my video sources w/ no artifacts or issues at all (yet). No frame drops and uber-low cpu usage!

Thanks so much!

I have the same APU and i too run Debian Jessie (64 bit). I never had artifacts or significant issues like the people around here.
But i compile everything from git myself from the kernel to mesa and xbmc too.
May be just this igp works better with oss radeon (it had issues with kernels 3.11 and up to 3.12 rc4 with random system freezing but since it was smooth sailing).
Or is the distribution ? (couldn resist ).
Seriously, this APU works very very well with radeon, not just in xbmc but in games too. And it doesnt overheat even with the tiny default cooler.

Hi Guys,
I have an A10-5700 that is very close to your APU-
I'm still running on Lubuntu 12.10 with patched radeon drivers and XVBA.
When I read success stories, I'd wish to get details, as I'll be forced to upgrade soon.
May you please explain your installation step-by-step? Or pointing to the instruction and explain if you did exactly what is written or not.
Even via PM if you don't want to do that within the thread.

Thanks,
Claudio

Well i did this independently from xbmc, the idea was to get rid of fglrx and use the open drivers. The introduction of the dpm code was the perfect opportunity since the oss driver wasnt worth a damn on APUs before it.
The theory is simple: i cloned the gits for kernel, drm, mesa, glamor (optional) llvm+clang, libclc (for opencl, nothing to do with xbmc), xf86-ati then compiled them. After that i built .deb packages from them then installed.
Now, all the above while its simple in theory it can be complicated when you actually have to do it. You need tons of dependencies and if you have 64 bit system you have to compile a version for 64 bit and another for 32 for the user space components and tackle the dependency hell related to non-multiarch dev libraries. It also involves the creation of deb packages that overwrite and take ownership of libraries from other packages.
The bonus of this approach is to have a reference implementation of the oss stack.
I dont recommend doing it unless you have time to experiment, know how building from source works and how to recover a broken system from command line. I learnt all of this from bits and pieces of docs from the net. Dont expect to be bailed out by anyone else if you mess something up.