Originally posted by pingufunkybeat
View Post
Announcement
Collapse
No announcement yet.
Intel Mesa Gives Problems With KDE's KWin, Again
Collapse
X
-
Originally posted by locovaca View PostWhy is it Intel's responsibility to test KDE's code out with their driver?
Comment
-
Originally posted by locovaca View PostWhy is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?
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.
Comment
-
Originally posted by pingufunkybeat View PostMarek, how would you test correctly if a driver provides appropriate functionality?
It is known since the last KWin fiasco that you can't trust the advertised functionality,
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
Originally posted by pingufunkybeat View Postand checking for direct rendering is also a hack which doesn't even work anymore. Blacklists caused their own set of problems, and if there is no check, KWin will crash all the time, like 4.5 did.
What is the correct way to check this?
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.
Comment
-
Originally posted by marek View PostAs far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.
Regardless of whether it was reported correctly to the Mesa devs, or tested at the right time before releasing, which is a different issue.
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.
Comment
-
Originally posted by marek View PostThe best way is to communicate and do the job right.
The Kwin devs should assume everything works
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.
Comment
-
Originally posted by marek View PostMost games ran beautifully.
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.
Comment
-
Originally posted by roentgen View PostHell of test you did there. Especially when it comes to Linux.
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.
Dave.
Comment
-
Originally posted by airlied View PostMust be the test we added for noticing if the user has posted dumb stupid shit to phoronix and slowing his machine down.
Dave.
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.
Comment
Comment