Bug 265293

Summary: Black screen on login with KWin in 4.5.5 (GL used despite no 3d hardware)
Product: [Plasma] kwin Reporter: Will Stephenson <wstephenson>
Component: compositingAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Will Stephenson 2011-02-03 14:54:17 UTC 
Version:           unspecified
OS:                Linux

A user reported that he gets a black screen, mouse pointer only on login on upgrading to 4.5.5 on a ATI ES1000 chipset.  I was then also able to reproduce this behaviour in Virtualbox (with and without virtualized 3D acceleration).  The kwin output on startup is:

kwin(6463) KWin::CompositingPrefs::detectDriverAndVersion: GL vendor is "Mesa Project" 
kwin(6463) KWin::CompositingPrefs::detectDriverAndVersion: GL renderer is "Software Rasterizer" 
kwin(6463) KWin::CompositingPrefs::detectDriverAndVersion: GL version is "1.4 (2.1 Mesa 7.6)" 
kwin(6463) KWin::CompositingPrefs::detectDriverAndVersion: Detected driver "software" , version "7.6.)" 
kded(6453) ActivityManager::RegisterActivityController: Registering "org.kde.ActivityController-6463" as an activity controller
kwin(6463): ""fsrestore1" - conversion of "0,0,0,0" to QRect failed" 
Unhandled monitor type 0
kwin(6463)/kdecore (KSycoca): Trying to open ksycoca from  "/var/tmp/kdecache-roger/ksycoca4"
kwin(6463): glCheckFramebufferStatus failed:  "GL_NO_ERROR" 
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported!  This is an application bug!
WARNING: Application calling GLX 1.3 function "glXQueryDrawable" when GLX 1.3 is not supported!  This is an application bug!

kwin remains running and if I kill it, disable compositing in kwinrc and restart kwin the problem goes away.  It seems the capability check fails in 4.5.5.

Reproducible: Always
Comment 1 Martin Flöser 2011-02-03 18:51:00 UTC 
The problem had been fixed in master with commit 60b3def9ba2672a04f9fa62f9d236761faf9608c and apparently it seems like I did not backport it to 4.5. Would openSUSE pick the patch if I backport it to 4.5 or is it fine to live with it being fixed in 4.6.0?
Comment 2 Will Stephenson 2011-02-03 19:56:32 UTC 
On Thursday 03 February 2011 18:51:01 Martin Gräßlin wrote:
> https://bugs.kde.org/show_bug.cgi?id=265293
> 
> 
> Martin Gräßlin <kde@martin-graesslin.com> changed:
> 
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
> - Status|NEW                         |RESOLVED
>          Resolution|                            |FIXED
> 
> 
> 
> 
> --- Comment #1 from Martin Gräßlin <kde martin-graesslin com>  2011-02-03
> 18:51:00 --- The problem had been fixed in master with commit
> 60b3def9ba2672a04f9fa62f9d236761faf9608c and apparently it seems like I did
> not backport it to 4.5. Would openSUSE pick the patch if I backport it to
> 4.5 or is it fine to live with it being fixed in 4.6.0?

I can pick it myself, unless it needs expert adaptation for 4.5 branch.  I do 
want it in 4.5.5 as our conservative users are waiting for 4.6.1.
Comment 3 Martin Flöser 2011-02-03 20:33:01 UTC 
On Thursday 03 February 2011 19:56:32 Will Stephenson wrote:
> unless it needs expert adaptation for 4.5 branch
no should work fine. Does not have any 4.6 specific parts.