Version: (using KDE 4.4.0) OS: Linux Installed from: openSUSE RPMs I have opensuse11.2+kde4.4.00(release 223) installed on my system. Panel is at the top of the screen and Oxygen theme is set. When i plugin/plugout the charger, notification appears and the cursor is automatically moved to top left corner of the screen. For any other notification cursor stays where it is. I tried creating new user with all default settings but same bug again.
I can confirm that.
I can reproduce this bug here using: Qt: 4.6.1 (kde-qt master commit 46ef51d8bf520bda3eea9e996349694ce1ff3959 Date: Sat Jan 30 02:23:21 2010 +0100) KDE Development Platform: 4.4.63 (KDE 4.4.63 (KDE 4.5 >= 20100209)) kdelibs svn rev. 1090634 / kdebase svn rev. 1090635 on ArchLinux i686 - Kernel 2.6.32.8 It is weird, I'm not sure which app to blame...
Dario, this bug belongs to kdelibs/kdeutils, to KIdleTime in particular (which I maintain, so the assignation is correct nevertheless). To the point, this happens to "fake" user input to reset idle counters when a power cord event is triggered. Last time I tried XTest faking "fake" key presses was not sufficient, hence I added this workaround. I'll try finding a more effective (and mostly less annoying) solution, which might be getting back to key presses, a slight movement of the mouse, or a fast move to top corner-get back to previous position. I'll investigate in the next days, however due the workload I have at the moment I can't guarantee a fix by 4.4.1. For sure for 4.4.2 I'll do something, though.
It is nice to know that you know where to look at, in order to improve the situation. Thanks! Reassigning to kdelibs
*** This bug has been marked as a duplicate of bug 218468 ***
We've recently started using KIdleTime in Konversation for auto-away support, and this is hugely annoying - when Konversation is started, the cursor moves to the top-left corner. What's more, if it's started inside an NX session (http://en.wikipedia.org/wiki/NX_technology) the mouse cursor is stuck there and the dies after a few seconds of trying to move the mouse cursor. Fun stuff.
s/and the dies/and the app dies/ (It's probably getting killed by the server.)
Hi, there was a X.Org bug with the same symptoms: https://bugzilla.redhat.com/show_bug.cgi?id=490984 https://bugs.launchpad.net/ubuntu/+source/vino/+bug/337926 unfortunately a patch which was supposed to fix this bug was commited more than one year ago: http://cgit.freedesktop.org/xorg/xserver/commit/?id=603db34337a61754e0c5f71525011d10eab78411 maybe a windows/mac user could confirm this problem does not occur on other platforms than linux? Regards, Martin
Created attachment 42985 [details] a small test-case this is a small test-case for the current bug (note: it's just one big hack. if you look at the code your eyes may get damaged - you've been warned ;)). how to use this: simply call: ./compiledbinary old then it uses XTestFakeMotionEvent() to "simulate" input if you leave out the "old" parameter it uses XTestFakeRelativeMotionEvent() which is supposed to fix the problem.
Created attachment 42986 [details] possible fix for the described behavior I also wrote a patch which is supposed to fix the described behavior. unfortunately I could not test the patch yet (so it may not work).
Eike Hein and me tried to find out why Konversation would crash inside an NX session. We found out that the slot resumeFromIdle() (which is connected to the resumingFromIdle() signal from KIdleTime) was called in (basically) an infinite loop. The interesting part is that timeoutReached(int) was NOT called (just as a side-note: we are calling KIdleTime::instance()->catchNextResumeEvent(); in the constructor of konversation's AwayManager - so it's still possible that the resumeFromIdle() event is being emitted.). It looks like there is a problem somewhere in KIdleTime as this patch fixed the "infinite calling of resumeFromIdle()": http://www.gitorious.org/~xdarklight/konversation/xdarklights-konversation/commit/ea6f96a14503f25dedc620afb82161c61b47d4cb After resumeFromIdle() was emitted once KIdleTime should have reset the internal flag "catchNextResume" - but it seems it did not do this (note that we did not debug KIdleTime. I'm just assuming that the flag was not set to false). Quote from Eike Hein (who tested my patch against konversation): "it still moves the cursor top-left once, but no more repeated hammering" Regards, Martin
SVN commit 1118296 by dafre: BUG: 227279 BUG: 218468 Do not make the mouse fly away when simulating user activity. Thanks Lubos for the suggestion. M +4 -4 kidletime.h M +2 -1 widgetbasedpoller.cpp M +1 -11 xscreensaverbasedpoller.cpp M +3 -9 xsyncbasedpoller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1118296
SVN commit 1118297 by dafre: CCBUG: 227279 CCBUG: 218468 Backporting previous fix M +4 -4 kidletime.h M +2 -1 widgetbasedpoller.cpp M +1 -11 xscreensaverbasedpoller.cpp M +3 -9 xsyncbasedpoller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1118297