Skip navigation

Warning: this contains a travelogue of my interesting, but perhaps tedious explorations while attempting to achieve full functionality with my mouse, and does not come to a solid conclusion.  If you have some useful information, feel free to drop a comment.

I recently began the quest to achieve full functionality with my mouse (as has been mentioned, an Intellimouse Explorer 4.0A).

This is my current config:

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "Emulate3Buttons" "true"
EndSection

So far, I’ve found some very useful tidbits.  xev does not recognize horizontal movements, but it has only been hooked up to /dev/input/mice.  If I simply use /dev/input/event3 instead (which I found by running ls -lh /dev/input/by-id/), the mouse generates what seem to be almost completely random side effects.

By running cat on the proper event file, you should be able to see that something comes through when you use the keys that were invisible to xev.

Now comes the trouble of actually configuring evdev to handle events.  The key seems to be deciphering the contents of /proc/bus/input/devices.  I was unable to find a guide to that, so I took a different route:

  1. cat the all possible mouse events to a file for analysis (if desired, you can attempt to perform one type of mouse action to better analyze the output)
  2. # cat /dev/input/event3 > mouseEvents.txt

  3. hexdump the file
  4. # hexdump mouseEvents.txt > mouseHex.txt

  5. open mouseHex.txt in a reasonably powerful editor
  6. remove line numbers and remove newlines (I recommend using a macro)
  7. adjust the size of the window until a pattern becomes apparent
  8. time cons tant cons vari time cons tant vari able vari able

    309c 47e5 0000 0000 cb45 000e 0000 0000 0000 0000 0000 0000
    309c 47e5 0000 0000 09af 000f 0000 0000 0002 0001 ffff ffff
    309c 47e5 0000 0000 09c0 000f 0000 0000 0000 0000 0000 0000
    309d 47e5 0000 0000 05eb 0000 0000 0000 0002 0001 ffff ffff
    309d 47e5 0000 0000 05fa 0000 0000 0000 0000 0000 0000 0000
    309d 47e5 0000 0000 82e3 0000 0000 0000 0002 0001 ffff ffff

    prt1 prt2 prt3 prt4 prt5 prt6 prt7 prt8 prt9 pt10 pt11 pt12

    I should note that this section is by no means representative of all possible variations.

In my case, I noticed that when dealing with side-scrolling, I had this output – notice the change in pt10:
2e7a 47e5 0000 0000 6f16 0009 0000 0000 0002 0006 ffff ffff
2e7a 47e5 0000 0000 6f1e 0009 0000 0000 0000 0000 0000 0000

as opposed to this output for vertical scrolling:

401f 47e5 0000 0000 c576 000b 0000 0000 0002 0008 0001 0000
401f 47e5 0000 0000 c580 000b 0000 0000 0000 0000 0000 0000

From what I can tell from the values I received and the source file, this field (pt10)  corresponds to either the axes type, or the keypress type (depending on the context).

After some testing, I am pretty sure the fields correspond to:

  • prt1, prt2, prt5, prt6 = time
  • prt3, prt4, prt7, prt8 = blanks
  • prt9 = 1 if keypress, 2 if mouse movement, (0 if nothing?)
  • pt10 = keypress type, or axes type
  • pt11 = for axes, distance moved over time
  • pt11 = for keypress, 1 for down, 0 for up
  • pt12 = direction moved (- or+)

One thing I’m not sure of is why blank values frequently follow normal lines.  Maybe it’s to help with syncing of events (i.e. letting the system know when multiple axes are being manipulated simultaneously).  It would be easier to handle that from a developer’s point of view, than actually worrying about clock values.

So, when attempting horizontal scrolling, my mouse is sending the value 6 in pt11, or REL_HWHEEL, which seems to be correct.  What now?  How does this correspond to my evdev settings in xorg.conf?  I’m at an impasse.

More info: After all that, I was running an older version of evdev, so that is a partial explanation as to why I couldn’t get it to work.  Serves me right for not checking the logs.  Even now, I haven’t been able to get it working.

I’ll stick with my old configuration until I have some more time.  How frequently would I use horizontal scrolling, anyway?  Even when I had it working, I rarely used it (it is pretty slow (and looking at the output of event3, it’s built that way)).  On the other hand, when I had it working, I didn’t know about pasting with the middle button, so I didn’t constantly have my finger over it, either.

Just a little note for resuming from where I left off:  with the following lines, the mouse doesn’t function, but from reading the log, everything seems to be properly detected, including horizontal scrolling.  cat /dev/input/event3 doesn’t echo anything, which is probably good.

Section "InputDevice"
Identifier     "Configured Mouse"
Driver         "evdev"
Option         "Device"     "/dev/input/event3"
EndSection

If I recall, by adding some of the bitmasks seen in sample configs, I can get some of the mouse features to work, but no more than with my current setup, and when I move to evdev, I will have to configure both mice individually.

Until another day.

2 Trackbacks/Pingbacks

  1. […] If you want to decipher the output, look at my overview in the previous post. […]

  2. […] – horizontal and vertical scrolling, backwards and forwards buttons. This means that my previous posts on scrolling are now obsolete – but that is […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: