If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Martin Takes His Mesa Issues To The List

04-20-2011, 10:10 AM

Phoronix: Martin Takes His Mesa Issues To The List

Over the weekend there was a rant by Martin Gr??lin, 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...

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

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

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

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

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

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.