Version: (using KDE 4.2.98) OS: Linux Installed from: Ubuntu Packages Okay, first off, i do not really know whether plasma is to blame here. It has probably to do with my hardware or somethin, or someone would have reported this already (and maybe someone has, because i can't really figure out how to describe this). Anyway, this is what happens: - I plug in my external LCD display - I use the Fn+CRT/LCD key on the keyboard to switch from the built-in monitor to the external screen - a little while later, my screen freezes and the changes from a normal desktop (see image 1) to this (see image 2) My Hardware: Dell Precision M4400, nVidia Quadro FX 440M graphics card, proprietary drivers. i also tried using the opernsource drivers, but they are _really_ slow. DOes anyone have an idea what causes this? Or at least where i could find someone who can tell me what's going on?
Created attachment 35779 [details] The screen before the error
Created attachment 35780 [details] The screen after the error
also, i apologize for the poor image quality, i had to use my cell phone camera for this.
The error happens earlier and more often when i have an flash-based website open in firefox or konqueror. Sometimes, i can use ctrl+alt+backspace to restart the x screen, but most times that does not work and i have to resort to alt+print+(s,u,b) to reboot the entire system. And there were a few times when even that did not work :(
Err. this is probably a graphics drivers bug. Let's reassing (unrelated to Plasma) and ask KWin guys. Are you using compositing/effects ? What is your drivers version? Is it updated? Regards
assumption 1: your external monitor has a different resolution than the NB dev? assumption 2: you're using compositing assumption 3: you're running kwin, not compiz -> press alt+shift+f12 (to suspend compositing) -> switch your display -> press alt+shift+f12 again (to resume compositing) works?
@Dario Andres: compositing / kwin effects: yes driver version: 180.44-0ubuntu1 (which is the driver version recommended by envyng) updated: uhm is assume you mean if its the newest version available? it is, at least via envy @Thomas Lübking: assumption 1: nope, both run at 1900x1200 assumption 2: yes assumption 3: yes solution: sory, once the screen is garbled up like that, it won't respond to anything (mostly). On rare occasions i have been able to salvage the session by switching to a console, killing plasma and kwin, switching back and restarting them. But in most cases all the keyboard shortcuts that are caught by the X Server do not work anymore, this goes for alt+shift+f12 as well. Thanks for your quick responses :)
i meant to suspend /before/ you mess up your system (by switching displays) and resume /after/ (in case it didn't mess - due compositing being disabled) 180.44 is however pretty outdated - i know it's not great regarding a clean package system, but could you please try to install the latest (stable+beta) drivers from here http://www.nvidia.com/object/unix.html and here (beta) http://www.nvidia.com/Download/Find.aspx?lang=en-us note: it appears nVidia has pulled back the /current/ ia32 beta driver for whatever issue (at least the link is dead) a) that makes it a bad long-term solution ;-) b) direct link: http://us.download.nvidia.com/XFree86/Linux-x86/190.18/NVIDIA-Linux-x86-190.18-pkg1.run
Hi, i can try that, but it will probably take a while. The point is, that the screen is not messed up like that "immediately" sometimes it takes just a few minutes, the next time it may be 3-4 hours before something happens. I even had entire sessions on the external monitor where nothing happened at all.
@Dominik: did you try even with other desktop enviroments (and window managers, of course) ?
so usually you can operate on the ext. monitor for a while? (i.e. it's not /directly/ related to the switch. in case, please confirm so the but get get marked "upstream") in this case i'd blame nVidia (or you for using outdated drivers ;-) to trace this issue you should look into /valr/log/Xorg.0.log (esp. for EE) can you ssh the broken machine for "in-crash" inspection? note the def. approach is alt+sysreq+r/e/i/s/u/b (not just s/u/b) and can leave use with a running system just w/o X11 (also you should wait a few seconds between the sysreq's)
Hi, i upgraded to the 185 driver (i had to use the amd64 version for some reason) and the error has not appeared since then. I might be celebrating too soon, but i think i'm in the clear :) thanks a lot for all your suggestions :) Dominik