Announcement

Collapse
No announcement yet.

Martin Takes His Mesa Issues To The List

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    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


    • #42
      Originally posted by bridgman View Post
      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.

      Comment


      • #43
        Originally posted by TheBlackCat View Post
        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.
        Just curious, what was the first time ? All of the earlier discussion I saw was related to driver features which were just in the process of being implemented.

        Originally posted by TheBlackCat View Post
        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.
        Test signature

        Comment


        • #44
          Originally posted by bridgman View Post
          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


          • #45
            Originally posted by TheBlackCat View Post
            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.
            No, that's pretty much just wrong. Please read the (entire) thread at http://lists.freedesktop.org/archive...il/006870.html. The commit in question is http://cgit.freedesktop.org/mesa/mes...2d6991a7385b59.

            Comment


            • #46
              Originally posted by bridgman View Post
              Just curious, what was the first time ? All of the earlier discussion I saw was related to driver features which were just in the process of being implemented.
              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.

              Originally posted by bridgman View Post
              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


              • #47
                Originally posted by TheBlackCat View Post
                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


                • #48
                  Originally posted by TheBlackCat View Post
                  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


                  • #49
                    Originally posted by kraftman View Post
                    Novell to care mainly about Gnome it's not only about communication.
                    Feel free to visit the openSUSE KDE room, lots of paid devs there all the time fixing all kinds of KDE issues (actually seems to see a lot more activity then the Gnome channel).

                    Comment


                    • #50
                      Originally posted by smitty3268 View Post
                      There's plenty of blame to go around IMO.
                      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.

                      Comment

                      Working...
                      X