Version: (using Devel) OS: Linux Installed from: Compiled sources Sometimes (about 20-30% of cases) plugging or unplugging the ac freezes plasma (and everything else) for about 30 seconds. Mouse moves and the cursor changes accordingly (text cursor on text fields, resize cursor on boundaries of windows), the keyboard is unresponsive. After this time all windows get repainted and everything is back to normal and apparently all the past keyevents are processed at once. This is easy to reproduce (for me) by fiddling around with the ac plug; as far as I remember it happened some time after beta 1. I believe that this is probably just a way to trigger another freeze already reported in bugzilla. J
if you kquitapp plasma and fiddle with the crt while plasma isn't running, does it still freeze?
Good point, Aaron, sorry for blaming plasma. i kquitapp'd plasma and played with the power adapter; after a few cycles of pluggin-unplugging, everything froze again, in some areas of the desktop there was, oddly enough, the kdm wallpaper. After ~30 sec I was again back to normal. It seems that nothing gets repainted. Is it a kwin issue?
try running a different window manager, e.g. do `metacity --replace&` and see if you can reproduce it that way. if so... try stopping kded (to see if it is kephal, which gets loaded as a kded module) and see if it is still producable that way. in fact you could just start an empty X session and see if it triggers then to rule out (or in) x.org or the driver itself.
First of all I'd like to provide an additional detail, I can reproduce the freeze by switching back and forth from "powersave" to "performance" setting in powerdevil several times. Metacity seems not to freeze as kwin, alt-tab works, windows move and I can interact with them (i.e. writing this right now), but plasma is frozen and unresponsive. Moreover, starting kwin --replace after a freeze takes a long while (again ~30sec). .xsession-errors does not seem to give any meaningful insight... J
Update: I recompiled yesterday from trunk. Now kwin seems more responsive, i can close windows but not interact (e.g. write on a text field) with them. Plasma is completely frozen and keyboard input (alt-tab and such) is not processed until plasma defrosts. The power profile is activated AFTER the freeze (e.g. brightness is restored after the freeze); can it be that powerdevil locks everything else?
i can confirm the same behaviour with trunk compiled about 7hrs ago (qt-copy: 904364, kdelibs:904337, kdebase:904348) BUT for external USB devices on connection, i.e., 1. connect usb external harddisk 2. device plasmoid shows device 3. click device opens dolphin 4. connect another usb device 5. device plasmoid shows device 5. click device opens dolphin after ~ 30 seconds or longer during which plasma is inactive, i can type things into konsole etc, but panel/menu/rightclick on desktop/alt-f2 all non-responsive
comment #6 indicates an issue that is unrelated to this report. comment #6 could be due to a number of root causes and would require some research done on the system it is happening on to be of use.
please let me know what i can do to figure out what is the cause of the lockup
I am CC-ing Dario Freddi as powerdevil seems to trigger this. (I don't quite understand how, though) I still encounter the bug as for 4.2.0; changing the power profile freezes kwin & plasma for about 40-60 seconds. Apparently, as for my configuration, powerdevil_daemon cannot use the XSyncBased Poller and I've been able to reproduce the behaviour with both the WidgetBasedPoller and the TimerBasedPoller (this may not be related, though) Apparently, the last method called before the freeze is PowerDevilDaemon::applyProfile however, quite often, when I kquitapp kded; kded4, this method terminates and the freeze starts later on. Once more, the system becomes unresponsive, windows are not repainted and keyboard and mouse input is not processed. Once the "freeze" is over, the windows are repainted and one can see that all programs have been running in background (I checked this with something like $while /bin/true; do sleep 1; date; done ) Actually this might well be a duplicate of bug #177123
*** This bug has been marked as a duplicate of bug 177123 ***