If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Actually yeah, I expect the distributions to make sure that the software they ship works correctly, and I don't know how they managed to get the intel update in without noticing that KWin won't run compositing with it.

It would be nice if Mesa guys tested with KWin and KWin guys tested with Mesa, but ultimately, this is the job for the distros. Gentoo had blocked KDE versions for a long time because of missing KDEPIM and some issues people had with older versions of KMail running with new libraries, that's what I expect a distro to do. If a certain combination of software breaks, don't ship it.

Comment

KWin uses relatively more driver features than Compiz, and uses features which were only recently implemented in the drivers. That resulted in some pain for a while, and the pain will probably continue for a while longer until the two components and communities "get used to each other", but the same thing happens in many places every day.

Once again, the problem is that the feature were working just fine for several releases of both KDE and Mesa, and then later changes to Mesa broke features that had been working. Twice.

If this had been an issue with kwin implementing something that wasn't working in drivers then people wouldn't be so upset. The problem is that the features were working just fine, and then Mesa devs changed drivers in such a way that they broke what had been working. And they did it twice, no less, the second time knowing that kwin was relying on what they were changing.

If this had been an issue with kwin implementing something that wasn't working in drivers then people wouldn't be so upset. The problem is that the features were working just fine, and then Mesa devs changed drivers in such a way that they broke what had been working. And they did it twice, no less, the second time knowing that kwin was relying on what they were changing.

I don't think many would agree with your "knowing that kwin was relying on what they were changing" statement.

Comment

Yep, and if it turns out os drivers cause cancer I will switch too. Neither is likely.

I'm not so sure about this. I can't even logout without crash in Kubuntu 11.04beta2. I was pointed it's a graphic drivers fault and I'm using radeon. There are some applications like Stellarium, Google Earth and Celestia which flickers badly in KDE.

The point here is that the focus on this particular issue is making everyone think there is an unusual systemic problem here when in fact the same problems exist all over the open source community and for better or worse distros are expected to deal with them and prevent upstream compatibility issues from affecting end users.

KWin uses relatively more driver features than Compiz, and uses features which were only recently implemented in the drivers. That resulted in some pain for a while, and the pain will probably continue for a while longer until the two components and communities "get used to each other", but the same thing happens in many places every day.

Can the situation be improved ? Absolutely. Whoever is responsible for managing the entire GNU/Linux/X/Mesa/Gnome/KDE/... stack is obviously not doing their job well enough. Oh wait, there *is* nobody responsible for that other than some folks at distros responsible for making *their* combination of components work together and some technical leaders trying to drive improvements into the entire stack... maybe that's the real problem here ?

If we want components to work together then they need to be planned and managed together from day one, and right now the incentives don't encourage that kind of behaviour. Beating on individual development communities after the fact is not going to help, although it is probably more fun than television, and is more likely to just harden positions and reduce communication in the future.

Kwin development is only one of the problems. It depends what are floss driver developers priorities. According to replies Marting got, it seems KDE's far away on the list from some reason. If those devs are paid by Red Hat or Novell to care mainly about Gnome it's not only about communication. They'll make care the drivers will be working well with Gnome, but nobody will force them to care about KDE. I'm not paying them, so I can't demand. I can just point I don't like what they're doing.

Comment

Once again, the problem is that the feature were working just fine for several releases of both KDE and Mesa, and then later changes to Mesa broke features that had been working. Twice.

If this had been an issue with kwin implementing something that wasn't working in drivers then people wouldn't be so upset. The problem is that the features were working just fine, and then Mesa devs changed drivers in such a way that they broke what had been working. And they did it twice, no less, the second time knowing that kwin was relying on what they were changing.

I don't think many would agree with your "knowing that kwin was relying on what they were changing" statement.

They apparently had told kwin developers that they shouldn't be using the driver strings, although without providing an alternative. They wouldn't have said that if they didn't know kwin as using them. And then they changed the driver strings.

Comment

They apparently had told kwin developers that they shouldn't be using the driver strings, although without providing an alternative. They wouldn't have said that if they didn't know kwin as using them. And then they changed the driver strings.

Since they had already provided KWin notice that they were doing it wrong, why do they have to stay up to date on all of the downstream code and follow up to make sure that KWin was really updated? You seem to think Mesa devs have nothing better to do so they might as well follow up on every project that might use their libraries. Mesa served notice that KWin was doing it wrong; at that point KWin should've fixed their code OR asked for clarification. Neither happened.

People have a hard enough time keeping up with their own code to have to consider how people downstream might be misusing their code.

Comment

Many of the issues that came up in 4.5 were with kwin features that had been working fine for several releases by that point.

Just to be clear, as I understand it this is what happened:

KDE had a bunch of OpenGL 2.x code, that worked correctly on the proprietary drivers.
It never got hit from Mesa, because the drivers only supported GL 1.5.

Then when KDE 4.5 was shipped the distros started including Mesa drivers than enabled GL2.x functionality, and the code that was previously working suddenly got hit by Mesa and there were a bunch of errors.

I'm not sure what the best solution to that situation would have been. Obviously the drivers needed to enable 2.x at some point, and it was probably inevitable that there would be some breakage when that occurred. There probably needed to be some more communication from the driver developers and/or distributions towards KDE that this was happening and needed to be tested, and apparently that didn't happen. You could also say that Martin needed to be more proactive in testing newer Mesa code, which would have shown the problem to him in advance of the actual releases. There's plenty of blame to go around IMO.

Comment

Why does Martin do the OpenGL checking the "incorrect way? Well, it's because Mesa doesn't support doing it the correct way. So why is that? It's because apps wouldn't check for OpenGL extensions individually like they were supposed to do. Instead, they would just check for some OpenGL version (e.g. 2.1) and then refuse to run when the driver didn't advertise full 2.1 support, even when the app only used a few OpenGL 2 extensions that the driver actually did support. So the Mesa devs decided just to advertise full 2.1GL support for the benefit of their users, and Martin decided to to parse the renderer string instead of just outright blacklisting open-source drivers for the sake of his users.