Possible problems with Intel drivers in 4.5.0 release

[Sebastian Kügler]

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