Hey Martin, On Monday 02 August 2010 20:59:24 Martin Gräßlin wrote: > I know that the release is scheduled for tomorrow, nevertheless I want to > make you aware of a possible problem with Intel graphics cards and > compositing. > > I think I first have to explain a little bit: KWin uses a test to determine > if OpenGL compositing is working during the startup. This seems to fail > for some Intel drivers since some time. It used to work and the code has > not changed, so it is most likely a driver bug. I was first made aware of > this problem at Akademy. Due to the fact that I do not own Intel hardware > I was unable to reproduce or try to fix the issue. > > Up to 4.4 KWin just disabled compositing if this check during startup > failed. In the 4.5 development cycle it was changed to fall back to > XRender compositing. The idea behind it was that you get translucancy when > starting from live cd or running in a virtual machine. It was not meant > for the case that the OpenGL driver causes an incorrect self check > failure. > > This fallback to XRender causes slowness of the system and some effects not > working. Furthermore the complete UI says that it is using OpenGL > compositing although in truth XRender is used. > > When I was made aware of this problem with Intel drivers I reverted the > fallback to XRender both in trunk and branch (svn revs 1148315 and > 1148316). Unfortunately I missed one change (the original commit changed > more than just the fallback) which I found by pure luck this weekend (svn > commit 1157978). It's confirmed that this commit is now finally working: > compositing is disabled at startup. By disabling the functionality checks > in the advanced compositing preferences it is possible to get OpenGL > compositing working again. > > Now the question is what to do with this commit. Due to the fact that I > missed this one line KWin is now saying that it disables compositing but > in truth is falling back to XRender. I see three possible solutions: > > 1. We ignore it. This might result in many complaints about slow KWin and > that effects are not working any more (e.g. cube, coverswitch, blur, > etc.). We will have many complaints about slow KWin anyway due to the > enabling of blur and the fact that many drivers are too bad for it. On the > other hand we had no bug report to this issue. I only heard about this > problem by fellow KDE developers, which might be related to the fact that > we have more recent drivers/Xorg than most of our users. > 2. We backport this patch to 4.5.0. This means a lot of work due to the > schedule (sorry for writing that late, I had to think about this issue for > one day) and will cause users not be able to use desktop effects any more. > But it would be the cleanest one. > 3. We backport to 4.5.1. This would mean a behavior change between 4.5.0 > and 4.5.1 which I would not like. > > To summarize: I am not happy with any of the three options I came up with. > And I do not know what to do about it. Given that the release is tomorrow > I guess it's only possible to choose between option 1 and 3, while I think > option 2 would be the best. I think it's better to disable compositing > instead of slow compositing. So the question is, if we should backport the > commit for 4.5.1.
I'd leave that decision to Dirk. > The best solution would be to fix the failing self check. But due to > missing hardware I am not able to investigate it. I'll add anote to the release notes however, and I can offer you testing ground. I have Intel and ATi hardware here, both machines with a recent source install. Just ping me on IRC if you need something tested. > Sorry for writing that late Don't worry, thanks for paying attention and noticing it. We can always delay the release a bit in case of problems. We're the release-team, you know? :-) > Martin Gräßlin Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
