Announcement

Collapse
No announcement yet.

Martin Takes His Mesa Issues To The List

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

  • #31
    It depends, when you look at debian i would not say that sid is the best branch. It is ok, when you are experienced and you can handle the things which usually happen. But is a pain to support lots of others which ran in into problems. I did that and it was no fun at the end. Also debian got maybe a bit outdated too due to the long freeze. I do not use arch (or gentoo) however, but i prefer the way of selected backports. I have got no problem when there would be a kde 4.x backport repo. It just has to install without problems. It is basically a good thing when you have got a stable system you can base your updates on. Of course not every package will be the latest one possible, but is that really needed? I had to patch a handfull of lines to compile nouveau with xserver 1.7. I get most likely the same speed as when you run 1.10, so what did you gain?

    Comment


    • #32
      Originally posted by RagingDragon View Post
      I assume Martin has already updated the KWin compositing whitelist to include the new Intel driver. So biggest problem here seems to be that Ubuntu (and perhaps other distributions) are unlikely to provide the KDE update in a timely manner?

      Also, drivers lying about their capabilities should be regarded as a critical driver bug. I'm not sure that it's reasonable to expect a window manager to handle that gracefully. Again I assume that driver bug was fixed fairly quick, and that what made it a big problem was that Ubuntu (and perhaps other distributions) were unlikely to provide the driver update in a timely manner.

      To me, these are just more reasons to prefere rolling release distributions. They get updates and fixes to their users as soon as possible.
      No he hasn't, and he's said he won't do so in a stable KDE release because of the possibility of regressions. So he's waiting for KDE 4.7.

      Ubuntu has fixed the issue by patching Mesa to add GEM back into the intel driver string. Apparently the Fedora guys want an actual fix, so it's not yet clear if they will create the patch themselves or if KDE will make one for 4.7 and Fedora will just backport it.

      Comment


      • #33
        Originally posted by TheBlackCat View Post
        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.
        I think they did say - it's whatever projects they are actually being paid to support. I'm certain there are some Red Hat or other devs being paid to make sure that Gnome Shell or Compiz are working. Apparently none of the distros have ponied up to make any developer responsible for KWin support.

        Comment


        • #34
          Well maybe they are lucky and everbody complains about unity or gnome shell so more ppl will use kde

          Comment


          • #35
            Originally posted by kraftman View Post
            This is probably true and this makes me thinking if I shouldn't just trow my card away, because I don't care about gnome at all. If open source drivers I'm using are made for gnome they're useless for me. I didn't have very good experience with nvidia blobs, but at least nvidia cares about KDE and I noticed most of the nvidia users chooses KDE. If os drivers won't be playing good with KDE I'll simply switch to something better. I guess many people will do the same.
            ???

            The open source drivers aren't *made* for gnome, it just seems that relatively more of the developers working on the drivers use gnome than use kde. Similarly, the developer working on kde (actually kwin, I guess), happens to have an NVidia GPU in his system, so KDE gets tested more on NVidia hardware with the proprietary driver.

            Using the same logic you could say that KDE doesn't care about anything besides NVidia proprietary drivers, but that wouldn't be true either. Beating up on either of the developer groups isn't going to change anything - they're all working really hard and making difficult choices re: where to spend their limited time.

            What might be a better use of time is trying to loosely coordinate release schedules for drivers and "close to driver" projects like compositors, and organizing some "power user" testing of driver and compositor release candidates against each other before either locks down for good. There are enough volunteers trying and testing new code to make this fly but if we could guide the testing towards the appropriate *combinations* of code we could get a lot more benefit from the same work.

            Comment


            • #36
              Originally posted by smitty3268 View Post
              I think they did say - it's whatever projects they are actually being paid to support. I'm certain there are some Red Hat or other devs being paid to make sure that Gnome Shell or Compiz are working. Apparently none of the distros have ponied up to make any developer responsible for KWin support.
              The exact words were:

              "'Mesa is our most important upstream and KWin (together with Compiz and Mutter) are your most important downstreams.' is not even close to be true. They're very important, but they're not even close to be the most important."

              When he said "They're", it looks to me like he is referring to KWin, Compiz, and Mutter. In other words, no window manager is "even close" to being their top priority. So my question still stands: if they aren't concerned with window managers, then what are they concerned with?

              I should also point out the next email said:

              "Please understand that mesa is also a community driven project and many of the contributions (especially for hardware drivers) come from volunteers, too. "

              The idea that their priorities are set by the companies paying full time developers while at the same time saying it is a community-driver project with lots of contributions coming from volunteers seems contradictory to me. Even if there a bunch paid developers, if it is a community-driven project they shouldn't be able to set the direction for the rest of the community. So if the paid developers are controlling things then there either aren't that many volunteer developers or the community it controlled by the paid developers. You can't have it both ways.

              Comment


              • #37
                Originally posted by bridgman View Post
                Similarly, the developer working on kde (actually kwin, I guess), happens to have an NVidia GPU in his system, so KDE gets tested more on NVidia hardware with the proprietary driver.
                He has several systems, including both NVidia and Intel cards.

                Comment


                • #38
                  Originally posted by TheBlackCat View Post
                  He has several systems, including both NVidia and Intel cards.
                  True, but if you read the email you'll see that he is not able to run the evolving open drivers on them for a variety of reasons, most of which boil down to real-world time limitations.

                  Comment


                  • #39
                    Originally posted by bridgman View Post
                    ???

                    The open source drivers aren't *made* for gnome, it just seems that relatively more of the developers working on the drivers use gnome than use kde. Similarly, the developer working on kde (actually kwin, I guess), happens to have an NVidia GPU in his system, so KDE gets tested more on NVidia hardware with the proprietary driver.
                    The point is they test drivers if they work with gnome, but it seems they don't do the same when comes to KDE. KWin developer at least tests some drivers on different platforms (not that much, though) thus he's able to make some blacklists.

                    Using the same logic you could say that KDE doesn't care about anything besides NVidia proprietary drivers, but that wouldn't be true either.
                    And this is not true. If he would care only about nvidia there won't be any white and blacklists.

                    Beating up on either of the developer groups isn't going to change anything - they're all working really hard and making difficult choices re: where to spend their limited time.
                    I'm not able to change a thing and devs are free to do what they want. I simply said what I think. If os drivers will be crashing in KDE I'll simply switch.

                    Comment


                    • #40
                      Originally posted by kraftman View Post
                      I'm not able to change a thing and devs are free to do what they want. I simply said what I think. If os drivers will be crashing in KDE I'll simply switch.
                      Yep, and if it turns out os drivers cause cancer I will switch too. Neither is likely.

                      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.

                      Comment


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

                            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

                                Working...
                                X