Possible problems with Intel drivers in 4.5.0 release

Martin Gräßlin kde at martin-graesslin.com
Mon Aug 2 20:59:24 CEST 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20100802/49957f57/attachment-0001.sig 


More information about the release-team mailing list