Misc: Wherein I Curse Ubuntu For Needlessly Breaking Something Useful
Lately I've found less and less of a reason to bother booting into my windows partition. I've used Linux as my primary operating system for at least 6 years, but I always kept a windows partition handy for when I wanted to play games. Now, The Wine Project has advanced to the point that all of the games I currently play I can play in a Linux environment, and all the windows applications I currently use are supported by Wine and by Crossover Linux, a Wine derivative customized to run windows office software.
My distro of choice is Kubuntu, a version of Ubuntu that is integrated with the KDE Desktop. Kubuntu has gone through some growing pains of late, since the latest version has formally adopted the latest version of KDE's desktop, KDE4, as it's official GUI. Unfortunately, KDE4 isn't quite finished yet and it looks like it won't be a real boy until they release KDE 4.2. Those birth pains are worthy of their own rant, but that's a topic for another day.
Today's topic is the utterly abysmal way that Ubuntu and Kubuntu support mouse buttons. And it is today's topic because not only is their support of mouse buttons abysmal, but as of their latest release they've actually taken a step back and gone from abysmal to nearly useless.
Back in the mists of time when Apple mice had one button and PC mice tended to have two, mice attached to a Unix box often had three. Unix users, unphased by the added complexity of an extra button, programmed the button so that it would easily perform various tasks for them while they were doing their work. As a result, Linux distributions pretty much have no trouble at all supporting three-button mice, and even have ways to make two-button mice act like three-button mice.
This is all well and good if you're still living back in 1996. But now it's nearly 2009, and you can go into a freaking Officemax or Office Depot or Staples or even Wal Mart for crying out loud and buy a mouse with as many as 7 to 10 buttons on it... and Linux will still support three.
Before I get to the rant portion of my rant, I want to be fair here -- Linux developers are working at a disadvantage when it comes to supporting mice. There are a lot of mice on the market, and while both Windows and OSX provide generic driver support for most mice, mouse manufactures provide their own enhanced drivers to enable the extra buttons and features that the extra-endowed mice come with... and they don't lift a finger to do that for the Linux platform, because Linux is (of course) a threat to our American way of life. So Linux developers are forced to re-invent the wheel where mouse driver functionality is concerned, and since they've also been forced to do the same thing for more important technologies (like bluetooth support and wireless networking), progress hasn't been what you might call "dramatic." In fact, the rule of thumb has pretty much been "Linux will probably support all your basic mouse functions, but if you want to do anything clever with your mouse you're going to have to muck around with configuration files and probably crash your X Server at least twice before you sort of get it working."
But for a brief, glorious moment in the history of Linux mouse driver development that began to change. A bloke named Olli Salonen came up with a landmark application in the world of mouse driver configuration. He called it btnx, which follows in the venerable tradition of giving good Linux applications obscure and occasionaly stupid names. What it did was outstanding: it figured out what signals your mouse sent when you clicked a button and let you assign commands to those mouse clicks.
Training btnx to recognize mouse events was relatively simple, though it could get tedious: first it learned to recognize when a signal was coming from the mouse, then it learned to recognize the difference between each mouse button. Once it did that, you were able to configure each button command separately, and that was pretty much it.
With btnx I was able to get my Logitech MX Revolution mouse to behave exactly the same way I'd set it up to work in my Windows partition, and it worked in every application I ran in Linux except for Firefox 3.0 (because the Firefox 3.0 developers tore a page from the Gnome UI development handbook and decided they knew what I wanted my mouse buttons to do better than I did, even though they were completely wrong).
I first learned about btnx when I was using Ubuntu 7.04 (the "Feisty Fawn" release), and it was a hallelujiah moment for me. I was able to configure the two thumb buttons on my mouse so that they emulated the shift and alt keys, which made it easier to access certain commands in Inkscape that I used a lot. When I wound up buying my beloved Logitech MX Revolution mouse I was able to completely customize the extra buttons to give me extra navigation controls, to active the Shift, Ctrl and Alt keys via button presses, and even to remap the "touch to search" button to act as the middle mouse button (which at one point the native Logitech drivers weren't able to do without using a third party driver supplement).
I used btnx with the 7.04 ("Feisty Fawn") release of Ubuntu and Kubuntu, the 7.10 ("Gutsy Gibbon") release, and the 8.04 ("Hardy Heron") release. Then when 8.10 ("Intrepid Ibex") hit beta, btnx stopped working. On September 14, Olli Salonen posted the following message on his site:
Good and bad news. Bad news first. Ubuntu Intrepid Ibex, which is to be released in October, breaks the foundations that btnx was built on. It seems that the kernel input event pipes can no longer be read. It is most likely related X.Org v.7.4. This means I will stop all development of btnx.
The "good news" was that evdev, an all-in-one Linux driver, had progressed to the point where it could replicate most of btnx's functionality as long as you were willing to delve into a rather arcane configuration process. But even after going through that heightened level of frustration it's not possible to replicate the feature that I most prize -- the ability to assign shift, ctrl and alt keyboard commands to mouse buttons.
In short, some jackass in the Ubuntu development group decided it was OK to break a piece of software that I had come to view as evidence that Linux had reached the point where it was overcoming not just the big obstacles to end user acceptance, but it was actually starting to work on the small stuff... and didn't bother replacing it with anything just as good or better. And the workarounds that exist don't actually help me much, so I find myself considering going back to a previous version of Kubuntu, or even switching to another distribution entirely (btnx apparently still works on openSuSE and Fedora just to get that functionality back.
I never realized exactly how much I depended on this little program until the Ubuntu developers broke it. The thought of having to learn the quirks of another damn distro just to get that functionality back is not a happy one, but I'm actually considering it.
So thanks for breaking btnx, Ubuntu devs! And while I'm at it, thanks for not saying anything official about it, and thanks for not announcing any replacements for it!









Comments
It's not just ubuntu
Fedora 10 will likely have the same issue as it also moved to evdev.
It's an evdev issue?
You could use btnx with evdev in Hardy.
That's why you use a decent
That's why you use a decent distro, like Gentoo. :P
I don't have the two weeks
I don't have the two weeks needed to compile a complete Gentoo system. :)
Do you get any output from
Do you get any output from xev when you place your mouse in the xev window and press your extra mouse buttons?
Yep -- that's not the problem...
xev has info on all my mouse buttons. I can assign commands to them, as long as it's not the shift, ctrl or alt key.
Here's a post that sort of explains the problem I'm having:
http://ubuntuforums.org/showpost.php?p=6254522&postcount=35
Out of curiosity...
does Ubuntu (Kubuntu) support a choice of kernels, at least to the extent of allowing one to stick to a slightly older kernel rather than always going with the latest stable release?
As far as I know (which is not necessarily saying much), new kernel releases are meant to support recently introduced hardware (as in "bleeding edge" stuff which previous kernels did not know how to support) and to improve various behaviors (e.g. better desktop response for workstations, better virtualization for servers, etc...
So if your chosen hardware does not absolutely require that latest stable point release of Linux (the kernel), and if you are satisfied with other aspects of a previous kernel's operation for YOUR usage modes, couldn't you just maybe "downgrade" Intrepid Ibex to the last stable kernel that supports btnx? That just might keep you running smoothly for a couple of years, and by then someone, somewhere, might have come up with a new way to do with the newest kernels what you have been doing with previous kernels.
Mind you, (since (K)ubuntu 8.04, aka "Hardy Heron" is their second (and latest so far) LTS ("Long Term Support") edition, you could conceivably stick with it for its projected supported lifetime of 3 years (for the desktop). And since the server edition of Hardy Heron LTS will be supported for 5 years, chances are that its sibling desktop edition will remain quite usable beyond 3 years...
I'm just sayin'...
Yeah...
I'm not really confident in my ability to downgrade a kernel.
I have considered going back to Hardy. But it's worth noting that while Ubuntu Hardy is LTS, Kubuntu is not -- it's only supported until October 2009.
I see your point about the non-existent Kubuntu LTS, and yet...
the documented (and, one presumes, SUPPORTED) way of converting the ... dare I say it, "Canonical" Gnome-based edition of Ubuntu into Kubuntu, is by simply installing the "kubuntu-desktop" meta-package with the Package Manager. I wonder if doing it this way would end up producing a non-LTS Kubuntu, or a usable Kubuntu with some semblance of long-term support...
Oh, and btw, are you that attached to KDE, and/or to some KDE-dependant apps? I used to swear, to myself anyway, that I would never give Gnome another look after having discovered KDE (maybe due to all those years of Windows-based conditioning ;-), but lately I am beginning to reconsider my stance. I am merely tinkering part-time with a weird installation of Debian "lenny" on a former server turned experimental Linux desktop machine, but I find that for my (admittedly very modest) needs, I might come to fully embrace Gnome...
xbindkeys
I use gentoo myself and at least for that there is a package called xbindkeys. You can bind commands to all sorts of xevents, including mouse buttons. I just checked and at least control is allowed as a modifier for mouse buttons also (and shift and alt should work similarly). You could see if that is available for kubuntu too, or if building from source would help. I'm using evdev for my mouse (logitech nano) and have all the buttons working :)!
e.g. The following in .xbindkeys will launch xterm when one of the mouse buttons is pressed and emacs when control and the mouse button is pressed.
"xterm"
b:8
"emacs"
control + b:8
Yes, you can do that...
... but I don't think we're talking about the same thing exactly.
It's quite possible to use xbindkeys to bind Shift, Alt or Ctrl + some other keystroke to a mouse button, but this is what I want to do:
When a button is pressed in the "Shift key" is pressed
When that button is released, the "Shift key" is released
xbindkeys doesn't let you do that. The best you can do is set it up so that when you press a mouse button it immediately sends "I'm pressing the shift key" and then immediately afterwards sends "now I'm releasing the shift key"
Either Shift, Ctrl and Alt support is broken or xbindkeys considers them "special keys" and refuses to work with them the same way. I dunno.
The idea must have seemed so
The idea must have seemed so absurd to me that I didn't even think of that possibility, although on a second reading your text is quite clear! There is also xdotool (http://www.semicomplete.com/projects/xdotool/) that should work, "xdotool key shift+a b" produces 'Ab'. I don't know if "xdotool key shift" would produce just shift alone. You could give that a try.
I'm curious now. What do you use this for? In combination with other mouse buttons to get ctrl + left mouse button?
I use it mostly in Inkscape...
In Inkscape the Shift, Ctrl and Alt keys are used in conjunction with other keys to bring up specific tool windows, etc., and it's generally convenient to have those keys bound to mouse buttons than it is to try to manage the Shift+, Ctrl+, Alt+ combinations with one hand.
For example, to bring up the layers management window in Inkscape you press Ctrl+Shift+L. Back when btnx was working I had shift and ctrl bound to the "forward" and "back" buttons on my MX Revolution mouse, so it was a relatively simple process of pressing both buttons with my thumb and pressing the "L" key on my keyboard. Bringing up the font window requires that you press Ctrl+Shift+T, and once again it's easier to just press two buttons on my mouse and the "T" key. Using the mouse wheel alone scrolls up and down the drawing area, Shift+mouse wheel allows you to scroll horizontally, and ctrl+mouse wheel allows you to zoom in and out.
I prefer using the mouse for this because some of the hand positions to trigger these things are a little awkward on a laptop keyboard, even a so called "full-size" laptop keyboard.
xdotool...
... how is this different from xvkbd? Same idea, cleaner syntax?
None of this is very hard to
None of this is very hard to accomplish, see
http://ubuntuforums.org/showpost.php?p=6356673&postcount=1158
xdotool / xvkbd
I suppose they are pretty similar. They both can simulate keyboard events and as commands can be bound to mouse buttons easily. Whether or not this makes the mouse button act like the keyboard event is a different matter, possibly worth trying out.
Thanks for the explanation. Seems like a great way to do things with one hand that usually need two.
One moment please
butnx method of actually doing this work is rather outdated, now it was compatible with the not quite so outdated method X.org handled extra mouse buttons. However for them to actually move forward in the area they have now needed to break that backwards compatibility. Unfortunately configuration apps haven't yet moved to the new method of using dbus and hal events (which I would add that both gnome and kde already currently use for keyboard). However it has forced them to start working on it. Maybe next release you'll find gnome and kde have finally built in the changes.
And yes, firefox is nasty as it always overrides every setting, you have to change the overrides in about:config.
well theres always the mystery that is hidpoint
its an interesting closed source tool for popular linux distros, it helps set up logitech hardware.
http://www.hidpoint.com/home.html
I had a different problem, but yeah
I'd had no real with Fawn, Gibbon, or Heron when it came to my sound card. Everything worked great, didn't have to edit any config file, didn't have to do squat. There were things I expected to have to tinker with - mostly my monitor and video until Heron, and a few other minor things. Then came Ibex. No sound. A really annoying hang on shutdown which required a hard shutdown. The culprit? I'm still working through all of it, but it's in the ALSA "upgrades". There's things I like about Ibex, but dammit, of all the things I ever expected to have to work on, this wasn't one of them.