SteerMouse

What follows here is a tale of intrigue, with a healthy dash of propeller beanie thrown in. While there is a happy ending, the timid may wish to wait for the next installment.

Quicken began to behave oddly; upon invoking it from the dock, the icon would do the customary couple of bounces, then nothing. Opening the Quicken data file met with mixed results; sometimes it’d open, sometimes it wouldn’t. Scary error messages, a weird file creation error in the backup process, that kind of thing.

Not the behavior I was looking for.

A bit of digging around led me to the console log, which contained entries like this:

kernel[0]: shared_region: 0x46bac64: lsf_map: unable to allocate mapping

Curious. Well, I’m a babe in the woods when it comes to OS X, but there’s BSD under them thar covers, and at least that I understand.

I happened upon a very informative arstechnica discussion of this problem, wherein a luminary for whom I am unqualified to fetch coffee had identified the source of the error. In short, one of the kernel’s non-expandable memory zones was full; the problem would prevent Rosetta applications such as Quicken from functioning.

Sure enough, from a terminal prompt:

$ zprint load_file_server
                          elem    cur    max    cur    max   cur alloc alloc
zone name                 size   size   size  #elts  #elts inuse  size count
----------------------------------------------------------------------------
load_file_server            36   491K   492K  13994  13994 13994    4K   113

Hmmm…yep, that’s full.

I did a restart to see just how fast this memory zone was filling; it had 293K in use immediately after a restart. Not good.

One individual in the discussion had indicated an issue with APE causing this problem. Now the thing was, I certainly hadn’t installed APE; heck, until a couple of minutes ago, I didn’t know it existed. However, when you see hoofprints, you should think horses, not zebras, so I fired up Activity Monitor to check.

And there it was, aped running. Curiouser and curiouser.

A little more digging uncovered the fact that the driver for my Logitech MX Revolution mouse silently installed APE, at a version (2.0.2) that was known to have issues with 10.4.9 Tiger.

I discovered some discussion about the possibility of installing the 2.0.3 version of APE after the Logitech Control Center installation, but by now, I was beginning to get a bit of a grump on. I am not at peace with software silently installing stuff I didn’t ask for or agree to; the time had come to purge.

I ran the Logitech uninstaller, which removed the Logitech Control Center preference panel; however, it didn’t get rid of APE. Fortunately, APE itself does provide an uninstaller, which did remove things cleanly. Frankly, the APE site and blog appear to be all about full disclosure, with a wealth of information provided. As such I’ve really got nothing against them; rather, I’m displeased with Logitech doing things behind my back.

Now, after a restart:

$ zprint load_file_server
                          elem    cur    max    cur    max   cur alloc alloc
zone name                 size   size   size  #elts  #elts inuse  size count
----------------------------------------------------------------------------
load_file_server            36    49K   492K   1412  13994  1412    4K   113

Much better.

So, now I had a system that wasn’t acting freaky, but my way-cool mouse was reduced to a shadow of its former self, most of its many buttons unresponsive. There had to be a solution for this problem.

Sure enough, there was. Steermouse is a third-party mouse driver, supporting a large array of mice, my MX included. The developer provided an unrestricted 30-day demo, which I installed. Steermouse immediately recognized the MX, and the dead buttons sprang to life once again.

One feature of the MX is the scroll wheel, which includes a clutch; the clutch can make the wheel operate in a free-spin or a click-to-click mode.

Personally, I find the free spin mode to be the best of any mouse I’ve ever used, but the click-to-click mode feels to me like stirring a vat full of rocks with a hockey stick.

Unfortunately, the click-to-click mode is the default. Ugh.

The Steermouse developer has an easy solution for this problem. I entered the following in a terminal window and relogged:

defaults write jp.plentycom.SteerMouse LOGITECH_MX_REVOLUTION_WHEEL -int -2

Presto, the mouse is now always in free spin mode. I love these guys. Other values provide different behavior for the scroll wheel; the Steermouse documentation contains complete details.

One final interesting feature of Steermouse is the ‘automatically move the cursor to the default button’ option, similar to that available in Windows’ pointer options control panel. Judging from the comments of reviewers, this feature is either the Single Best Thing Ever or the Manifest Work of the Devil; I tend to be in the former camp, having used the snap-to feature under Windows for years. It’s configurable and can be turned on or off as desired.

Steermouse was $20 USD to register. Not bad for giving me back a functioning Quicken and my mouse buttons.

All’s well that ends.