More Details On The OpenGL Situation In KDE's KWin

[pingufunkybeat]

The point is that he claims that he doesn't "want" to develop for the blob but that he doesn't have any other choice, which is not true. He can update his X/Mesa/Driver stack on his own or switch to another distro.

So could you, and you could have reported the bug too. As could have any KDE user, or any Mesa developer too, for that matter.

He's an unpaid volunteer coder. He tested with what was available to him, and he added an optional effect.

[RealNC]

"blur" effect does not blur anything however - all still looks clear as it wasn't enabled (or maybe there is some obscure misconfiguration) but there is no such thing as artefacts or crashes.

Blur works fine with Mesa Git and 2.6.35 here (HD4870):



However, bypassing KWin's internal GL checks might be required for it to work. See this post:

http://www.phoronix.com/forums/showp...9&postcount=19

[[Knuckles]]

It's easy to point fingers at people who do nothing and say "at least report it".

But he does a lot of work. So what if maybe he doesn't really have that many time to mess with testing a lot of configs, hey that's where the community can help. It's not like kwin just materializes hours before KDE releases -- anyone can run a trunk build of kwin (regardless of using KDE at all) and test it out.

Of course it would be nice if he went to THAT extra trouble, but hey, if all of us here and commenting on that blog did that much for the free desktop, it would probably rock even more.

Honestly even I get a little tired of trying combos of kernel+X+mesa to get free drivers rocking. And when you find that perfect combo, dang you discover that kernel broke some other hardware you had.

So here's my 0.02 (euro) cents.

[RealNC]

So could you, and you could have reported the bug too. As could have any KDE user, or any Mesa developer too, for that matter.

No, we couldn't. KWin disables stuff with Mesa drivers; we never get to see it so we can report it. Only the devs know the internals well enough to make out whether something is working as intended or not.

Visible bugs get reported (I've filed some myself.) What we can't see, we can't report, obviously.

[KAMiKAZOW]

And what does this have to do with a KWin dev not wanting to test his code against the open drivers, allowing him to file bug reports to X.Org? Which is entirely up to him, I'll give you that, but why make excuses about an imaginary inability to do so?

He is a volunteer. If his favorite distro is configured in a way that Mesa drivers don't work with his GPU, that's not his fault.
Volunteer developers don't owe you or anyone else anything! He is not obligated to run a gazillion distributions with trunk builds of Xorg and Mesa.
No! It's the paid Xorg/Mesa developers duty to test their drivers with with the most common composite window managers (currently Compiz and KWin, in the future Mutter as well). The current messy situation wouldn't have happened if the well paid developers did their job in the first place.
And in case there are too few paid Xorg/Mesa developers, maybe some Linux distributors should put some money where it actually counts instead of spending it on a design team that makes purple backgrounds and moves window buttons to the left side....

[bridgman]

Most of the Xorg/Mesa developers are volunteers as well. If the paid developers did all the testing you want instead of working on drivers, the problem would take care of itself because the GL 2 support and new hardware support being discussed here probably would not exist in the first place.

Somewhere around 5x the current staffing level would make a lot of things possible. In the meantime, more communication and making more options "user-selectable" rather than "automatic based on extensions and blacklists" would probably help.

[RealNC]

He is a volunteer. If his favorite distro is configured in a way that Mesa drivers don't work with his GPU, that's not his fault.
Volunteer developers don't owe you or anyone else anything! He is not obligated to run a gazillion distributions with trunk builds of Xorg and Mesa.

Gazillion? What the hell are you talking about?

Also, yes, his is not *obligated*. But it's easy to install a recent stack. Takes 20 minutes.

Gah, I need to get back to what you said... "Gazillion"... Seriously, roflmao!

[bridgman]

What's the problem ? A gazillion is an indeterminate, large number and AFAIK there are an indeterminate, large number of distros to choose from

[dfx.]

The current messy situation wouldn't have happened if the well paid developers did their job in the first place.

that's the thing - _currently overall situation is not that messy as he writes_, currently his situation is that messy because he using obsolete graphic stack. it was his personal choice and this is consequences of his choice - his problems, not other users and not some devs.

maybe some Linux distributors should put some money where it actually counts instead of spending it on a design team that makes purple backgrounds and moves window buttons to the left side....

that is true...

Blur works fine with Mesa Git and 2.6.35 here (HD4870)
However, bypassing KWin's internal GL checks might be required for it to work.

doesn't work for me but looking at how ugly even blacklisting for effects done (and that forced selective disabling of effects done via blacklisting at all) in kde and knowing that kde devs do not afraid of letting undocumented parameters and functions in releases i'm not surprised.

to hell with it still, i hate blur anyway.

[noisymime]

And what does this have to do with a KWin dev not wanting to test his code against the open drivers, allowing him to file bug reports to X.Org? Which is entirely up to him, I'll give you that, but why make excuses about an imaginary inability to do so?

I agree that testing on all platforms is desirable, but its not always feasible, especially with free software. I think the steps they've taken though are pretty good:
Query the driver about whether it supports feature xyz and only proceed if it does.
If you don't have the hardware to test on, that's a pretty good strategy, unless, of course, the driver lies about what it actually supports. There's no excuse for a driver claiming capabilities it doesn't have.