# MS Wireless Intellimouse Explorer -- extra features!

## alv

It is a long weekend, and I finally had a chance to work on something that I have started last year -- to bring MS Wireless Intellimouse Explorer (w/tiltwheel), and all its glory to the linux.

By default the mouse is simply a 5-button mouse. And as far as the default vanilla kernel is concerned, there is nothing else there. I have update the kernel's Human Interface Device to include the ability to send and receive certain packets (which are in the HID standard, but the kernel developers seemed to ignore it), as well as to add the vendor specific codes to the mouse (all of them reverse engineered -- so I could have made a mistake).

The result is the following features that are now present on the mouse:

1. Full use of tiltwheel, if you use the evdev interface for X.org. The configuration is described here: https://forums.gentoo.org/viewtopic.php?t=198534. Note that the evdev patch is now a part of the normal ebuild, and there is no need to specifically add it. Please use the patch described here.

2. An ability to read the battery meter as well as the signal strength meter. What the values mean is best guesses. For example what I am labeling as fair, actually is most frequently reported when the mouse goes on powersave.

3. An ability to set the high sensitivity mode on the wheel, meaning that to send a ZAxis event takes less that a third of an arc than it used to. This is perhaps the most important extra feature, as I found the scroll wheel to be too slow. Do note, however, that there is a bug in X.org, making it unable to handle wheel events that generate high values (i.e. when you scroll the wheel fast, it generates a relative change of 10, making X send spurious button presses). I have placed the bug on gentoo's bugzilla https://bugs.gentoo.org/show_bug.cgi?id=62920, but I am not sure how far that went. I suppose that I could write a workaround that will improve handling of evdev events in that respect. Stay tuned.

The patch (standard kernel diff against 2.6.10) and the associated tool (just run make to compile, and then ./msmousectl --help) is on my site: http://cs-www.cs.yale.edu/homes/alv/msmouse.xhtml. Please ignore the crap that is my site design. I do not claim to be a good designer. Also I am not a kernel expert, so please do not place this patch on a production system. Even if there is a bug I think it would be limited to causing your input devices to stop working, and at worst a system hang.....but you never know.

So to configure the mouse, do the following:

1. Patch the kernel with the patch on my site. Make sure to include evdev as a builtin or a module. I recommend module

2. Configure X.org to use the event device:

I use tis one. You may need to play around with ZAxisMapping.

```

Section "InputDevice"

    Identifier   "Mouse1"

    Driver "mouse"

    Option      "Protocol"      "evdev"

    Option      "Device"        "/dev/input/event1"

    Option      "Buttons"       "9"

    Option      "ZAxisMapping"  "6 7 8 9"

    Option      "Dev Phys"      "usb-*/input0"

EndSection

```

3. Make sure the mouse works. You may need to play with xmodmap to assign events to the right functions. I use 

```
xmodmap -e "pointer = 1 2 3 8 9 4 5 7 6"
```

which may or may not work for you. xev is your friend. It will tell which events are being sent.

4. Compile msmousectl by running make. Run msmousectl --help to see options. msmousectl status should give you the current mode of operation.

Anyway. I would love to hear comments and request and flames about this. Especially of the libusb versus kernel patching kind, as I am not sure that i did the right thing by introducing a massive vendor-specific change to the kernel. But then again -- vendor specific stuff is in the spec for the HID, and as long as they do not conflict it is the job of the HID drivers to handle it. Anyway, comments please!

----------

## factodude

Thank you.  I'm about to try this now, and I've been looking for something like this for awhile now.  Is there any way you can add this to the Documentation Tricks and Howto area?  Maybe with "HOWTO" in the title?   

Thank you again.

----------

## alv

I am weary about adding this to the documentation, given the fact that it involves an untested, poorly written kernel patch.

Once this will get some review....and there will be an adequate interest, then perhaps a HOWTO will be in order!

For now, it will be just an interesting thread. Bookmark my site, and save my email, if you wish to reach me for the updates while this thread descends into obscurity.

----------

## nford

Hi

I am using my intellimouse explorere together with a PS/2 converter.  Will your kernel module work ok for this too?

----------

## alv

 *nford wrote:*   

> Hi
> 
> I am using my intellimouse explorere together with a PS/2 converter.  Will your kernel module work ok for this too?

 

No, it will not. The kernel patch modifies the usbhid driver, which is a protocol that runs on top of usb. (Although I have heard that a similar protocol runs on top of bluetooth, and it might use this driver too). However this whole converter business is quite interesting. From what I understand these USB HID devices actually support something known as the HIDBP(?) protocol, and actually start out in that mode. This mode is incredibly simple, and is used for things like BIOS usb keyboard entry. The devices switch out of that mode the moment the HID driver initializes them. From my understanding, by using the converter, you keep the devices in this simplified mode, which is backwards compatible to some protocol that runs on PS/2 devices. Please understand that this is only my guess....and that these devices may have a converter detector and can actually use a different protocol when connected to the PS/2 port. I have no clue which of these cases is actually true....but in either case the device is running a different protocol...which may or may not have the functionality that the patch is trying to add.

Suppose that it does have the functionality. If you wish to squeeze the functionality out of the ps/2 port you will either need to play with the protocols in the Xserver that parse the ps/2 output, or the gpm driver which converts the /dev/psaux output into /dev/mouse output. I do not know the protocol that runs on the ps/2 port but I suspect that it will be an extension of the IMPS/2 protocol (assuming the tiltwheel and battery indicator work through the ps/2 port at all).

----------

## nford

It sounds too complicated - if your method works, I think I'll just connect my mouse to the USB port.

----------

## alv

 *nford wrote:*   

> It sounds too complicated - if your method works, I think I'll just connect my mouse to the USB port.

 

Just be careful. The biggest issue with this whole thing is that you have to configure X to use the event device. The evdev patch for X.org can be capricious...so whatever you do, backup your xorg.conf.

Make sure your evdev config is tailored to your system, and make sure that appropriate permissions are set.

(Note -- if your permissions on event devices are not correct, X.org will just show a blank screen, and will block (freeze).)

Try switching to the evdev device before applying my patch. That will help iron out some bugs before ones caused by me start appearing.  :Wink: 

----------

## meowsqueak

How about adding a section or a new page to www.gentoo-wiki.com? If you do, you could cross-link with this article:

http://gentoo-wiki.com/HOWTO_Mouse_Nav_Buttons

----------

## TheCurse

Hmm, I did not understand... How can I get my Microsoft IntelliMouse Explorer 2.0 Tiltwheel working? I use evdev and the Mouse is connected via PS/2. This must be possible because it works under windows...

cu

TheCurse

----------

## alv

 *TheCurse wrote:*   

> Hmm, I did not understand... How can I get my Microsoft IntelliMouse Explorer 2.0 Tiltwheel working? I use evdev and the Mouse is connected via PS/2. This must be possible because it works under windows...
> 
> cu
> 
> TheCurse

 

First of all, I know very little about the PS/2 port and its interaction, as the last time I used PS/2 actively has been with 2.4 kernels. Thus I know very little about the PS/2 ports and the protcols that run on it. All I can say is that this patch is not going to work for it, as this is a fix/enhancement for a generic USB Human interface device, and the only thing that is specific to this mouse are the id's of the controls.

However, this does not mean that it is impossible to make it work through the PS/2. I suppose there is a psaux driver that is present in evdev, such that it pumps ps/2 events into the input system, and I can probably find these drivers. However there are 2 problems:

One is that for USB the USBHID is well defined and is at least bearly functional in linux. (I will claim it is full of bugs, and it is a complete wonder it works. On the other hand there are plenty of issues in the definition of the protocol as well). Thus I can easily produce enough fixes for USB without much reverse engineering. This is not so for PS/2. I suppose I will have to figure out how IMPS/2 protocol works, and figure out specifically what kinds of commands are sent over it. 

Two: Given that I have no PS/2 version of that mouse (nor converters), this is practically an impossible task for me.

Thus I will not be able to provide any help on this front.

----------

