Printable View
So far, this is what I hope indeed :)Quote:
Originally Posted by TheBlackCat
If they do that, they are wrong and need to be educated about the open-source drivers. Trying to hide bugs never works.Quote:
Originally Posted by TheBlackCat
I don't know for intel or radeon, but clearly, nouveau is not even polished-enough to accept crashes report (only mis-rendering bug reports are accepted).
People can't expect things to work flawlessly when a driver is experimental.
In other words, create a whitelist of drivers known to work good and only enable effects when one of them is detected? That's exactly the solution they came up with.Quote:
Originally Posted by MùPùF
I think modern Mesa drivers basically work, it's just the older ones that were problematic. The problem that occurred here was Intel changing the driver string which caused it to fall off the list of good drivers being detected.
Then that's an issue with the white listing process, NOT with the driver. In fact, the white listing process WORKED.Quote:
Originally Posted by smitty3268
You are perfectly right, I didn't tell how to identify the driver too...Quote:
Originally Posted by smitty3268
I found Martin's mail quiet informative and I do believe they did what they did with Kwin in KDE 4.5 with the best intension for us the users.
Submitting bug reports is always good but with something like Mesa it means it might be a long long time before the fix ever reaches your DE, so they opted for the blacklist to gives users here and now the best experience they can get.
If something breaks and the users see's Kwin he will blame Kwin and not the fact that some drivers say they can do stuff but in reality they can't.
None the less distributions ship with these (in previous post mentioned) experimental drivers installed by default and users expect a working good looking DE.
What I did find a bit sad in the reply's to Martin is that one person mentioned "Also as said half a year ago, blacklisting features in kwin based on some renderer string is a _very_ bad idea. " to me means they at least knew about it ? So they also knew that changing that string would cause problems ? They could have contacted Kwin dev about the upcoming change ?
Did not really like the cold replies from Mesa people about it at all, but that is just a personal perception from their answers.
Then the issue is the distribution, not the DE. If a distribution is going to throw crap together without testing it (a development model wholeheartedly endorsed by some distributions for sure), that needs to be on the distribution. KDE is not a distribution, no more than Mesa is a composting desktop environment.Quote:
Originally Posted by Xilanaz
Indeed, it seems like a consensus is attainable:
Mesa devs: Keep doing what you're doing, but run some piglit tests for KDE now and then to make sure you aren't inadvertently breaking something they rely upon (assuming that they rely upon features that are within scope of the OpenGL standard they're targeting).
Kwin devs: Take out the whitelisting/blacklisting stuff, and check for extension availability using the standard GL calls. You can also parse the first few characters of the version string because they are required by the standard to report the core GL version there; it's an easy out if it's not >= what you need. But don't rely on the rest of the version string. Instead, just make your best effort to use features that work with reasonably modern versions of Mesa on most drivers, and report bugs when you find that something advertised doesn't work.
Distributions that ship KDE4: Before you release, do a fresh install of your distro, using your distro's version of Mesa, and boot up KDE. Do not install the binary drivers. (If you don't have a card that works with Mesa, buy one, or find a reliable community member who has one and can test on your behalf.) Assuming that you have a working, hardware-accelerated mesa stack: Do you get compositing? No? Then: either figure out whether to upgrade or downgrade either KDE or Mesa to make it work, or post on the ML that you need to make Mesa version XYZ work with KDE version XYZ, and ask for an approach or a patch. The fact that distros don't want to provide or request workarounds is irrelevant: the fact remains that it's their software distribution and the responsibility for getting it working is ultimately on them, at the end of the day.
So KDE and Mesa devs will make their best effort to be compatible, but due to the lack of manpower neither side can afford to manually test the software. They must both operate under the assumption that >90% of users will never compile their own version of the software manually, and those who do so are accepting the onus of either reporting bugs or fixing things. Then the distribution must realize that they need to test their software as much as possible, because it's hardly a foregone conclusion that slapping a bunch of packages together will "just work" -- that's why distributions exist!
The upstreams here are doing things mostly right, and users who expect all upstream code from all projects to integrate flawlessly with no hacks are living a pipe dream. Here I say "users" to mean both individuals compiling stuff from source, as well as distributions. The difference is that, we assume, distributions contribute quite a lot of testing, integration and hacking to the equation, to smooth out any wrinkles encountered from upstream. This might raise the bar relative to what some distributions provide, but clearly if you look at RHEL or Debian or SUSE, this kind of rigorous testing is known to happen with some existing distros. And when it doesn't happen, the frequency of bug encounters is much higher across the board, not just in Mesa and KDE.
If we want to improve the out of the box experience for non-technical end-users (and I think everyone agrees this is a good thing), the main responsibility is on distros. Distros fill an essential, indispensable role in converting "raw" free/open source software into a polished product. We should all recognize what a great contribution they make, and encourage the distros that don't live up to the quality bar to improve.
The Mesa developers said that they don't consider KDE to be one of its most important targets. That makes me wonder: if the first or second most-used X11 window manager isn't one of their most important targets, then who is? They don't say.
This is not possible. A few months ago, the Kwin developers were complaining about another major FUBAR situation with Mesa, but I think it was related to the radeon drivers. The drivers would report that they supported various extensions but didn't and would subsequently break Kwin when it tried to use those extensions. Hence, the crude black/white lists. I also seem to remember that there were situations where even checking for capabilities could crash some drivers.Quote:
Originally Posted by allquixotic
They simply can't check the driver for extension support because the open-source drivers frequently lie about what is implemented.
Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.
Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?
Open-source developers, stop changing stuff just to change it. It breaks other code.
Because it is a lot more useful for a lot of people the way it is now. Please consider thinking before posting dumb shit. Try to get some clue on what you are talking about and then come back.Quote:
Originally Posted by jbrown96