My last blog post about the driver situation in the KDE Plasma Workspaces in version 4.5 caused quite some discussion. This is great and really required. But it also showed that there are quite some incorrect information about the current and future OpenGL compositing being spread. With this post I want to address some of the wrong assumptions I read, so that they won’t be spread any further and causing grieve to both the KWin developers and the driver developers.
1. The Plasma Workspaces require at least OpenGL 2:
Nothing changed: KWin still supports no compositing, XRender compositing and OpenGL compositing. Compositing is still an optional feature (but enabled by default if feasible) and that won’t change in the next years. Given the experience we have with enabling compositing by default it would be irresponsible in my opinion to require OpenGL for desktop computing. Being able to disable effects on the fly is an important and often used feature. The minimum OpenGL requirement is somewhere between OpenGL 1.1 and 1.3 and this has not changed since our first compositing release 4.0. OpenGL 2 features are only used for further optional features in 4.5, which are only enabled if the graphics driver supports it. In case of blur effect there is no requirement to OpenGL 2 at all as it only requires extensions already available for OpenGL 1.x.
2. KWin uses extensions unsupported by free drivers in 4.5:
In 4.5 we added two new optional features which require framebuffer objects (FBO) and GLSL shaders (lanczos) or framebuffer objects and GLSL shaders or ARB shaders (blur). Both are no new optional requirements. Already in 4.0 we shipped several optional effects which required GLSL (invert, blur, sharpen, looking glass and explosion) and framebuffer objects (blur, sharpen, looking glass). The first GLSL based effect was imported to SVN in March 2007, so three and a half years ago. In 4.2 we added two more optional effects using GLSL: sphere and cylinder and in 4.3 we added an optional FBO requirement to the logout effect (which is enabled by default). This one had been committed in February 2009, so 1.5 years ago. The funny thing is that the blur effect in 4.0 required more from the graphics driver than the blur effect we added to 4.5. At the time of 4.0 this did not cause any problems while running 4.0 with modern free drivers would result in the same breakage as we see with the 4.5 variant. In fact we already saw the external breakage in case of the logout effect. If I would use bugzilla I would be able to draw a nice graph when we added an optional effect and when it started to be broken.
3. KWin developers only care about proprietary drivers:
Both new effects have been implemented by a developer not using proprietary drivers. In fact both effects did not work with NVIDIA at the time when they were committed to trunk as we hit a bug in the proprietary driver. The lanczos filter explicitly checked in the source code if the NVIDIA driver is used and was disabled for it. So we did the same thing as we do for free drivers at that moment: we blacklisted the driver. In opposite to the blacklist for free drivers we added that to the code so the user would not have had the chance to change it and also a new driver version would not have re-enabled it (this is ensured in the blacklist solution for mesa drivers). Luckily I was able to find a workaround so that it works with NVIDIA, too. Personally I would like to test more with free drivers, but my Laptop has an NVIDIA card and my desktop has an Ati R700 card which are both unsupported with mesa drivers in the distribution of my choice.
4. KWin should not have delivered the effects enabled by default or at all:
The effects are optional and do not get enabled if the driver does not support the required extensions. In case that the required extension is supported but does not work the protection mechanism does not work (and I cannot think of any other mechanism to make that work with all drivers). This would also be the case if we would not have enabled the effects by default. So I do not see the advantage by disabling them. Not delivering the effects at all would be unfair to the users who can use the effects without problems (both mesa users and proprietary driver users) and also to the developers working on the effects. Last but not least we would have had to remove all the effects listed in section 2, because they require the same optional requirements.
5. KWin developers did not communicate with the Mesa developers:
More communication is always a good thing and it is true that there is hardly any communication. But we do not live in a perfect world and there are many reasons for bad communication and non-existing communication always requires two parts (btw blogging about the problems is also a form of communication ;-). For our given problems I do not see how more communication would have helped. As shown in section 2 we did not add new requirements and we have seen external breakage before (better said: now we know that it has been external breakage). I truly believe that communication between GNOME Shell developers and Mesa developers helps GNOME Shell, but GNOME Shell is in the lucky situation to develop for future driver versions. We have to live with the current driver versions. And communicating does not fix the drivers shipped by the distributions at the moment. The only recommendation we would have received would have been to not ship the effects by default – to that see section 4.
6. KWin developers do not report bugs:
I can only write for myself: I do not have a card supported by mesa drivers so I cannot report bugs. I could proxy between our users and the mesa developers but I think there are more useful ways to spent my time. Therefore we tell the users to report the bugs upstream. Oh and of course if we see the same crash being reported for the 50th time we do not tell them to report it as duplicates in the mesa bugtracker are as useless as in the kwin bugtracker.
7. KWin developers do not contribute patches:
It is difficult to develop drivers for hardware you don’t have. Furthermore I develop KWin and not drivers. I keep the development of drivers to the people competent in that area. If wine developers are competent enough to develop both wine and drivers they have all the respect I can give them. But I am not able to do it and I do not want to develop drivers.
8. It is common knowledge that hardware cannot support OpenGL 2, so you should not check for OpenGL 2:
Yes, that’s why we don’t check the version but the actually required extension. We know that the R300 chips do not support NPOT textures and that’s why we check if NPOT textures are supported before creating a texture.
9. It is common knowledge that the drivers do not fully support the extension just to be able to say they support OpenGL 2 to make broken games work:
What? Seriously? I have never read about it in all the OpenGL documentation I have read so far. I thought that’s why there is an extension system and the experience with proprietary drivers show that this is not how it is done in practice. If that is the way how it is in mesa than I am not surprised that Valve does not want to release Steam for Linux.
10. Mesa drivers need to ship the broken extensions as that makes some more games work:
That’s a little bit unexpected as that breaks the checks we have been using since 4.0. Maybe it would have been an idea to see what the important downstreams require? I am also a little bit surprised that supporting games seems to be more important than not breaking a desktop environment. Reading such arguments really hurts.
11. Because of adding blur my desktop freezes when changing KWin settings:
The change in KWin triggering a mesa bug causing the freeze is completely unrelated to blur and/or lanczos. The change makes KWin use direct rendering when it is supported and not just always enforcing indirect rendering for mesa drivers. With direct rendering enabled the desktop freezes when KWin restarts compositing and crashes with indirect rendering. Given the current state of investigation there might be a bug in KWin which triggers the mesa bug. But this is still unconfirmed and it seems that fixing the KWin bug does not solve the freezing bug in all situations. The only relation to blur is, that with indirect rendering mesa drivers are reporting support for extensions which do not work with indirect rendering which makes the complete desktop unusable. Just for the record: this does not happen with NVIDIA or fglrx driver.
12. KWin will require OpenGL 3 in 4.6:
No, please see my blog post where I wrote that I want to have OpenGL 3 support in 4.7.
13. KWin will require OpenGL 3 in 4.7:
No, this will also be only an additional feature. KWin supports multiple backends and it does not make any sense to remove a working backend which is required for all mesa users and users of graphic cards which cannot handle OpenGL 3.
14. OpenGL 3 does not add anything needed by a compositing manager:
Well let’s not talk about OpenGL 3 but about programmable pipeline (OpenGL 3) and fixed functionality (OpenGL 1). Anybody who has worked with both understands why I want to have a backend based on the programmable pipeline. I want to port KWin to OpenGL ES 2 which requires a programmable pipeline backend, so the OpenGL 3 port is more or less for free. So most of the things we need from OpenGL 3 are also supported by OpenGL 2, nevertheless OpenGL 3 gives some useful things: geometry shaders, forward compatible profiles to ease the porting, a required hardware standard and (sorry to say so) mesa does not support it. Given the experience we have made in 4.5 we would not be able to add a programmable pipeline backend without risking unease situations for our users. Therefore it is better to go for version 3 directly and lower the requirement to 2 when mesa is ready. This gives hopefully the best to both involved groups: our development is not stopped by mesa and mesa is not bothered with problems caused by our to high requirements.
15. KWin wants OpenGL 3 just for FBO:
I am able to read specifications and as shown in this summary, we have been using FBOs since 4.0.
16. KWin should add a legacy backend for Mesa:
Our backend is legacy. The forward compatible profile is not yet developed. The effects can make use of more functionality if the driver supports it.
17. KWin should use the last major OpenGL version before the one drivers announce:
So for 2.1. we would use 2.0, for 2.0 we would use 1.5 and for 1.5 we would use 1.4. Does that solve any of our problems? I doubt it as GLSL is around since 2.0, so dropping back to 2.0 does not help and FBOs are supported since 1.5? I just tried to look it up and it’s not really trivial to find information when an extension was added. So that approach just is not possible. It would also mean that we would remove functionality for users where it is working (e.g. proprietary drivers) as for code maintainability doing yet another fuzzy check on renderer would not work. Not to mention that the renderer string is not stable at all in mesa development.
To summarize the most important points of this post: KWin has not started requiring new unsupported features from the drivers, but has been using this optional requirements since our 4.0 release. Since the early days we had ensured that the optional requirements work and that KWin does not break when an optional requirement is not supported. Our code can handle two situations: supported and not supported. We now had to learn that there is a third unspecified state, which could be called "maybe supported", which we do not handle, cannot handle and won’t be able to handle. Given this historic background all claims about we should have known better or if we just had communicated better the problems would not have appeared are just wrong as our checks used to work in the past. The only possible solution would have been to remove existing functionality because the drivers upgraded their support from unsupported to maybe supported. I know that this sounds like finger-pointing and blaming others, but I just do not feel responsible for this external breakage. I completely understand that users are pissed-off and I would recommend them to talk to their distributions to ensure that when they release the next version which includes 4.5 it can be ensured that a driver is shipped that does not maybe support extensions. There are also more fun things to do than reading the bug reports by disappointed users and spending lot’s of my spare time on working around driver bugs.
Another important point from this post is: KWin will not require OpenGL 3 in future. The complete OpenGL 1 based code will not be removed. There is a lot talking about what KWin should do or should have done without checking the facts like e.g. seeing when KWin started to use GLSL.
=-=-=-=-=
Powered by Blogilo
Hi
Your points are right. However, IMHO, its a shame that you dont have major hardwares to test kwin with.
KWin affects whole KDE experience very seriousely. I dont think a machine with 3 GPU’s would be too much for KDE e.v to provide for you.
More hardware does not solve the problem. Hardware is just one factor, but there is also the time I have to spent and sorry I am not willing to spent my spare time with testing on twenty different systems. That’s something a fulltime developer might be able to do, but as a volunteer developer I cannot.
So would a staff of testers with their hardware and drivers help you? They would need advices of what to test exactly, of course.
Yes more testers would be useful as it is a bad thing if we notice things like the freezes after a release. And there is not much advice needed, just test for regressions. A plus would be if the users would be able to report the issues to the mesa developers and can do things like installing latest drivers from git master to see if it resolves the issues.
It’s hard, for most people, they maybe just desktop users and don’t know much about things like opengl, actually I have been concentrating on this bug for a while, but still not be able to summarize what to report to upstream……
So even if kwin developer just help them to report the bug and give the link to the bug in kde’s bug tracker, it will be more convenient for such would-like-to-help users.
Better idea: AMD and Intel should fix their f**king drivers.
AMD has a working driver. It’s called fglrx.
Hey Martin,
I’m impressed that you are still motivated to work on desktop effect with all the breakage you are facing.
But it sounds as if there is an easy way to help you – donating hardware.
There are probably enough people or companys out there that would donate unneeded hardware if that helps making KDE effects work more smooth.
Maybe you place a call for donations and specify what you need most?
As just replied to the other comment: more hardware does not solve the issue.
I commented this on an earlier blog post of yours, but a section in the Desktop Effects kcm where you can anonymously report what works and what doesn’t might get you some good statistics on issues that arise with certain videocard/driver/Xorg/KWin combinations. It would have to gather every bit of interesting information without violating privacy too much before submitting.
Perhaps a button there that says “Run Stress Test” with a warning saying that it might crash your (KWin) session, which then proceeds to tests extensions and plugins, one at a time? If the card *seems* like it should support lanczos or $NEW_EFFECT_X and then doesn’t, that would get submitted for processing. If it’s a trend, it would become statistically obvious.
If it isn’t apparent to KWin if an effect works or not (ie it seems to work but user gets graphical distortions that KWin cannot detect), perhaps a solution where the user has to manually click a button to proceed to the next test. Then you could have buttons like “No issues”, “Slight issues”, “Severe issues” with a comment box.
DirectX has these kinds of tests in dxdiag, if memory serves. It can generate a log of interesting information about the computer hardware and its driver versions, though I don’t think it can anonymously submit it to the DirectX developers. Everytime an application crashes you can do that, though. Much like you can anonymously send in a Firefox crash to Mozilla.
If that intrudes too much on the Desktop Effects kcm, perhaps just a small additional program that’s semi-hidden to end users, much like kdebugdialog is.
The idea sounds great but it needs developers to implement it. My TODO list is already quite full with the ES stuff.
The piglit test-suite from Mesa should be able to fill that role. Shipping it shouldn’t fall on the kwin developers (it’s the distros’ role), but it might be useful to point users to it when you need more information for reported bugs.
Sounds sensible, but good luck getting geometry shaders to work reliably on the proprietary drivers across different driver revisions and hardware. Not kidding, it’s the Mesa situation all over again (speaking as a 3d programmer).
The silver lining is that the proprietary drivers *should* have matured by the time 4.7 is ready for release.
Hopefully by that time, Mesa will also have matured to the point where a GL2 backend is feasible – things are simply too fluid right now (a new GLSL compiler, a new driver architecture, tons of bugfixes, performance enhancements, etc).
I doubt that we will ship a geometry shader in 4.7. That’s more like getting the backend ready 🙂 Maybe one geometry shader for testing and playing around, but nothing to actually ship. And of course the OpenGL 3 backend will not be enabled by default in 4.7.
It’s an interesting read, thanks for your time spent writing it.
But I can’t agree with “my desktop has an Ati R700 card which are both unsupported with mesa drivers in the distribution of my choice” and “I do not have a card supported by mesa drivers”. AMD/RedHat and others are doing superb job supporting chips R600-R800 now in both mesa class/gallium3d drivers. It’s still a WIP (in classic R800 and R600g), but it’s definitely a good progress.
Anyway, I don’t think it would be a time “badly” spent if you were to test open source graphics stack for a day or two. You know kwin internals (which most people don’t) so you’ll be able to provide good bug reports for drivers developers (which in turn could write some piglit tests for all mesa drivers).
Fact is: with Debian Squeeze it is not possible to use mesa drivers with one of the cards. I cannot just compile gallium as therefore the kernel is way too old. And if I start using another distribution we are not in a timespan of one or two days but more likely of one or two weeks. Getting KWin compiled from trunk is not the most trivial thing if you have no idea about the distribution.
well, I wouldn’t call compile custom kernel + mesa from git “not possible”. Maybe it’s easier in one distribution (as Fedora being close to upstream) than others (Debian), but certainly it’s possible to set-up working mesa from git in half a day or so. You can always ask people running such stuff on “radeon” irc channel.
About “kwin” from trunk, I was running “KDE” from trunk for several years (in Debian, Fedora, Kubuntu) and after first compilation it goes very smoothly, unless there’s some package dependency change, which doesn’t happen very often.
The problem is, even if I set up R600g driver myself (which I recently did in 30 minutes with Fedora), I can try enabling kwin compositing and if it doesn’t work I can’t do more. (I can go and look at the source code, but that’s way too out of area of my expertise). And on the other side, driver devs can’t fix the problem since they don’t know about it in the first place. (if you don’t run kwin, how could you know it doesn’t work). Asking driver developers to run/debug kwin would be too much, wouldn’t it?
That’s why it’s *very* important for community as a whole to provide important feedback (bugs in this case) for each other. I see a very big gap between open source graphics stack and kwin here. Sorry, but it’s how it looks like.
I just did compile KDE from trunk on a new system and it took me something about one day on a distribution I know. I have no idea about how to compile a kernel, Xorg or drivers. Sorry but that is just above my knowledge. I need my system to work and using drivers from development versions is nothing I want to do on my productive environment. You can see that I care about a stable system by the fact that I use Debian.
For anything else like using another distribution: sorry no time for it. I am only a freetime developer and have a regular job where I cannot work on KWin.
sure, I totally understand that you don’t have much time.
but there’re 2 things about it: you don’t have to break your current system with new kernel, new mesa, you can install them in some temporary location and remove it later on, so it’s really not that hard. and second thing, I think feedback from you as a kwin developer would be very useful for mesa devs
still my time is really limited and I just do not want to spent time on compiling and configuring stuff I have no idea about. Sorry it’s just that my schedule does not allow to work on something like that. All the “but it would be useful” does not help as I do not have the time for it.
You don’t even have to do that, testing current driver snapshots is dead easy these days. Just install ubuntu maverick beta and upgrade to the xorg-edgers PPA.
Of course, if you can stand debugging the weekly boot script crash and trying to debug obscure Ubuntu-only kernel bugs. For some reason I can’t understand, I can actually use Fedora betas, but Ubuntu pre-releases are unstable until the very last minute before the release (truly: somehow more than 3,000 updates are released in 72 hours to close crasher bugs between RC and release)
I tried Kubuntu Maverick Meerkat and it didn’t work with stock packages. It won’t work, of course, with experimental PPAs loaded on top of an unstable system.
It has nothing to do with how much time you have available, it’s about priorities. You have time to work on the OpenGL3 support because that’s important to you, or fun to work on, or whatever. If OSS driver support was more important than that, it would get time as well. (Unless your employer is paying to work on GL3 support, or something like that)
Anyway, obviously it is your choice about what you want to work on. But I wish you would stop saying you’d like to work on it but just don’t have the time.
Hopefully the problems being encountered here can motivate some other developers to start hacking on KWin in these areas that you aren’t very interested in.
well said. of course, lots of users are really thankful for kwin developers for spending their spare time on implementing those different features. nobody says otherwise.
the problem here is that KDE 4.5 is supposed to be stable release, which doesn’t crash (not even once at startup with X, when tries to enable desktop effects). Graphics drivers are known to be in a “broken”/experimental state, depending on your distribution of choice. 2+2 equals 4. if you want to add new features either test them on all hardware/make sure someone else does/make sure driver devs know that kwin uses some features or don’t enable features by default. period.
Kwin is a critical component, if you don’t get it right and stable people will turn away (and this is not KDE4.0 we’re talking about here). if there’s no one who’s willing to do the testing/debugging kwin on most of the hardware available I don’t see how KDE goals of being production ready could be met with Deksopt Effects enabled by default. That’s the world people have to live in, not some imaginary one where graphics drivers will fix itself. at least not yet, while graphics development is still in progress
so everything is fine as it completely works as expected for my GPU which has failing drivers. Effects are not enabled by default, so no X crash. When the user manually enables compositing X crashes and there is nothing I as a kwin developer can do to fix experimental drivers (yeah R700 is a different topic than the other drivers we are talking about). KWin takes care that after such a crash the user will not be able to crash X again. So we have added what we can do to prevent X crashes.
I hope I do not have to mention that it should never be possible for an application running with user rights to crash an application running with root rights.
slava – “the problem here” is not with KDE 4.5. Your assumption is that you should not add new features because they might expose bugs in other components. This logic leads to NO new features anywhere EVER.
Yes, KWin is a critical component but the multitude of desktop effects are optional. Graphics drivers will always be in development as will KWIn so getting both to line up is like trying to hit a moving target. You can’t completely freeze the development of all other components while you exclusively work on one.
Bugs happen. New features in a component may expose bugs in other code. Complaining about the new features is mis-directed energy. Complain about the other code not implementing the documented interfaces correctly. That’s where the problem is.
Matt – Again with the massive arrogance. Who are you to say what developers should spend their time working on ?
Martin has told you repeatedly that he spends his time working on other tasks and there are only so many hours in a day. You don’t get to decide what other people spend their time doing.
If you have a problem, shut up and write code to fix it yourself. Otherwise you have no right to complain about what developers choose to work on. Why don’t you stop your whining and start hacking on KWin yourself. Every minute Martin wastes here answering you means less time to write code.
Your attitude sucks. Spend your own time anyway you want, but don’t preach about how other people should spend their time.
An Ubuntu is installed in 20 minutes an the Xorg egers ppa is included in 40 seconds. With the software updates you need maybe 2 Hours an you has an recent Kernel, Mesa and DDX Version.
https://launchpad.net/~xorg-edgers/+archive/ppa
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Sorry, but I tried Ubuntu Maverick and my X server crashed when I activated Desktop Effects. There my motivation ended
Hi Martin,
I simply love KWin and give nothing about the “I have no idea what I talk about but …” people. Except for a short period of compiz and Komposé (I know it’s not a window manager) under KDE3 there was no room and need for anything else on my desktop. KWin always worked for me, never bothered me.
Keep up the good work.
ZooLodian
Hi,
I have been affected by these issues… and the level of discussion now is way over my head. I’m just going to say thanks to you and everyone working to sort it all out… and KDE in general for pushing the boundaries of what a modern desktop should be.
Cheers.
Martin – I totally understand that you are busy, but can I humbly suggest that spending the 12 hours it might take to learn how to compile a kernel + mesa and stick them into a temporary location to be used for testing purposed might be much more important than anything else you could have worked on with KWin in those 12 hours?
Your comments right now basically make it sound like you can’t be bothered to support the open drivers, so it’s not surprising when users of those drivers get a little bit upset. It would be different if there were other developers doing this testing – it sounds like there possibly are, except that from the results it seems like perhaps they aren’t. You seem to be waiting for other people to stand up and fix this for you, and it just doesn’t seem to be happening. 🙁 I know it’s a tough situation, but that’s just the reality of graphics drivers right now. The situation really isn’t much different with the proprietary drivers either if you use the more recently implemented functionality, it’s just that the stuff you’re currently using was implemented years ago in those drivers.
Matt – You are directing your comments to the wrong person. It’s not for Martin and the KWin guys to fix bugs in the Mesa drivers. He’s not waiting for others to fix anything for *him*. KWin isn’t the thing that’s broken.
Users of the drivers should get “a little bit upset” at the Mesa driver developers. Why should KWin developers fix bugs in Mesa drivers ???
Anyone humbly suggesting that another person should spend 12 hours of their precious time on fixing someone else’s problem, really needs to look up a dictionary definition of “humble”.
I never said it was. All I would like Martin to do is to create a Mesa bug report when he sees that it’s crashing rather than just shrugging and saying Mesa isn’t ready yet. The Mesa developers are very responsive to bug reports, and this issue probably would have been solved by now if Martin had taken a few minutes to report the issue. Instead, they’ve just started debugging this now, after a huge uproar and hundreds of people are blaming KDE. It’s simply not a good situation, and I hope that in the future the communication is better.
I mean, I understand that the drivers are broken and that’s bad. But they have to test against millions of different hardware/application configurations. KWin developers might feel like they have a lot of different configurations to test as well, but at a fundamental level they are only a single app and can test much easier. Martin said that the blur effect was broken on NVidia initially, and that he managed to find a workaround to get it working – why do i think someone might have been able to do the same thing with the mesa drivers if they had tried hard enough? It would be nice if someone (not necessarily Martin, but another developer maybe) put out that extra effort for drivers that a large portion of their users are using.
Seriously you are missing the point. I have this piece of hardware since two years and it never worked with Mesa. I do not have to report bugs for not yet supported hardware. Reporting such issues just takes my time and their time. And I could not have told them anything useful at all as I did not have a backtrace or anything.
Clearly you don’t have to do anything, I’m just saying it would take KDE to the next level. It’s something that’s missing right now.
Anyway, I’ve said my peace and will continue to bug you no more. Thank you for all the work you do, and hopefully the future will bring even more.
Awesome blog post Martin! I’m impressed – keep it up! 🙂
Ad 9.
Even proprietary drivers for R300->R500 faked the extensions and either fell back to software or crashed. There is a bunch of white papers published by ATI containing the list of features you *should not use* with their 2.1 proprietary drivers. If you do not know about this, then you probably wasn’t a GL programmer back in 2005. NVIDIA had the same issues on GF FX.
In Mesa/R300, I have a different strategy:
1) Not using software fallbacks.
2) Inserting filters for NPOT textures directly into shaders.
3) Misrender if something goes wrong, but never crash.
Also I guess Mesa won’t have GL3 because of patent issues. It sucks but what else can we do?
No I have not been a GL programmer back in 2005 😉
About the patents I won’t answer, because my opinion to patents is probably incompatible with what X developers have to work with 😉 (My opinion is mostly based by the fact that patents on software are forbidden in the part of the world where I live)
Great Post! It’s a shame that some people blame KWin for crappy drivers… and it’s also a shame that such crappy drivers exist and Intel/AMD don’t seem to be fixing these issues soon. (BTW: it’s amazing how AMD has managed to have crappy drivers for both Windows/DirectX and Linux/OpenGL…)
It’s an eye opener how some people says that you are selfish to devote your programming skills and time to something that interest you and that you you should stop that behavior and do what they want instead…. hmmm. But I think you are doing a great job handling this, and its always be the way free/libre/open source software where made. You have to be tough and strong minded. And who knows, maybe one day… a one first startup 3d diag detect routine (at first boot) could be crafted A kind of wizard app. it could reused if the user claim to the wizard app the the drivers are now bettter / have been updated. Just a series of steps and tests with a yes/no question for all. And i’m not saying that for you but for all the Internet. Unfortunately I’m no programmer 🙁 It must be great to program cool stuf for the entire planet… 🙂 except maybe when people spit in your face …
Here Another suggestion. In the advanced effects listing and config we could have a popup bubble or something saying: This effect requires opengl version 1.1 / or 2.0 or what ever for each effect, being blur transparency or what ever.
I have a wish unrelated to all of this mess, but related to OpenGL desktop effects ;).
Can I enable or disable some effects with the power profile? My poor 6150 IGP suffers when it tries to do blur (it isn’t a KWin issue, it happens with Windows Vista and, to a lesser degree, with Windows 7, the IGP simply doesn’t have enough muscle to drive a so simple thing), and I want to enable blur when I’m plugged in, but disable it when I run on batteries. Since disabling Composite actually hurts battery life, disabling Composite isn’t an option for me.
BTW, thanks for making everything work. Even on Nouveau with XRender. Thank you.
“Sorry, but I tried Ubuntu Maverick and my X server crashed when I activated Desktop Effects. There my motivation ended”
And this is why people don’t like desktop effects — they don’t work on many configurations, particularly if it is different to YOUR configuration.
What you did there is called “testing”, and what you found is a “bug”. You should, as someone who is ideally placed to identify these problems, so identify the problem, or contact others who can.
Its not a problem of “i don’t have enought time” its a problem of “I don’t prioritise testing, I think it is boring and unimportant/
You are developing things without testing them — this is bad. Please prioritise testing this over feature developments.
if you said that you can
1) Deliver a very stable KDE
or
2) Deliver more effects
I wonder which one people would go for.
No that is not testing, that is realizing that the driver just does not support my graphics card yet. I can see that on various distributions in different states of breakage. Btw. KWin works completely fine with this X crash as it won’t allow the user to ever again enable desktop effects.
Your blog is awesome, it’s really nice to hear from someone blogging about these issues! I hope all the best for KDE because I simply love it!
(me again, Myself)
When the user manually enables compositing X crashes and there is nothing I as a kwin developer can do to fix experimental drivers
Absolutely there is something you can do, grep the lspci and then use a modal dialog box:
“Enabling desktop effects with your hardware combination has been reported as possibly nonfunctional, and may produce a crash. Do you wish to enable anyway (yes/no)”
This is called “defensive programming”, and is a good idea
Just for the record: this cannot work for many obvious reasons. We did what is possible: recognize the X crash and prevent further crashes.
Sorry, I don’t understand — why can this not work? There must be dozens of KDE developers, and hundreds of potential testers right? Surely they use a heterogenous mix of hardware.
Send a mailing question out and ask:
“For people running X.Y.Z of package BLAH — does the following crash? (yes/no)”. If this crashes please send your driver details and LSPCI output to us. We will add this to a database of potentially problematic hardware. Use
Use this to build a blacklist of driver/card combos that fail. If the end user’s hardware matches any of these, then throw up the warning.
When deploying your code, as you detect the X crash, popup a window saying “BTW, your X died. We are really sorry, and we would like to prevent other users from experiencing the same problem. To do this we would like to send a copy of your driver version and KDE version to our servers. We will use this to alert users that this hardware combination is potentially problematic. (OK) (No way)”.
Set up a webpage that accepts a POST request (you can do this with curl/wget really easily) then filter this for spamming by rejecting any IP that has submitted more than a given threshold of entries (say 3).
Use this data with the next version of the program’s blacklist.
Users just don’t expect to have their work go kaboom for enabling what is a seemingly (and most people don’t know otherwise) innocuous alteration to their config.
Heck, even just labelling this as “BTW this can cause crashes, save your work before pressing this button” would be a start.
Blacklist by asking users to provide data: tried it, didn’t work or I would not have had to read one of these blog posts.
And for the rest: till that is implemented with all the required infrastructure the driver crashes will hopefully have setteled down. And no I don’t add a warning to a button which works fine for 99 % of our users and will only crash once. It’s bad if they lose data, but that’s not our problem, sorry. X should just never crash. (Although I’m rather tempted to try to exploit it for gaining root priviledges).
Hi, it’s possible to have recent mesa drivers on Debian:
I’m not sure about the free radeon driver but nouveau can be easily installed with 3D support:
-Squeeze’s linux kernel (2.6.32) contains recent drm code backported from 2.6.34 (http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-21/changelog)
-Install the package libgl1-mesa-dri-experimental based on mesa 7.8.2 code (http://packages.debian.org/experimental/libgl1-mesa-dri-experimental) from the experimental repository which contains nouveau’s 3D support (should be fully compatible with Squeeze without any other dependencies from experimental)
-Adapt your xorg.conf and maybe remove your previous proprietary nvidia installation and then you should be able to have a libre 3D acceleration.
Hopping this could help you.
I tried nouveau some time ago with said packages from experimental and it did not work for me. Neither did it work for me on openSUSE 11.3 (on different systems with NVIDIA graphics)
Kwin should force developer to become well behaved by trusting them, causing crashes, and then screaming about them. So long as we put up with badly behaving drivers, the driver developers will behave badly. There is a lot of pain now, but if you persist (perhaps even going so far as to remove the blacklist in a future version!), eventually developers will learn that there is a lot of pain for broken drivers claiming they can do something they cannot.
In short, you are already doing to much for drivers that don’t work. Please focus your efforts as much as possible on drivers that work. That means fall backs so when the driver says it can’t do something you can use it, but if the driver says it can do something keep telling people to scream when it can’t.
This is reasonable, and makes the world a better way. Thanks for your efforts.
If there are problems for Kwin within KDE 4.5 with some open source drivers, why not, instead of blacklisting compositing when said drivers are detected, either blacklist the new effects introduced with KDE 4.5 when said drivers are detected, or enable the user to run compiz instead?
I can’t see the point in throwing a hissy fit and cutting some users out of features, just because they happen to have a certain type of graphics card.
Erm, our solution is to blacklist the effect.
4.0?!!!! 4.0 was a developer release and it caused problems for everyone!!! esp because distro’s treated it like it was stable…
My question is this, how are you going to prevent this from happening in the future? or can we expect every new KDE release to perhaps break everything again.
KDE is a developer community with several thousand developers – how should I be able to answer that question?
Martin, thank you for your amazing work on KWin. It has lifted KWin and thus KDE onto a wholly different level of desktop experience. Thank you for that.
I hope you won’t let the difficulties frustrate you. The Linux graphics stack is clearly moving in the right direction. I believe everything will come together during the coming maybe two years. If you keep playing your part, you will be a major contributor to this.
Cheers!
I’m pretty sure KWIN developers do the best work according to resources …
The energy that is used to explain why their work is correctly done is also time that is wasted … but this is probably done because they have received a huge amounts of mails criticizing their work (and probably not always in a gentle manner – it is always easier to criticize than to build things)..
I have used KDE 4.4 and it was really working well on my nvidia card (9800gt) .. (even if not everything was perfect but I don’t have a very new config – only one core ;))
when I have tested 4.5 I had problems – 90% were corrected by placing the famous filter as blacklist for my card.. I understand all the arguments explained here .. but not all end-users would look this far which is understandable…
So to my opinion there should be a team at KDE global level for desktop effects dedicated
1. to create accurate BUG report
a – to the video card manufacturer when the driver is responsible …
the more accurate the bug description , the more difficult it would be to say that it is someone else’s fault
when the bug is filled allow users that complains to promote this bug nr xxx on video card manufacturers support sites. the more people complain with an accurate bug report – the sooner it should be corrected.
b- to the X team when it is X fault
c – to the KWIn team if the bug is identified to be at their level
2. to define which videocard do the job correctly with each of the KWIN options.. and to block effects that aren’t working based on the card.
That should facilitate the work of programmers … and let the develop in peace 😉
Great, this just keeps getting worse for me.
A few years ago AMD/ATI decided to remove support for my graphics card (Radeon x1300) and now I’m losing support with the free drivers. I hope that xorg and mesa can develop the drivers supporting the latest OpenGL requirements.