Announcement

Collapse
No announcement yet.

Martin Takes His Mesa Issues To The List

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

  • Martin Takes His Mesa Issues To The List

    Phoronix: Martin Takes His Mesa Issues To The List

    Over the weekend there was a rant by Martin Grlin, the lead developer of the KWin compositing window manager for KDE, about Intel's open-source driver breaking. This is the second time in recent times that the driver has outright failed with KDE, which threatens the Intel KWin support in Ubuntu 11.04, but this time it's over the OpenGL renderer string being changed and KWin using that to determine direct rendering support. Martin has now written a very lengthy e-mail to the developers of Mesa...

    http://www.phoronix.com/vr.php?view=OTM1NQ

  • #2
    I find it strange that you call Martin's blog a rant when you yourself have written articles ranting about problems you've been suffering from, rather than reporting issues to bugzilla or the developers

    Care to explain the difference?

    Comment


    • #3
      KWin works well on nouveau, at least here on all the cards I have. But I only use mesa from git.

      I've had loads of errors from kwin trying to guess "it works" or "it doesn't". Why doesn't it solely rely on the supported extensions reported by the driver?
      If they want, they can give hints to users that it may not work, but kwin's current system is a pain and often disables compositing even though it has been working well for almost a year.
      One last thing, when I set "disable checks", I *really* want to disable checks.

      As for a solution, why don't you(kwin devs) advertise a "job" for new comers? I'm sure more than 3 people are willing to work on KWin and I'm sure QA is a nice starting point

      Comment


      • #4
        Originally posted by MPF View Post
        I've had loads of errors from kwin trying to guess "it works" or "it doesn't". Why doesn't it solely rely on the supported extensions reported by the driver?
        Because these used to crash KWin and result in an unusable KDE session, even though they were advertised as working.

        Comment


        • #5
          Originally posted by pingufunkybeat View Post
          Because these used to crash KWin and result in an unusable KDE session, even though they were advertised as working.
          So, let's hide the bugs then? If no-one can do QA, users should. Bugs don't get resolved by masking them

          Seriously, I would love that open source driver could be relied on, but it isn't the case now. As said Jerome Glisse, composition could be disabled by default and it would be up to users to deactivate the checks and report bugs.

          Comment


          • #6
            Originally posted by MPF View Post
            So, let's hide the bugs then? If no-one can do QA, users should. Bugs don't get resolved by masking them
            No, of course they should be reported!

            But the problem still remains -- people are stuck with a broken system for 6 months at a time because the distributions ship KWin with drivers which crash when KWin uses them.

            Actually, I'm surprised that none of the distributions notice this. They should have the manpower for QA before something like a new Kubuntu or Fedora version is released.

            I think that piglit tests are a good direction in any case.

            Comment


            • #7
              Originally posted by MPF View Post
              So, let's hide the bugs then? If no-one can do QA, users should. Bugs don't get resolved by masking them

              Seriously, I would love that open source driver could be relied on, but it isn't the case now. As said Jerome Glisse, composition could be disabled by default and it would be up to users to deactivate the checks and report bugs.
              Yes because Martin doesn't get enough hate directed at him already

              I'm sure he'd be very popular if he simply disabled compositing for everyone including the binary driver users too

              Comment


              • #8
                Originally posted by FireBurn View Post
                Yes because Martin doesn't get enough hate directed at him already

                I'm sure he'd be very popular if he simply disabled compositing for everyone including the binary driver users too
                Why would he disable by default compositing on binary drivers? You can't fix the proprietary drivers, you need to deal with it.

                No, seriously. The only thing I care about as a dev is, "let things go wrong horribly so as we can fix them". As a user, I like default settings to be safe but I want to be able to try things.

                The best solution for me really is to deactivate what is unstable (be coarse) and let users activate it if they want. This way, they know it is their fault if it doesn't work (and they know what to do to make it work again), not kde's. Then, they'll focus their hate on the open-source drivers and hopefully fill bug reports.

                What do you think?

                Comment


                • #9
                  Originally posted by MPF View Post
                  The best solution for me really is to deactivate what is unstable (be coarse) and let users activate it if they want. This way, they know it is their fault if it doesn't work (and they know what to do to make it work again), not kde's. Then, they'll focus their hate on the open-source drivers and hopefully fill bug reports.

                  What do you think?
                  In other words you are telling them to disable compositing for every user of open-source drivers?

                  Even if they did that, I can tell you what will happen: the web will be filled with instructions on how to enable it, users will enable it, and it will break. Users will blame kwin twice, once for making them enable it and again for it not working. It will only make users angry twice.

                  You are asking kwin to disable major features for a massive number of users. I don't see that as a viable solution.

                  Comment


                  • #10
                    Originally posted by MPF View Post
                    Why would he disable by default compositing on binary drivers?
                    I assume that they should detect the binary drivers by parsing the OpenGL renderer string and turn it on if a binary version is detected?

                    That's exactly what they do -- compositing works fine with Intel Mesa drivers, until they changed the renderer string, now it's disabled as a precaution.

                    Comment


                    • #11
                      Originally posted by TheBlackCat View Post
                      In other words you are telling them to disable compositing for every user of open-source drivers?

                      Even if they did that, I can tell you what will happen: the web will be filled with instructions on how to enable it, users will enable it, and it will break.
                      So far, this is what I hope indeed

                      Originally posted by TheBlackCat View Post
                      Users will blame kwin twice, once for making them enable it and again for it not working. It will only make users angry twice.

                      You are asking kwin to disable major features for a massive number of users. I don't see that as a viable solution.
                      If they do that, they are wrong and need to be educated about the open-source drivers. Trying to hide bugs never works.

                      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.

                      Comment


                      • #12
                        Originally posted by MPF View Post
                        The best solution for me really is to deactivate what is unstable (be coarse) and let users activate it if they want. This way, they know it is their fault if it doesn't work (and they know what to do to make it work again), not kde's. Then, they'll focus their hate on the open-source drivers and hopefully fill bug reports.

                        What do you think?
                        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.

                        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.

                        Comment


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

                          Comment


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

                            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.
                            You are perfectly right, I didn't tell how to identify the driver too...

                            Comment


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

                              Comment

                              Working...
                              X