Intel Mesa Gives Problems With KDE's KWin, Again

[pingufunkybeat]

People don't know that the drivers are responsible, they just see KDE crashing, and KWin gets the blame. Most users don't even have the debug symbols compiled in to be able to trace it to the drivers for a proper bug report.

[Nille]

If the Driver Crash why not report it by the Driver Devs? I mean its not kwins fault if an Driver has problems with the EXT that he export.

[Nille]

People don't know that the drivers are responsible, they just see KDE crashing, and KWin gets the blame. Most users don't even have the debug symbols compiled in to be able to trace it to the drivers for a proper bug report.

And now kwin try to blame the driver teams before they talk to them.

[Milan]

As I see it, it happened to some Ubuntu beta release (users shouldn't complain with betas but they should fill bugs), KDE use hacks for feature detections, to parse a string is something to expect from Adobe.
KDE tests are based only on NVidia binary drivers but they think Intel should test whether new release works with Ubuntu's KDE Natty beta release? Cmmon...
And how do you think developers can improve drivers, I am sure there was a reason for that change. Issues like that should be solved with bug reports not with some blog and phoronix posts...

[NeoBrain]

If the Driver Crash why not report it by the Driver Devs? I mean its not kwins fault if an Driver has problems with the EXT that he export.

Yeah just reporting it and not workarounding it would probably mean that KWin would be unusuable on any hardware/driver combo but NV+blob. And I guess not even that would work perfectly...
It wasn't just the intel driver which crashed, fyi.

[allquixotic]

It's really a programming error in the application to expect the user to be running one of a finite set of whitelisted drivers. A perfectly viable, new driver could emerge tomorrow with all the needed ClosedGL support, and it wouldn't work only because you didn't recognize its version string? Bullshit.

The problem with whitelisting is that, by taking on the problem of whitelisting, the application developer assumes de facto responsibility for going out into the world and discovering all the extant ClosedGL drivers that exist, and individually determining if each one is compatible with their program, and then adding them to the list if so. The timeliness of updating their list is a direct consequence of how agile their development cycle is, and how aware they are of alternative drivers. That a driver changed their version string is no different than the case of a completely new driver that the app developer isn't aware of: in both cases, it is the app developer's fault, because it became their responsibility to maintain the list from the moment they introduced whitelisting. An app developer who finds this deal to be intractable should reconsider the decision of using whitelisting in the first place.

And the driver developers should be free to change their version string at will, too. No one ever intended the version string to be relied upon; you may as well rely upon the output of `cat /dev/random`. The problem is that the ClosedGL standard says nothing about how this string should be formatted, or what information it might contain, except that it must specify the core ClosedGL version that it supports. Look here:

OpenGL also provides a mechanism for detecting the OpenGL version at run time. An app may call glGetString(GL_VERSION), and parse the return string. The first part of the return string must be of the form [major-number].[minor-number], optionally followed by a release number or other vendor-specific information.

So the app developer can either accept the onus onto themselves for fully understanding the remainder of the string past the core version number of all possible drivers, or they can simply rely upon other features of the GL API to determine if the driver has the features they want, and if so, use them.

As to the complaints that swrast and llvmpipe advertise direct rendering and all the extensions and GL 2.1: my suggestion is to just not ship these drivers with distributions -- duh! If a user has a piece of hardware for which we have no driver, they'll get no GLX support at all, and glxinfo will say Direct Rendering: no. This is a pretty unambiguous indication that you ought not to try to enable compositing, and makes it REAL easy for other apps to figure out that they can't use GL.

I don't know of any case where the software rasterizers are actually useful to end-users for real applications. First, if they have a video card that completely lacks hardware acceleration support, such hardware is very likely to be ancient, and so lack sufficient CPU power to make use of any software rasterizer, even llvmpipe. For the one in ten million installations that actually has sufficient CPU to use a software rasterizer to great effect, but no video card or no supported driver, they can use the package manager to grab the swrast or llvmpipe drivers after installation. For the one in a thousand (or one in a hundred) that has a fully working hardware accelerated driver that your whitelisting wouldn't have recognized, these users will have no problem if you disable whitelisting. (Aside: I know full well the utility of both developing and using the software rasterizers from a graphics developer's standpoint. I just think that this use case is sufficiently rare that asking them to install from the package manager is no high crime, especially since they're developers and are quite likely to compile from git anyway.)

TL;DR? Okay Mr./Ms. impatient, here it is in plain terms: I have a proposal for fixing this mess. App developers: please don't do whitelisting based on any part of the version string except the first decimal number starting at index 0 of the string. Linux distributions: please don't ship the swrast or llvmpipe drivers by default in an installation, and make sure no package depends on them; make the user install them from your package manager.

[agd5f]

The renderer string changes have some purpose behind them, it's not done just to be malicious. For example, in the radeon 3D drivers, we used to just report the driver name (radeon, r300, r300, r600) but not the specific asic. Wine wanted more granular information (rv350, r520, r430, etc.) so we added it to the renderer string. Why not file bugs or talk to the developers when something doesn't work rather than relying on a random sting and not telling the driver developers.

[Goderic]

@allquixotic
IIRC KWin devs used to do this, but the free drivers claim to support things they don't support. So you can't really blame them...

[pingufunkybeat]

If the Driver Crash why not report it by the Driver Devs? I mean its not kwins fault if an Driver has problems with the EXT that he export.

That's because most people don't know what's crashing.

[pingufunkybeat]

or they can simply rely upon other features of the GL API to determine if the driver has the features they want, and if so, use them.

That's what KWin did, and the drivers crashed every time you changed a setting, or enabled some of the effects. Randomly.

Even if you did a runtime check to see if the advertised things actually work, the drivers crashed.

That's why they implemented the whitelists. Without whitelists, nothing would work.

I do agree that working with the driver developers is what should be done, and that the drivers should be debugged and fixed whenever something like this is detected.

But this time, it's not KDE who released a new version, it was Intel, and they didn't check if it works. Now KDE is facing the possibility that compositing will be broken on Ubuntu for the next 6 months.