[Mesa-dev] KWin and Mesa

Henri Verbeet hverbeet at gmail.com
Tue Apr 19 19:32:25 PDT 2011


On 19 April 2011 16:52, Martin Gräßlin <mgraesslin at kde.org> wrote:
> Hi Mesa-devs,
>
> yesterday I published a rant about Mesa breaking KWin and given some
> comments on Phoronix Forums it seems like there is the wish for more
> communication between our development groups and so I want to start it. Please
> note that I am not subscribed to this mailing list, so please keep me in CC (I
> might not be able to reply this week at all). It is my wish to never have to
> rant about the state of Linux drivers any more and that I never have to see
> Mesa breaking KWin again.
>

I think there are a couple of points here, some of them already made
by others. Note that the following is mostly just how I personally see
things, not necessarily what anyone else thinks.

First, there's the specific issue your blog post talks about. While I
understand the issue, and can sympathize somewhat, I essentially think
you're just wrong there. (Yeah, I can be direct too.) It's perhaps
unfortunate that this change happened on a minor release, but the
basic issues are that blacklisting / whitelisting drivers is just a
bad idea, and you can't depend on renderer strings being stable. If
you do it anyway, it's going to break, you get to keep all the pieces,
and you can't blame the drivers.

In the more general case, I think hacking around driver bugs is about
the worst way to deal with driver bugs in GL applications. In the best
case you're just removing an incentive to fix the bug, but it's more
likely you just end up creating fragile code or depending on the bug
somehow. IMHO it's better to just direct users to the appropriate bug
tracker in those cases. You'll get some flak for that, but it's worth
it in the long term. Of course the best way would be to work on fixing
the bug in the upstream project, but I realize that may not always be
practical.

Note that I think distributions have some role to play here as well. I
think it's just about as unreasonable to expect driver developers to
test with every application as it would be to expect KWin developers
to test with every possible hardware / driver combination. (And you
can't say "My application is more important." either. You're going to
find plenty of users that would gladly have us e.g. completely break
KWin to make StarCraft 2 run faster, and viceversa.) Realistically
speaking we'll have to depend on users / testers testing with
development versions to find bugs before releases. If nobody reports
bugs that either means nobody noticed or nobody cares. An important
part of what distributions are supposed to do is making sure things
work well together, so I don't think it's all that unreasonable to
expect them to do that kind of testing and report / fix bugs where
appropriate. If it does come to the point of writing hacks (pending a
proper fix) it's probably also more appropriate for a distribution to
carry those than KWin.

Something else. Blogging is all modern and all, but it's really not
the most constructive way to make things actually happen. In fact, I
could certainly imagine this specific blog post causing some
resentment. In general, for specific bugs / regressions, please just
create a bug report, preferably with a small test case or even a
proposed patch. For more general issues posting to the mailing list or
just talking to people in IRC (#dri-devel) tends to work best. If you
really consider Mesa your most important upstream, it's probably a
good idea to be on the mailing list and IRC anyway, just to be aware
of what's going on, even if you end up not reading most of it.

Some more random remarks below:

> Due to the bugs KWin had hit in Mesa, KDE got a pretty bad Media coverage.
> This was something I did not like. The bugs were not in our software. I have
> no problems with admitting bugs in my part and I take blame for it, but I
> cannot stand being blamed for problems due to 3rd party breakage. So I wrote a
I'm afraid that's just reality. There's certainly enough
misinformation going around about e.g. Mesa, Wine, CrossOver, and just
about everything else as well. "News" sites with less than stellar
editorial standards don't exactly help either.

> hurts. Now feel free to shoot the messenger of bad news, but sorry it is the
> truth that Mesa just broke KWin.
I disagree with this, see the first part of my reply.

> mind. Given how important KWin is for you as a downstream I am really
> surprised to see that you do not do regression tests against KWin. What can we
> do to help you there?
Making sure the functionality required by KWin is covered by piglit
would probably go a long way. If KWin has its own set of automated
regression tests that's likely very helpful as well, though likely
more so for distributions than for Mesa directly. Mesa (like everyone
else?) doesn't exactly have huge amounts of developers / QA staff
waiting for something to do, so to make something happen there you'll
probably either have to automate it or find some people who care
specifically about KWin on Mesa and have them test it on a regular
basis.

> Please understand that KWin has only three regular developers. We are all
> volunteers and are doing development in our spare time. Please understand that
> I personally do neither have the time nor the patience to follow the upstream
> development. In a perfect world I would do KWin development as my day job and
> would have the time to follow the upstream development. In reality I have to
This is of course fairly off-topic, but I'd be curious if there's no
interest for funding that kind of thing. SUSE for example has
historically been a fairly strong KDE supporter.

> Anyway even if I were able to follow the upstream development it would not
> help much. The combinations of hardware, driver, mesa, kernel and distribution
> are way too high that our team can ensure that it does not break. This is
I don't doubt development manpower is limited, but don't you have any
users / testers interested in testing development releases either?


More information about the mesa-dev mailing list