Page 2 of 8 FirstFirst 1234 ... LastLast
Results 11 to 20 of 75

Thread: Martin Takes His Mesa Issues To The List

  1. #11
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote 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

    Quote 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.

  2. #12
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote 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.

  3. #13
    Join Date
    Apr 2010
    Posts
    271

    Default

    Quote 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.

  4. #14
    Join Date
    Feb 2009
    Location
    France
    Posts
    309

    Default

    Quote 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...

  5. #15
    Join Date
    Apr 2010
    Posts
    102

    Default

    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.

  6. #16
    Join Date
    Apr 2010
    Posts
    271

    Default

    Quote Originally Posted by Xilanaz View Post
    None the less distributions ship with these (in previous post mentioned) experimental drivers installed by default and users expect a working good looking DE.
    Then the issue is the distribution, not the DE. If a distribution is going to throw crap together without testing it (a development model wholeheartedly endorsed by some distributions for sure), that needs to be on the distribution. KDE is not a distribution, no more than Mesa is a composting desktop environment.

  7. #17
    Join Date
    Sep 2008
    Posts
    989

    Default

    Indeed, it seems like a consensus is attainable:

    Mesa devs: Keep doing what you're doing, but run some piglit tests for KDE now and then to make sure you aren't inadvertently breaking something they rely upon (assuming that they rely upon features that are within scope of the OpenGL standard they're targeting).

    Kwin devs: Take out the whitelisting/blacklisting stuff, and check for extension availability using the standard GL calls. You can also parse the first few characters of the version string because they are required by the standard to report the core GL version there; it's an easy out if it's not >= what you need. But don't rely on the rest of the version string. Instead, just make your best effort to use features that work with reasonably modern versions of Mesa on most drivers, and report bugs when you find that something advertised doesn't work.

    Distributions that ship KDE4: Before you release, do a fresh install of your distro, using your distro's version of Mesa, and boot up KDE. Do not install the binary drivers. (If you don't have a card that works with Mesa, buy one, or find a reliable community member who has one and can test on your behalf.) Assuming that you have a working, hardware-accelerated mesa stack: Do you get compositing? No? Then: either figure out whether to upgrade or downgrade either KDE or Mesa to make it work, or post on the ML that you need to make Mesa version XYZ work with KDE version XYZ, and ask for an approach or a patch. The fact that distros don't want to provide or request workarounds is irrelevant: the fact remains that it's their software distribution and the responsibility for getting it working is ultimately on them, at the end of the day.

    So KDE and Mesa devs will make their best effort to be compatible, but due to the lack of manpower neither side can afford to manually test the software. They must both operate under the assumption that >90% of users will never compile their own version of the software manually, and those who do so are accepting the onus of either reporting bugs or fixing things. Then the distribution must realize that they need to test their software as much as possible, because it's hardly a foregone conclusion that slapping a bunch of packages together will "just work" -- that's why distributions exist!

    The upstreams here are doing things mostly right, and users who expect all upstream code from all projects to integrate flawlessly with no hacks are living a pipe dream. Here I say "users" to mean both individuals compiling stuff from source, as well as distributions. The difference is that, we assume, distributions contribute quite a lot of testing, integration and hacking to the equation, to smooth out any wrinkles encountered from upstream. This might raise the bar relative to what some distributions provide, but clearly if you look at RHEL or Debian or SUSE, this kind of rigorous testing is known to happen with some existing distros. And when it doesn't happen, the frequency of bug encounters is much higher across the board, not just in Mesa and KDE.

    If we want to improve the out of the box experience for non-technical end-users (and I think everyone agrees this is a good thing), the main responsibility is on distros. Distros fill an essential, indispensable role in converting "raw" free/open source software into a polished product. We should all recognize what a great contribution they make, and encourage the distros that don't live up to the quality bar to improve.

  8. #18
    Join Date
    Feb 2011
    Posts
    1,238

    Default

    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.

  9. #19
    Join Date
    Jul 2008
    Posts
    69

    Default

    Quote Originally Posted by allquixotic View Post
    Indeed, it seems like a consensus is attainable:

    Mesa devs: Keep doing what you're doing, but run some piglit tests for KDE now and then to make sure you aren't inadvertently breaking something they rely upon (assuming that they rely upon features that are within scope of the OpenGL standard they're targeting).

    Kwin devs: Take out the whitelisting/blacklisting stuff, and check for extension availability using the standard GL calls. You can also parse the first few characters of the version string because they are required by the standard to report the core GL version there; it's an easy out if it's not >= what you need. But don't rely on the rest of the version string. Instead, just make your best effort to use features that work with reasonably modern versions of Mesa on most drivers, and report bugs when you find that something advertised doesn't work.
    This is not possible. A few months ago, the Kwin developers were complaining about another major FUBAR situation with Mesa, but I think it was related to the radeon drivers. The drivers would report that they supported various extensions but didn't and would subsequently break Kwin when it tried to use those extensions. Hence, the crude black/white lists. I also seem to remember that there were situations where even checking for capabilities could crash some drivers.
    They simply can't check the driver for extension support because the open-source drivers frequently lie about what is implemented.

    Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.

    Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?

    Open-source developers, stop changing stuff just to change it. It breaks other code.

  10. #20
    Join Date
    Dec 2009
    Posts
    76

    Default

    Quote Originally Posted by jbrown96 View Post
    Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.

    Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?
    Because it is a lot more useful for a lot of people the way it is now. Please consider thinking before posting dumb shit. Try to get some clue on what you are talking about and then come back.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •