Possible problems with Intel drivers in 4.5.0 release

[Helio Chissini de Castro]

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