Honestly, if AMD just put out a roadmap stating when they thought all the various problems with fglrx might be solved, that would be a good start. Right now it's like Flash - there are so many problems and no indication about whether AMD even intends to fix them, let alone whether it's under progress now or scheduled for 5 years later.
I'm quite sure the drivers don't have as many problems as people keep suggesting. I'll note that many will say "it's got so many problems, blah blah blah", but few actually state any problems, and of those that do, it's rarely a problem but rather a missing feature.
So I imagine AMD says dilligaf a lot.
What does fglrx need for people to take it seriously?
Video accelerated decoding needs to work, out of the box, with no fiddling and no errors. And no breaking when a new driver comes out each month.
xserver no-backfill. Need i say more?
Supporting new versions of x and the kernel in less than 6 months. Heck, nvidia is supporting this stuff before they're even released.
constant crashes when watching video. ok, this one might already be fixed, i haven't actually used fglrx in a while because the oss drivers are working better for me.
This is analogous to the Flash situation, to me. Flash mostly works, it's just that it does so rather poorly and there's no indication that things are going to get better any time soon.
Video accelerated decoding would be nice - but do bear in mind that AMD have never officially released it, and don't support it. So it's strictly something missing at the moment, albeit something that a good many would like.
xserver-backfill - yep, you'll need to say more (at least for me to understand). I can't remember too much about that as it was something that never affected me.
Not had a problem with video in a long time here. Used to have issues with xv (crashes typically), but it's worked fine for well over a year now (for me at any rate). Of course, I don't use much eye candy for my desktop (e16 user, occasionally e17) so I may well not encounter some of the problems that others have.
The xserver backfill thing was in response to terrible desktop performance the driver had when maximizing windows and doing other wm tasks. I'm not sure AMD ever even officially acknowledged the problem, but bridgman told users to apply the no-backfill patch to the xserver to fix it. Last i heard, it was still an issue for fglrx, and the xserver folks weren't going to accept it upstream because they viewed it as a hack to work around a fglrx-only bug that would end up affecting all the other drivers which already worked correctly. Never heard any more from amd besides applying that patch, and that they were "looking into it". That was probably a year ago now.
I'm not sure if I ever "officially acknowledged the problem" either (I'm not the official problem-acknowledger ;)) but we sure talked about it for a long time. Here's the background one more time :
1. The "no backfill" code had been shipping in most distributions for years in order to improve performance on all hardware - I think it was first added to Fedora then spread across to other distros as well. Looking back, we now know that all hardware needed the patch because all hardware ran with XAA acceleration at the time, and XAA did not accelerate the "backfill" (copying big chunks of data from video memory to system memory) which was required under certain conditions.
2. Somewhere in late 2008 / early 2009 a problem appeared using Intel hardware, resulting in (IIRC) previously used screen buffers re-appearing on the screen, which could contain sensitive data. Disabling the "no-backfill" code was found to eliminate this problem, so the "no backfill patch" was flagged as a security problem and removed from the next round of distro releases. This resulted in the delays you know about when running a compositor and unminimizing windows etc... on some hardware (mostly ours).
3. Much debate and finger-pointing ensued. In the end, it turned out that removing the long-standing "no-backfill" patch caused performance problems when running with XAA acceleration and compositing but not with EXA or other similar acceleration schemes. Note that since IGP parts use a common pool for system and video memory the copy can sometimes be "free" on that hardware but not on discrete GPUs.
4. The root cause seemed to be a discrepancy in the specs for X and related extensions, in the sense that a literal interpretation of the spec resulted in what many called non-intuitive behaviour, ie a large copy of data down to system memory, which was then promptly over-written and discarded. There seemed to be agreement on the problem, but it wasn't clear how to fix the problem other than making that largely redundant copy run faster, which apparently had come for free as drivers moved from XAA to other acceleration APIs.
4. As a short-term fix, Felix implemented a "no-backclear" patch (no-back*clear* rather than no-back*fill*) which returned performance to where it was when distros were all shipping no-backfill, but without the side-effects on Intel (and apparently other) hardware.
5. As a medium-term fix, the 2D acceleration API on fglrx is going to be changed to one which can accelerate the backfill operation, so we'll still be doing the redundant copy (just like all the other hardware vendors) but at least will be doing it quickly. This isn't a real solution, but it works for now and at least everyone will be dealing with the problem in the same way.
6. The real solution, if it ever happens, will involve some TBD changes to the X and extension specs to eliminate the largely wasted copy (maybe something similar to Felix's no-backclear patch), or maybe just to live with it and flag the backfill copy operation as a core function which needs to be accelerated (or at least fast) on all drivers.
this thread. Takes no more than a minute, fglrx builds fine and works like a ch... ah... nevermind ;). Hope this will help you.