[Mesa-dev] KWin and Mesa

[Martin Gräßlin]

 On Wed, 20 Apr 2011 04:32:25 +0200, Henri Verbeet <hverbeet at gmail.com> 
 wrote:
> 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.
 Thanks for your mail. This is really constructive and a reply in the 
 kind of I hoped to receive. A good starting point to fix the mess we are 
 currently in :-)
>
> 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.
 Actually I agree with you and all other who wrote it: it is a hack and 
 it should not be there. It was added to make KWin at least "work" around 
 the 4.5 release. As a matter of fact and that question might sound 
 stupid, where do I find information on additional API provided by Mesa 
 than not parsing the renderer/version string? In the response to the 
 blog post I received replies that we should use DRI2QueryVersion. That 
 was the first time that I heard this thing existed. Where is that 
 documented? How can we find out about it? I seriously have never ever 
 heard about it or read about it in any documentation I have read so far.
>
> 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.
 The problem is that at the time we release it has to work. Our users do 
 not care about whether it is the driver or not. It just has to work. A 
 big problem in that regard is as you noticed yourself the distributions. 
 They do not ship updates to the drivers, so we need to make it work with 
 the driver version out there and not with the next bug fix release. Our 
 work would be much easier if we could just tell the users to update 
 their drivers ;-)
> 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.
 We do tell the users to report the bugs upstream. I don't know if they 
 do it, but we tell them. We cannot do much more - I personally don't 
 want to play proxy for bugs I cannot reproduce with my hardware. I also 
 reported the only bug I ever encountered with free drivers, 
 unfortunately nobody ever replied to it.
>
> 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.
 Normally distributions do not want to have specific code. Especially 
 KDE discourages distros to create specific hacks. If I think of Kubuntu 
 they for example would not have the manpower to create the patches and 
 would ask me to fix it. Most packagers do not have any knowledge in this 
 area. But it's also working now: Ubuntu includes a fix for the problem 
 now (adding "GEM" again) and Fedora is at least interested in adjusting 
 the code to make it work with Mesa 7.11 (which I will not consider for 
 our next point release, but only for our next major release).
>
> 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.
 I hope I could explain in my last mail that this time I just did not 
 have the possibility to discuss with you on IRC or send you a mail in 
 before. Writing blogs for communication is a typical KDE thing, so yeah 
 I'm sorry if it causes resentments and because of that I wrote the 
 lengthy mail to get out of the stupid "they broke us"/"they are doing it 
 wrong" circle which does not help anybody. I will try to no longer post 
 such blog posts in future and I hope the mesa devs could stop writing 
 mess on the Phoronix forums ;-)
>
> Some more random remarks below:
>> 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.
 I am working on getting the compositor to compile without the window 
 manager to be able to run it as standalone application and as the base 
 for some test suites. This will take some more time - we will most 
 likely get a GSoC project which will implement parts of it. Concerning 
 piglit: I think there are more experienced people than me to actually 
 write the tests. One of the problem for me is that I do not speak 
 Python. I hope that when we have the compositor standalone we can just 
 add a few piglit tests on top of it and test everything what KWin 
 provides. But as said: it takes some more time.
>
>> 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?
 Too limited to actually be able to test everything or not knowledged 
 enough to really understand what they need to test :-(

 Cheers
 Martin