I mean, if people expect KDE guys to test several dozen drivers (and I do), then I'd expect a driver dev to have a quick check whether he broke the second most widely used window manager under Linux.
P.S. It's still wrong to rely on the renderer string, and I still have no better solution for enabling basic functionality on software people expect to just work.
Moreover, the NVIDIA OpenGL implementation is far from being compliant, so if something works on NVIDIA, it pretty much means it might not work anywhere else. I *like* proprietary drivers, but relying solely on NVIDIA ones might lead to frustration as you can see in various Martin's blog posts. Unlike NVIDIA, both Catalyst and Mesa try to follow the OpenGL specification to the letter, even though the spec is sometimes self-contradictory or doesn't make sense.
Further reading on the subject (a little bit more technical): http://www.g-truc.net/post-0348.html
The worst scenarios are:
- Reverting to an older version without telling anyone and hoping the problem will be fixed in the next version (it won't).
- Blacklisting the software without telling anyone (again, it won't get fixed until either a developer runs into it or a user reports it). And don't forget to make a blog post about it to piss off everybody else.
As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.
Regardless of whether it was reported correctly to the Mesa devs, or tested at the right time before releasing, which is a different issue.
But some people don't use modules. And DRI2 is only used by open drivers, as is exposing stuff through sysfs. Perhaps it's better than grepping the renderer string, but it's bound to be considerably more complicated and is also bound to change between driver versions, leading to complex logic.As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.
I don't know of a single, reliable way of detecting what the driver can actually accelerate reliably. Ideally, they would all accelerate everything reliably, but unfortunately this is not likely to be the case soon.
That's what they did for 4.5, and it didn't turn out very well.The Kwin devs should assume everything works
Definitely. However, often the response is "fixed in latest git" which doesn't really help the KDE devs much. They have to work with older drivers that are actually being shipped in distributions, or people complain. And I don't think it's reasonable to force the distros to always ship the latest git drivers either.and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.
I think everyone can agree that they way KDE is parsing that string is hacky, but I think they have a point complaining here. Why would Intel change the userspace API (even if it's a hack, they know people are using it) like that in a point release which is supposed to be bugfixes only? Or at least that's what i thought they were meant to be. Just wait for 7.11 to come out. There also wouldn't have been an issue if the change hadn't occurred right before an Ubuntu release but right after a KDE release - presumably they were trying to sneak some fixes in for Ubuntu, and managed to completely break the other desktop as a result. It doesn't really matter who's to blame at that point, all the user knows is they updated a package and everything broke. That shouldn't happen in a point release, IMHO.
Maybe we should all ditch desktop environments and find a way to run apps from the CounterStrike console.
PS: running radeon here and all I see is degraded performance with every Mesa / Xorg / kernel upgrade. Both gnome3 and kde.
Still, wouldn't you agree that a proper testing procedure before releasing a "stable" release would be: 1. launch Gnome + compiz, 2. launch Gnome + Mutter, 3. launch KDE, and test to make sure all continue to work? And if not, email the project in question to try to figure out why a stable release broke something?
I think much of the frustration here is coming from the fact that a project like Compiz or KDE are used by about 50% of users. Even the most popular game is probably in single digits. So it seems like more attention should be given to one rather than the other, and it seems like the opposite is actually true.