That's like concluding we will support UVD in the open drivers because we support most of the other blocks. Reasonable if you don't look too closely.
But very clear![]()
Not AMD fault, but AMD add workaround to driver anyway.Where we may look at XBMC crashlog and core dump?That was changed.
Anything else?
Well as long as fglrx runs you can use the aticonfig command to enable h264 l5.1. but xbmc fernet menta branch is currently everything else than stable - especially when you dont use it fullscreen only but windowed or when you switch between both ways using \. do you try xbmc fm git code often?
I find it curious that the AMD people imply they have some inside info on Intel's discrete efforts. What makes you think the hypothetical GPU would not be open, or that Knight's Corner will not have the rest open-sourced too once it actually starts selling a bit?
If you're referring to the currently not-perfect GCC support for it, I find it likely that will change in the future.
That is what I am referring to. My HD7xxx based card. When my HD4xxx card failed I needed to upgrade. Now with a brand new card with less power than my old GForce3 not because of the hardware but the drivers. The blob might be the greatest thing ever on RedHat5. Not sure. But it is useless on FC18. Sure AMD doesn't want to support some thing so bleeding edge and I don't blame them. But no one is asking them to. What people are asking for is documentation. With out it the HD7xxx is just one step up from a software frame buffer device. I don't understand why the AMD people are shocked that Linux people might not want to pay $$$ for bleeding edge features they are never going to get to use. Actually most things like audio over hdmi isn't exactly bleeding edge any more. Releasing documentation should have been of the process of coming to market, not an after thought.
Everything about this answer is wrong. Especially the attitude.
It IS AMDs fault if it is the only driver that does not work in gnome3.
I don't have that crashdump anymore, it's been a while since then, but I do not doubt that you can still get it to crash if you try.
Yeah it was maybe changed, ignoring the fact that VDPAU worked fine out of the box and we're still struggling with xvba and that you have to do some very badly documented things and use some very bleeding edge software to get it to work.
Last edited by barkas; 07-01-2012 at 04:01 AM.
Do you read comment 14 of this bugreport carefully?
No, I doesn't. I just said "That was changed".
This is also going to change. When XBMC-XvBA Team patches will be accepted by upstream ffmpeg, any ffmpeg-based application will be capable of using XvBA.
HWUVD_H264Level51Support probably require wide testing before going to be enabled by default.