Mouse control issues with KDE Plasma

English Applications
1

I’ve started experiencing strange behaviour with the mouse and KDE. After a few minutes of working, using mostly Thunderbird and Firefox I find that the mouse will not respond on any of the window decorations or other windows apart from the one I was working on.

My mouse button control is severely impaired. The mouse control of window features is sometimes limited to one window with the rest of the desktop not responding to mouse actions. Popping up a second window (Alt-Tab) causes the mouse control to be completely lost. The issue leaves KDE effectively broken having only keyboard control. With some ESC key hits and Alt-F4 to close the focused window, I can move focus to another window but mouse control within the window is non-existent. Moving windows or raising or lowering doesn’t work either. Sometimes, the GUI captures the mouse click but does not recognize the active window and applies it to objects sitting on the desktop screen underneath. Nothing on the panel responds to mouse clicks apart from the kicker which opens but I am not able to make a selection from it.

I’m using 12.1 with KDE 4.7.4. I’ve tried turning off Desktop Effects which improves things but eventually I end up with the same problem. As an experiment I tried switching to KDE 4.9 but the problem still exists. I don’t remember doing any system updates before the problem started so am not sure what kicked this off.

Has anyone else experienced this behaviour?

2

OK, I did some more testing and the problem definitely doesn’t seem related to having desktop effects enabled or not as it manifests itself whether I have desktop effects enabled or not. It just takes longer for the problem to materialise if effects are off. Restarting kwin by using Alt-F2 then typing

kwin --replace&

restarts kwin and restores some mouse functionality, i.e. I can then click on the various applications on the task panel and bring them into focus but there is still no response when clicking on the window decorations. Killing the session by hitting Alt-Ctrl-Backspace and logging in again doesn’t really help either.

I tried to find clues in the logs but not sure which logs to look in.

In the kdm.log I have the following:

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux suntp001.site 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40 UTC 2012 (d016078) i686
Kernel command line: root=/dev/disk/by-id/ata-ST9500325AS_5VE9B458-part5 resume=/dev/disk/by-id/ata-ST9500325AS_5VE9B458-part8 splash=silent quiet vga=0x31a
Build Date: 10 November 2011  03:34:02PM
 
Current version of pixman: 0.24.0
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 29 08:19:22 2012
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
(EE) PreInit returned 8 for "TPPS/2 IBM TrackPoint"
klauncher(1558) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. 
kdeinit4: Communication error with launcher. Exiting!
kdmgreet(1544)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed:  "Not connected to D-Bus server" 

kdmgreet(1544)/kdecore (K*TimeZone*): No time zone information obtained from ktimezoned

Two things catch my eye.
“(EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device” No idea what this means.
and
“klauncher(1558) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. kdeinit4: Communication error with launcher. Exiting!” DBUS is started and running so I don’t know why this is coming up. Perhaps the dbus is not starting soon enough? The timezone initialising fails for the same reason.

I don’t have an .xsession-error log in my home directory. Should I have one?

I also have these errors in my localmessages log. These date back to Jan 16th so I don’t think they are related.


<snip>
Aug 27 14:10:39 suntp001 checkproc: checkproc: can not get session id for process 22056!
Aug 27 15:21:17 suntp001 checkproc: checkproc: can not get session id for process 1915!
Aug 28 07:39:42 suntp001 checkproc: checkproc: can not get session id for process 4387!
Aug 29 06:13:54 suntp001 checkproc: checkproc: can not get session id for process 1734!
Aug 29 06:44:40 suntp001 checkproc: checkproc: can not get session id for process 1721!
Aug 29 08:23:12 suntp001 checkproc: checkproc: can not get session id for process 1725!

Are there any other logs I can look at?

Any help would be appreciated.

3

I am having that same exact behavior in openSuse 12.3 kith KDE 4.10.1. The strange thing is, I wasn’t having this problem with 12.2. I have no clue.

4

Unfortunately I never found a real solution. What I can say is that I was experiencing that problem when I was using a Logitec cordless mouse. After swapping it for a corded USB mouse I never experienced the problem again so it points to the problem being hardware related - well in my case any way.

I haven’t bothered trying to figure out why the cordless mouse started causing the problem except trying another identical model cordless mouse which also gave problems. So for me it’s definitely something to do with the cordless mouse of Logitec as the problem occurs with two mice I tried. It’s strange that the problem occurred only after I went to oS 12.1. Before that the mouse worked without these issues.

If you’re using a cordless mouse try a corded USB mouse and see if that helps.

5

Hi,
I am observing the same cumbersome behaviour - but only in gtkpod (2.1.0). All other applications I use are working fine. I tried various versions of gtkpod, but the problem still exists.

Anyone an idea how to fix this?

Greetings,
Knut

6

Same issue in OpenSUSE 12.3 with KDE 4.10. Is it a bug? Should it been reported in buzilla or any other concerned place?

7

Hi,

I experienced mouse errors in xorg, highlighted in the Xorg.0.log file (useful log file to check and possibly post here) after 12.3 upgrade.

This is my suggestion:

  1. cd /etc/X11/xorg.conf.d
  2. sudo cp 11-mouse.conf 11-mouse.conf.org (make a copy)
  3. as a super user comment the section “InputClass”… EndSection containing the identifier "“TPPS/2 IBM TrackPoint” (add # at the beginning of each line of that section)
  4. save and reboot
  5. If at login time your mouse is not working at all, then you need to revert the changes by going in console mode (Ctrl + Alt + F1), and restoring the original file (cd /etc/X11/xorg.conf.d && sudo cp 11-mouse.conf.org 11-mouse.conf). Reboot, the problem is not solved and back to square one
  6. If the mouse is now working properly it is all thanks to the default mouse behavior picked up in 10-evdev.conf (in /etc/X11/xorg.conf.d) which is loaded before the file 11-mouse.config

Gualtiero

8

I can confirm there is a mouse control issue on my system as well. It seems to appear randomly and makes it impossible to interact with windows. Running openbox --replace helps to some extent, but when switching back to kwin --replace the problem reoccurs in most cases.

System:
OpenSuSE 12.3 x64, KDE 4.11, RadeonHD 7970 with proprietary driver. (I recently switched from geforce [using the nvidia driver] to radeon but the mouse problem remained.)

Pointing devices:
Apple Magic Trackpad, aditionally running touchegg for gesture support
Madcatz R.A.T.5 with button-workaround in the xorg.conf file

As the mouse control issue existed even before using touchegg or the R.A.T., it cannot be related to those.

9

EDIT: I think I’ve found it: Bug 238431 in the KDE bug tracking system (https://bugs.kde.org/show_bug.cgi?id=238431) seems to be what we are experiencing. Says it could be related to gesture support switched on in konqueror…

AND: it does not occur when I switch to openbox.

10

I have the same issue with my Logitech Wave keyboard and mouse. I have loaded several versions of linux trying to find one that will work for me. Versions of Ubuntu don’t load Grub correctly. OpenSuse and Fedoria have this mouse issue, and mint doesn’t have a drive controller for my computer. Sure would be nice to find some support somewhere.

11

I can confirm that this still happens in OpenSuSE 12.3 with the latest updates.

Starts happening pretty fast and almost always. It’s definitely nothing to to with malfunctioning hardware or drivers. It’s strictly a problem of KDE’s focus handling: both mouse movement and all kinds of button events are still seen by X, it’s just that button events are still passed to the previous window while keyboard events arrive in the current window.

I tried every possible combination of Focus handling policies under “Configure desktop”, but none of them fixes it consistently. Workaround: switching to another virtual desktop (or activity) and back via the keyboard almost always fixes it for a while, otherwise I wouldn’t be able to work at all with this install.

The linked bug seems to be about inconsistent behaviour of the mouse wheel vs. the mouse buttons, so it’ something different. Should we report this and clamor for a bug fix somewhere?

12

Hm. I never encountered any mouse issues with any openSUSE or KDE version here.

Starts happening pretty fast and almost always. It’s definitely nothing to to with malfunctioning hardware or drivers. It’s strictly a problem of KDE’s focus handling: both mouse movement and all kinds of button events are still seen by X, it’s just that button events are still passed to the previous window while keyboard events arrive in the current window.

Sorry to ask, but what do you mean exactly with this?

To clarify:
Mouse button events are sent to the window the mouse cursor is over, not the active window.
So if f.e. you move the mouse wheel while hovering over an inactive window, the inactive window will scroll its contents not the currently active one.
This is no bug.
This is how X behaves at least since I started using Linux 11 years ago, and is the behavior I expect. I always get annoyed that the active window gets the mouse wheel events when using Windows.

The linked bug seems to be about inconsistent behaviour of the mouse wheel vs. the mouse buttons, so it’ something different. Should we report this and clamor for a bug fix somewhere?

Well, if you think there’s a bug, you should report it.

But it might help finding out first whether the possible bug is actually in KDE or in X itself. Does your issues also occur when using a different desktop environment/window manager? (you can select a different session at the login screen by clicking on the wrench icon. at least “IceWM” and “twm” should be installed by default)

Also, if you are just not satisfied with X’s default behavior (see above), a bug report might not make sense. Maybe there’s even some config option to change it?

13

Let me describe the most egregious kind of this issue.

I work with a window. Both keyboard events and mouse events are sent to the window; e.g. I can scroll it with the mouse wheel, by clicking the scrollbar area, by dragging the scroll bar, or with the Prior/Next keys.

Then I change the window via Alt+Tab. The new window comes to the front, completely covering the old window. I can type into the new window, but when I use the mouse, it interacts with the old window (which can cause really unusual error messages, such as XEmacs complaining “Not over a window!”). Whatever I do with the mouse - clicking, moving, dragging - I can’t make the mouse talk to the new window at all. Even when I click on the new window’s title bar and try to drag it around, nothing happens - the window control icons don’t even acknowledge that I’m touching them.

By this time I’ve both tabbed to the new window AND clicked into it like a monkey on speed, but mouse events are still routed to the old window. Can that possibly be right? Is there some really weird focus handling policy that I might have inadvertently activated where this is expected?

14

OK, I never saw anything like that.

Would sound like a graphics driver issue though. Or kwin, but I’d think more people would have this problem then.

Is the new window shown as active? (you can enable the “Outline active window title” option in Configure Desktop->Workspace Appearance->Window Decorations->Configure Decoration…->Fine Tuning to better see which window is actually active)
Does disabling Desktop effects help? (Shift+Alt+F12)

What graphics card/driver are you using?

15

I see the problem from time to time, and like others reporting in this thread use a logitech mouse.
It seemed cured for a long time for me (saw it in 12.2 but not 12.3 and 13.1 using KDE 4.11) but returned when I updated to KDE 4.12

It has never really bothered me as I am using a thinkpad that has a touchpad and trackpoint.
Basically, the logitech mouse loses focus. I can still mouse around but the button / cursor when clicked still remains focused / locked to the previous window I was working.
I can overcome this by clicking into the trackpoint or touchpad to regain focus - from there the logitech mouse works fine again.

But I can see if you didn’t have a touchpad as an alternative it would be a hassle.
If I was in this situation I would just get another brand of mouse rather than waiting for a bugfix. :open_mouth:

16

Okay, here’s what I run: OpenSuSE 12.3,
kdebase4-openSUSE-12.3-10.111.5.i586
kdebase4-runtime-4.10.5-1.104.5.i586
kdebase4-session-4.10.5-1.100.1.noarch
kdebase4-workspace-4.10.5-1.119.1.i586
kdelibs4-4.10.5-1.105.1.i586
kdelibs4-core-4.10.5-1.105.1.i586
libkde4-4.10.5-1.105.1.i586
libkdecore4-4.10.5-1.105.1.i586

NVidia GeForce GTX 650 under proprietary driver NVIDIA-Linux-x86-331.49 (which works fine otherwise)
Legacy keyboard with PS/2-style connector
Logitech cordless optical mouse

  • Update: Switching to a “LC-Power optical mouse m710B” seems to cure the problem, at least for the minute I’ve been trying it so far.
17

Okay, refreshing my mouse batteries also did the trick. It seems that
I have to treat this focus problem as just another early indicator of
my mouse battery going down.

Thank you very much for your help! I have to admit that I would never
in a thousand years have considered that this kind of focus problem
could be anything to do with the mouse hardware. It looks
like I was chronically missing FocusOut or EnterNotify events, but
aren’t those generated by the driver rather than the mouse itself? Can
it be that a failing mouse generates enough motion events that it
looks to the user as if it’s working, but so few that X keeps
missing the focus change events it would need to instruct the window
manager correctly?

18

I don’t think this seems like a plausible explanation - at least for the OP.
In my situation I still see from time to time with fully charged batteries.

19

I can confirm this same issue on Leap & Plasma5 with intel graphics drivers (GM45 on Lenovo Thinkpad SL500). I occasionally also plug in a cordless Logitech mouse but it does not seem to be directly related when the bug occurs. EDIT: plugging the HDMI screen can also trigger the issue (but again, not systematically reproducible)

20

Probably best to start a new thread this one is a bit old

Does this machine run the new Intel skylake processor?