In Kubuntu 14.04 (KDE 4.13.0), I use imwheel 1.0.0pre12-9 to map the extra thumb-buttons of my LogiTech M510 to some useful keystrokes for certain programs. This works fine, it will start nicely when my computer switches on and it will even survive suspend to RAM.

Problem is, imwheel often halts, when tv-browser.org pops up an automatic notification. I configured those notifications in KWin to always show on top and also enabled the focus steeling prevention. Also TVB is not the only program to kill imwheel.

If I haven't moved the mouse for a few seconds, imwheel will survive a TVB notification. If I'm actively using the mouse (scrolling/left-clicking/dragging) the moment, one of those popups appears, the extra-mappings of imwheel are defunct thereafter.

I ran imwheel from the console: no errors get displayed. The process of imwheel is still hanging around, but doesn't do anything anymore. It happens about once every hour, so I pretty much cannot rely on the thumb button currently issuing the command, I programmed it to or issuing e.g. a back in Firefox per default-configuration bypassing imwheel.

My questions:

  1. Anybody else ever suffered this problem?
  2. How and where to get help on this complex scenario?
  3. Shall I report a bug against KWin? In launchpad or upstream at kde?
  4. Who is maintaining imwheel? There is only an outdated http://imwheel.sf.net from 2004
  5. Can you recommend a more up to date alternate software for mapping mouse-thumb-buttons to key-strokes in Kubuntu / KDE?

Thanks for your time and advice


Found more ways to kill imwheel almost reliably.

  • In Firefox, when I save a small download / an image to my harddrive there is an animation of the green arrow icon. If I click my thumb-button (supposed to close the current tab by Ctrl+W) within two seconds of that animation, the tab won't close and imwheel is defunct everywhere (also in other programs/windows)

  • After switching windows or desktops I have some fancy 3D effects enabled. If I'm too fast clicking one of the thumb-buttons right after such an animation, imwheel gets defunct to.

As a wild guess I'd say, imwheel somehow tries to deliver it's derived key-events that translated from the thumb-button-presses, to some graphic overlay, which is not a full fledged window itself and certainly not supposed to ever gain keyboard-focus.

Finally I found "imwheel --kill" to be way faster for reactivating it (instead of logging out and in again). I even mapped that to a global keyboard shortcut.


Debug shows, imwheel is ungrabbing buttons 4 to 9 and then waits eternally, never grabbing them again. Only a restart with -k can bring it back.

The easiest scenario is to send a mapped thumb button to a configured window, which is in the background and does not have the focus. Debug output shows, imwheel testing against the window which has the focus, not respecting the mouse position over the other window. None of the ordinary rules apply to this window, but I made an exclude rule at the end of ~/.imwheelrc like this:

".*" @Priority=-1000 @Exclude

matching every window.

Removing/commenting this final exclude rule solves my problem. imwheel won't crash anymore.


When running imwheel from the commandline, use the options '-d -D' to see debugging information.

  1. I have had some issues with imwheel crashing/freezing in the past, though mine is much less reproducible than yours. It looks like we're not the only ones having an issue with imwheel: There are two suggested patches on the upstream tracker ( sourceforge.net/p/imwheel/patches/2/ sourceforge.net/p/imwheel/bugs/8/ ) which may help with your issue.
  2. Since the upstream project appears to be inactive, you may have better luck contacting the Debian maintainer for this project: chrsmrtn -AT -debian.org You might ask them to include one or both of the patches mentioned above. Package details are here: packages.qa.debian.org/i/imwheel.html
  3. Since imwheel is not behaving as expected, the problem is most likely in imwheel. If you file a bug for this problem, the bug should be filed against imwheel.
  4. The official support channel for this project is the Sourceforge page (see #1), which does appear to be inactive. (See #2 for more info)
  5. Easystroke is an alternative. From wiki.archlinux.org/index.php/All_Mouse_Buttons_Working :

    Go to Preferences tab > Additional buttons > Add, and add any special button.

    Note: In case of easystroke doesn't automatically detect mouse buttons, you can specify it manually. Button identifiers (numbers) can be viewed by xev.

    Go to Action tab -> Add action, give the new action a name, as Type choose "Key", as Details set "Alt+Left" for Back button, "Alt+Right" for Forward button, as Stroke click the proper mouse button (confirm if a warning is displayed), and voilà! Your mouse button is configured.

  • "imwheel -d -D -k" was really helpful. Thanks a lot! – user261217 May 10 '14 at 0:57

I was recently bitten by this, too, and it appears to be a bug in imwheel that has to do with @Exclude. Apparently the code responsible for restoring key grab after an exclude is activated is never executed.

There's a patch in the link above, and here as well. Apparently, the bug has been known since 2004 :D

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.