Senior Member
smitty3268 and the E-Mail sounds like "Do it like we/I want" from Martin Gräßlin. I bet this is the reason why he get this type answers.
> http://lists.freedesktop.org/archive...il/006870.html
Senior Member
Originally Posted by mat69
Maybe because ofOnly that KWin got most of the blame and even for bad communciation ...[1]
The most big changes like this are discussed on the Mailing list.
They don't care about Mesa and they don't test there Stuff on the Free Drivers. Its Sounds like he/kwin test only on the Nvidia Blob.
Senior Member
I agree that certain stuff from Martin needs to change. But instead of taking the opportunity to discuss that with him the Mesa devs chose to flame him, thereby ensuring that nothing changes and we will run into the same problems again.
Mesa devs are not solely to blame, but neither are they blameless. Currently both sides are acting like idiots, and when 1 makes at least an effort at conciliation it's disappointing when that effort isn't returned.
Senior Member
Just to be clear about what i think needs to happen:
Martin needs to stop his stupid "i can't be bothered to test current Mesa code" argument.
Mesa devs need to stop their stupid "i can't be bothered to test KDE" argument.
Both sides need to stop their stupid "everytime something goes wrong start shouting about how much the other side sucks" behavior.
These problems are going to continue until both sides get it together and actually give a **** about their users. Right now they both seem more interested in scoring points.
AMD Linux
This issue comes up every few months. The core problem here is that the KDE devs were writing new code which used OpenGL features that were just being implemented in the open drivers. Nothing wrong with that in principle but it requires fairly close communication between app and driver developers so everyone understands what should and should not work.[1] I wonder if it is good communication to set flags specified in a standard to advertise features ,that are in fact not working right. And yeah I know of the unfortunate situation that some tools require OpenGL X.Y while actually onle few features are really required. I just think that the blame was not fairly distributed.
Most of those issues are in the past now, but one part of the problem will remain more or less forever -- the fact that OpenGL 2.x came out after DX9 hardware was designed but doesn't quite match the DX9 requirements. As a consequence of this, there are multiple generations of cards which can run GL 2.x well enough that users want it enabled (ie want the features advertised) but which can not provide 100% support and never will.
The choices are either to disable GL 2.x features completely (thereby costing users the ability to run a large number of interesting and useful apps) or enable the features and recognize that they are always going to be "implementation errors" when running on DX9 hardware because the hardware doesn't support everything that GL 2.x requires.
Senior Member
Like I said I think the best way would be to pass a flag when asking about advertised features that tells the driver to only say yes if the feature is fully implemented and stable. That way a client could ask for only features that are done and really implemented.
X.Org Developer
I couldn't disagree more. The features were implemented as much as they could be on the given piece of hardware. GLSL is not C. An arbitrary piece of code in GLSL might not work everywhere. That's the reality. Just pay attention to your code and it will pay off.
As for the discussion on the ML, it proves that nobody has the time to test his software with someone else's software. Most people are unpaid and simply don't care. (what would you choose: hacking some drivers or kwin for free, or checking out the chick who lives next door, or maybe playing in a rock band and have some fun?)
Phoronix Member
I have to admit that I lack the knowledge in this regard and was posting what I remembered or thought to remember.
In any case I think we can agree that blogs for sure aren't the correct medium to raise issues. I think they are a good way to inform others (i.e. not the affected devs) of it, but informing should imo ideally not contain finger pointing at all. Still the situation for the users is bad and that should improve one way or the other.
Senior Member
Martin's email to mesa-dev really doesn't paint him in a good light. Interpersonal skills are of utmost important to a project manager and he displays close to none. Plus, his racist remark was very ill-conceived.
In any case, the solution is simple:
(a) write piglit tests to cover kwin functionality
(b) establish minimum version requirements (e.g. kwin 4.7 requires mesa 7.11)
Ranting and panting won't get us anywhere.
Phoronix Member
What kind of racist remark are you talking of?
Imho his mail is indeed way too long and might apear arrogant instead of solution oriented. I doubt that devs who themselves have to cope with rare spare time they can invest in their projects are willing to read long rants in this regard.
Reply With Quote
