Several times during the KDE logon process, and - for example - in the moment when the screensaver is being turned on, X.org shows garbage scren content for a few seconds. It also happens when I click onto a picture in doplhin, which makes gwenview to open it. Gwenview displays garbage instead of the picture for approximately one second. Similar screen garbage shows up when switching X11 modes (e.g. starting a new session, switching to console etc.) And this is without any KDE 4 packages, so it is definitely an X.org problem. It turned out that this can be worked around by switching to XAA acceleration method instead of EXA, thus, EXA is the cause of this problem, experienced with Intel drivers. Moreover, XAA allegedly gives superior acceleration performance, but unfortunately it's becoming unsuportted, so it's not a viable alternative: http://bugs.freedesktop.org/show_bug.cgi?id=10912
Created attachment 22004 [details] Gwenview shows this for one second instead of the image
Created attachment 22005 [details] KDE logon video created by Xavier Callejas
I've forgotten to mention, that I experienced this symptom under both the 32bit and 64 bit version of openSUSE 11.1, using an Intel 945M card with the intel driver. This very bug may be the duplicate of http://bugs.kde.org/show_bug.cgi?id=170462, but I'm not sure, since the comments of that bug seem to describe distinct problems. Some comments, like http://bugs.kde.org/show_bug.cgi?id=170462#c31 , http://bugs.kde.org/show_bug.cgi?id=170462#c37 and http://bugs.kde.org/show_bug.cgi?id=170462#c77 (as openSUSE doesn't use the patch mentioned in http://bugs.kde.org/show_bug.cgi?id=170462#c44) and even the original problem description seems to describe my problem, but others, like http://bugs.kde.org/show_bug.cgi?id=170462#c6 , http://bugs.kde.org/show_bug.cgi?id=170462#c7 NOT. There are at least two bugreports regarding this topic on openSUSE's bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=464512 https://bugzilla.novell.com/show_bug.cgi?id=444373 And they have the following features in common: -Seem to occur with the intel driver -Unaffected by compositing -Switching to XAA from EXA eliminates the problem!!! -Easy to reproduce by gwenview and KDE login/logout -Don't seem to be related to the patch mentioned in http://bugs.kde.org/show_bug.cgi?id=170462#c44
Hi, i can report a similar problem, but using different hardware and driver. Using openSUSE 11.1 64bit with KDE4. Graphics card is an ATI X700 mobile with the opensource radeon driver. I have similar "symptom". Corruption while log in/out. Once logged in have only noticed it in gwenview... only for a second before i can see the correct image. This is just as described above by Tamás. Removing the EXA line from xorg.conf fixes it. Disabling KDE4 desktop effects also fixes it. regards, Carlos Bessa
Just wanted to add that disabling KDE desktop effects does not fix it, so it is just as described above by Tamás. But using the Radeon driver and a X700 mobile graphics card. Carlos
I'm experiencing the same problem in openSUSE 11.1 64-bit, NVIDIA 8800 GTS 512 (nvidia 180.29 driver), so it's definitely not a "Driver/intel" problem.
I think that "Summary" and "Component" fields should be changed accordingly.
> --- Comment #6 from dsent <dsent@mail.ru> 2009-02-15 08:37:19 PST --- > I'm experiencing the same problem in openSUSE 11.1 64-bit, NVIDIA 8800 GTS 512 > (nvidia 180.29 driver), so it's definitely not a "Driver/intel" problem. nvidia doesn't use exa, so this doesn't point to exa more than intel. there's a good chance your issue with nvidia is actually unrelated.
Yeah, please don't mix up several issues... Tamàs, which version of the X server are you using? If in doubt, just attach the full Xorg.0.log file. Also, are you using the KDE compositing effects, and if so using the XRender or OpenGL backend?
Created attachment 23868 [details] xorg log file (radeon driver)
In my case i'm using xserver 1.6.0 and radeon driver 6.12.0 Bear in mind the problem also appears with the shipped xorg/driver from opensuse 11.1... that's why updated to see if it was corrected. Using Kde4 compositing effects with the openGL backend. The xorg.0.log file is attached. regards, Carlos
(In reply to comment #9) > Yeah, please don't mix up several issues... > > Tamàs, which version of the X server are you using? If in doubt, just attach > the full Xorg.0.log file. > > Also, are you using the KDE compositing effects, and if so using the XRender or > OpenGL backend? > X.Org X Server 1.5.2 and KDE compositing with openGL. However, this glitch seems to be unrelated to KDE compositing: it happens without compositing too, and even when only kdm runs. It also has a KDE bugreport (since it only seems to happen with KDE4): https://bugs.kde.org/show_bug.cgi?id=170462 but some say it's QT's fault: http://www.qtsoftware.com/developer/task-tracker/index_html?id=220550&method=entry So, I don't understand where the problem, however, today I tried KDE 4.2.1, and that seems to solve the problem completely!!! (Except that compositing is very slow with XRender, and any openGL usage (either compositing or just an openGL screensaver) makes the X server quite unstable). So, now it seems to be solved somehow by KDE 4.2.1. Does anybody else have som experience with KDE 4.2.1?
Does Option "ExaOptimizeMigration" "off" work around the problem?
(In reply to comment #13) > Does > > Option "ExaOptimizeMigration" "off" > > work around the problem? > Since upgrading to KDE 4.2.1 solved the problem, I thought that I was unable to test this for you. However, surprisingly just changing the kdm theme package from kde4-kdm-branding-upstream to kde4-kdm-branding-openSUSE caused my machine to produce the symptoms again, but only during running kdm. The KDE session works without problems. Then I tried this: Section "Device" BoardName "945 GM" Driver "intel" Identifier "Device[0]" Option "monitor-LVDS" "Monitor[0]" VendorName "Intel" Option "ExaOptimizeMigration" "off" EndSection But it didn't help. Is it the appropriate section for this option? BTW, how can a package consisting mainly from images change kdm's behaviour so badly? milleniumfalcon:~ # rpm -ql kde4-kdm-branding-openSUSE /usr/share/doc/packages/kde4-kdm-branding-openSUSE /usr/share/doc/packages/kde4-kdm-branding-openSUSE/COPYING /usr/share/kde4/apps/kdm /usr/share/kde4/apps/kdm/pics /usr/share/kde4/apps/kdm/pics/.randomlist /usr/share/kde4/apps/kdm/pics/kdelogo.png /usr/share/kde4/apps/kdm/pics/shutdown.jpg /usr/share/kde4/apps/kdm/pics/users /usr/share/kde4/apps/kdm/pics/users/default1.png /usr/share/kde4/apps/kdm/pics/users/root1.png /usr/share/kde4/apps/kdm/themes /usr/share/kde4/apps/kdm/themes/SUSE /usr/share/kde4/apps/kdm/themes/SUSE/Background.jpg /usr/share/kde4/apps/kdm/themes/SUSE/Background.svg /usr/share/kde4/apps/kdm/themes/SUSE/KdmGreeterTheme.desktop /usr/share/kde4/apps/kdm/themes/SUSE/color.kcsrc /usr/share/kde4/apps/kdm/themes/SUSE/dots.png /usr/share/kde4/apps/kdm/themes/SUSE/enter.png /usr/share/kde4/apps/kdm/themes/SUSE/opensuse.png /usr/share/kde4/apps/kdm/themes/SUSE/screenshot.png /usr/share/kde4/apps/kdm/themes/SUSE/suse.png /usr/share/kde4/apps/kdm/themes/SUSE/suse.svg /usr/share/kde4/apps/kdm/themes/SUSE/suse.xml
Hi, Option "ExaOptimizeMigration" "off" didn't work for me either. I'm also using kde4.2.1 by the way. Switched to kde4-kdm-branding-upstream from kde4-kdm-branding-openSUSE based on what Tamás said and no more corruption. Now i get a blue image, probably opensuse next release wallpaper... but no "corruption". regards, Carlos
(In reply to comment #14) > Is it the appropriate section for this option? Yes. If in doubt, check the X server log file to verify the option is taking effect. > BTW, how can a package consisting mainly from images change kdm's behaviour so > badly? Is the kdm corruption also intermittent or persistent? Can you provide screenshots of it? Does it still only happen with EXA?
(In reply to comment #16) OK, I reverted to kde4-kdm-branding-openSUSE in order to be able to test it for you. > (In reply to comment #14) > > Is it the appropriate section for this option? > > Yes. If in doubt, check the X server log file to verify the option is taking > effect. OK, I checked. It took effect, but didn't eliminate the problem. > > BTW, how can a package consisting mainly from images change kdm's behaviour so > > badly? > > Is the kdm corruption also intermittent or persistent? Can you provide > screenshots of it? I don't clearly understand, what you mean here, but I think it's rather intermittent from your point of view. Take a look at the attached video in comment #2, and/or the videos in the comments #1, #2 and #3 at https://bugzilla.novell.com/show_bug.cgi?id=464512 . You can find screenshot images, too, for example in #1 here, or somewhere in the mentioned Novell bugreport, or at http://bugs.kde.org/show_bug.cgi?id=170462 . > Does it still only happen with EXA? Placing the following line into the Device section definitely eliminates the problem: Option "AccelMethod" "XAA"
Two things to notice about this "corruption". First is that it appears when the screen flickers. During login, the loading bar progresses and the screen flickers twice, i think, and it's during that time that the messed up images appear. So maybe it's initiating the driver/card or something similar. Second thing is that this corruption sometimes consists of partial images of the desktop or open apps during the last time the computer was on. By the way, updating to kde4-kdm-branding-upstream from kde4-kdm-branding-openSUSE did not fix it afterall, as now i see this corruption when looking at pdf files. regards, Carlos
(In reply to comment #18) > bar progresses and the screen flickers twice, i think, and it's during that > time that the messed up images appear. Are the flickers due to the video mode being reprogrammed, or something else? > By the way, updating to kde4-kdm-branding-upstream from > kde4-kdm-branding-openSUSE did not fix it afterall, as now i see this > corruption when looking at pdf files. So it isn't limited to kdm after all? Though I'm again wondering if we're only dealing with one single issue here...
Created attachment 24011 [details] Compiz cube caps after starting an openGL application (e.g. glxgears) Maybe totally unrelated to this problem, but recently I switched to compiz, and realized that after starting an openGL application, the cube caps get filled to some visual noise, very similar to the one, which this report is about. (See this attachment.) It sometimes happens after a suspend/resume cycle. Reloading compiz cleans up the visual noise. Switching to XAA acceleration from EXA (like above) NOES NOT HELP in this case anyway.
Created attachment 24012 [details] Reference image: cube caps should look like this (Geeko)
(In reply to comment #20) > Maybe totally unrelated to this problem, It most definitely is. > but recently I switched to compiz, and realized that after starting an openGL > application, the cube caps get filled to some visual noise, very similar to the > one, which this report is about. (See this attachment.) It sometimes happens after a suspend/resume cycle. Reloading compiz cleans up the visual noise. Sounds like the X driver doesn't properly invalidate texture storage on VT switches. I think there's a bug report about this against the intel driver.
(In reply to comment #19) > (In reply to comment #18) > > bar progresses and the screen flickers twice, i think, and it's during that > > time that the messed up images appear. > > Are the flickers due to the video mode being reprogrammed, or something else? Regarding the login, after choosing the user/pass and pressing enter, the screen goes black for half a second or something and then the pic with the loading bar appears. If i have desktop effects enable it will "blink" one more time during loading before entering the desktop. If not, it goes straight to the desktop. So, if i use exa acceleration (added: Option "AccelMethod" "EXA" : to the xorg.file) i get "corruption" in the two situations i mentioned above. This is in opensuse11.1 64bit, with KDE4.1 and KDE4.2, and kubuntu 8.10 (livecd). I also tested on another pc, with a ATI 9700pro card (r300), using an opensuse live cd (32bit) with the same result. If i chose gdm as the display manager there is no corruption. > > By the way, updating to kde4-kdm-branding-upstream from > > kde4-kdm-branding-openSUSE did not fix it afterall, as now i see this > > corruption when looking at pdf files. > > So it isn't limited to kdm after all? Though I'm again wondering if we're only > dealing with one single issue here... Unfortunately i haven't been able to reproduce the corruption i've been seeing only in kde apps... so maybe that's something different and not related. So, could this just be a kde4 problem, and not related to xorg? What i find weird is that sometimes the corruption is pieces of the desktop or apps that i used before reboting... so that's info that remained o the graphics card (framebuffer?). regards, Carlos
(In reply to comment #23) > So, could this just be a kde4 problem, and not related to xorg? It's hard to say, though the latter still seems more likely.
I experience the same problem. My configuration: - ATI Mobility X1600 - opensuse 11.1 - KDE4 4.2.69 (svn) - X-server 1.6.0 - xf86-video-radeon 6.12.2 - drm from git I notice the garbled screen when using EXA (sort of cached pixmaps) when X/KDM is loading, then it occurs again immediately after login when the splash screen starts (with XAA and fglrx I get a black screen instead of this corruption). Is the following commit, from 2009-04-09, to the radeon driver related to this bug? Clear the framebuffer before initializing modes. Fixes garbage being visible shortly on server startup or when VT switching back to X. I couldn't compile the driver to test it.
(In reply to comment #25) > Is the following commit, from 2009-04-09, to the radeon driver related to this > bug? > Clear the framebuffer before initializing modes. > Fixes garbage being visible shortly on server startup or when VT switching back > to X. No, this report is not related to X server startup nor VT switching back to X.
Michel, Looking through the bug report here I see both Intel and Radeon hardware and issues specific to EXA. So if I'm reading that right, I'll reassign this bug to you. If I'm reading that wrong, and there's an Intel-driver-specific bug here, then Tamás or whoever has the problem, please feel free to open a new bug against x86-video-intel. Thanks, all. -Carl
Or if comment #6 is actually about the same problem, maybe it's not an EXA bug at all... Has anyone been able to reproduce this outside of OpenSUSE?
Is this still a bug?
(In reply to comment #29) > Is this still a bug? No, AFAIK.
(In reply to comment #30) > (In reply to comment #29) > > Is this still a bug? > > No, AFAIK. Thanks, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.