Martin, what you need to test ? I have a notebook with this current issue ( Fedora 13 ) and happens that even Meego SDk not works anymore, so is indeed a Intel issue.
I have another machine to test, desktop, but remote one. []'s Em Segunda-feira 02 Agosto 2010, às 15:59:24, Martin Gräßlin escreveu: > Hi Release-Team, > > 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. > > The best solution would be to fix the failing self check. But due to missing > hardware I am not able to investigate it. > > Sorry for writing that late > Martin Gräßlin > -- Helio Chissini de Castro South America and Brazil Primary Contact KDE Developer since 2002 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team