My beloved logitech mouse died. For reasons that have no bearing here, I ended up with the titular IntelliMouse Explorer 2.0 (though I'd have preferred another logi, the size and shape suit me better). If for some reason you too gave Microsoft money (well, don't! It's bad enough I did it!), here's how you use it with linux.
To take full advantage of your new and semi-ugly mouse, you'll need a kernel that supports evdev. Check whether you have it: modprobe evdev
If you get FATAL: Module evdev not found., it doesn't exist as a module, but maybe, it's compiled into the kernel proper. If your kernel remembers the configuration it was built with, try zcat /proc/config.gz|grep EVDEV. If it doesn't, but you have the kernel sources you built from, then I really don't have to tell you this, but something like grep EVDEV /usr/src/linux/.config should do the trick. If your kernel does not support evdev, you cannot proceed. Get a kernel that does, or give up.
You'll also need an Xserver that supports evdev. Reasonably new versions of X.org do, but the evdev-driver may be in a separate package that you'll need to have installed (x11-input-evdev on SuSE).
Now that that's out of the way, let's assume your mouse is connected via USB.
We'll use these data for /etc/X11/XF86Config: Section "InputDevice"
Option "Buttons" "7"
Option "ZAxisMapping" "6 7 5 4"
Option "Device" "/dev/input/event2"
Option "Dev Name" "Microsoft Microsoft Wireless Optical Mouse 1.0A"
Option "Dev Phys" "usb-0000:00:10.0-2/input0"
Option "Emulate3Buttons" "no"
This should give you a mouse with three buttons, and a scroll- and tilt-wheel once you restart X. The thumb-buttons (8,9) are still ignored in all apps though. I had special plans for them, so I seized them using imwheel: imwheel -k -b "89". (This can go into whichever of ~/.xsession and ~/.xinitrc you have so you don't have to type it everytime you log in.) I want the buttons to react to the application I'm using them in, though — time for some ~/.imwheelrc magic:
Control_L, Button5, Control_L|a|n
Control_L, Button4, Control_L|a|p
The left bit is what keys (shift, alternate, control, ...) have to be pressed in combination with the mouse-button(s) in the middle for us to emit the buttons and/or keys on the right, so the first line means, if Button5 is pressed while the left control key is held, emit control, a and n. (The screen program will switch to the next terminal upon seeing ^A^N.)
So our thumb-buttons (8,9) are (4,5) inside imwheel. Yeah, WTF.
The first section is for the screen program (which multiplexes terminals, giving your "several shell in one window"): when in screen and the left Control key is pressed, make the thumb-buttons switch to the previous/next shell, respectively.
The last section matches anything else, it's the fallback: with no modifiers (shift, control, alt, ...), the thumb-buttons (4,5) should act like button 2 (the middle button / scroll-wheel) and paste the selection. I always found it awkward to "click" using the mouse-wheel, and on my logitech, the thumb-button was a button "2" (same as clicking the middle-button/wheel), so I'll stick with what I'm used to.
If used with the left control key, Alt plus the left resp. right cursor-key should be emitted: this will make control + thumb-button go forward/backward in most web-browser's page-history.
Finally, if used with shift, we want to go the the top/bottom of the page. To do this, we emit button1 to focus the area under the mouse (just in case) as well as Home or End, respectively.
If you also wish to use the tilt-wheel from within imwheel, call it like so: imwheel -k -b 8967 To use tilting the wheel as an alternative way of changing terminals in screen, add lines for the left and right events:
Control_L, Button5, Control_L|a|n
Control_L, Button4, Control_L|a|p None, Left, Control_L|a|n
None, Right, Control_L|a|p
Since 8,9 in X are 4,5 inside of imwheel, they're 6,7 inside of xemacs. Sure, we could make a special case for xemacs in ~/.imwheelrc, but just for practice, here goes (~/.xemacs/init.el snippet): ;; mouse-wheel: scroll
(global-set-key 'button4 'scroll-down-command)
(global-set-key 'button5 'scroll-up-command)
;; tilt-wheel: go to previous/next buffer
;; ERC (emacs Internet Relay Chat) users may prefer binding
(global-set-key 'button6 'switch-to-previous-buffer)
(global-set-key 'button7 'switch-to-next-buffer)
Unfortunately, previous tab/next tab is not an option in those settings, so to do that, we'll have to once more modify ~/.imwheelrc:
None, Left, Control_L|Page_Up
None, Right, Control_L|Page_Down
New hardware toy
Recently aquired toy: Wireless IntellMouse Explorer
If you google for it in connection with Linux, you quickly discover this very helpful link
Unfortunately, this doesn’t work with Breezy, which does include an evdev driver, but only as a prot...
Weblog: CodeForFoodAndHonor Tracked: Nov 08, 11:37
Evoluent VerticalMouse 2, linux, xemacs, and x.org
It's the Chinese Year of the Mouse. First my beloved logitech mouse died. All I could get on short notice at the time was an IntelliMouse Explorer 2.0 (see there for installation) though I'd have preferred another logi, the size and shape of which suit me
Nun, da würde ich ja gerne mal mit der Mighty Mouse testen, wie weit ich da komme. Allerdings ist die physikalisch eingeschränkt, was chording betrifft (Apple mißt mit einem aufwändigen Sensor, welchen Teil der Maus man berührt, um nur einen primitiven Mikroschalter verbauen zu müssen. Wenn der Sensor mehrere Berührungspunkte ermißt, nimmt er an, dass man Button1 will. Dafür haben sie einen Lautsprecher eingebaut, der 'klick' macht, wenn man klickt, und leise '*triiiieeeeep*', wenn man mit der Nippelkugel scrollt).
Nach den Beschreibungen klingt die Microsoft-Maus der Apple-Maus deutlich überlegen.
Das tilt-wheel ist sinnvoller als gedacht. Man kann es links oder rechts "klicken", dabei verwackelt man aufgrund des Widerstands die Maus. Das muss man aber offenbar gar nicht; das Rad einfach anzukippen (ohne den Klick-/Feedback-Punkt zu überwinden) sendet ebenfalls den tilt-event. Damit ist das Ganze durchaus benutzbar und lässt sich gut zum Weiterschalten von tabs (Reitern) in screen, emacs, oder browsern verwenden. Fein!
Das 'weiterschalten' wäre mit der MM bestimmt nicht so einfach möglich, weil die Nippelkugel eben genau keinen haptisch diskreten Schaltpunkt hat. Dafür entfällt das Verwackeln, weil man ja 'über der Maus' und nicht 'in sie hinein' scrollt.
Als ich gesehen habe, wie ich nun in Opera die Tabs per Tilt hin und herschalten kann habe ich fast gegluckst.
Der Punkt, der Nerven kostet ist das langsame Scrollen. Irgendwie wird das in Windows glaube ich beschleunigt, so daß man mit einer schnellen Runde bis ganz hinunter auf der Seite kommt. Langsam gehts dann in kürzeren Sprüngen.
Hast du dazu auch was auf Lager?
Das hängt ab. Wenn Opera das Rad direkt erkennt, mag man das auch dort einstellen, dazu weiß ich aber zu wenig über Opera. Alternativ kann man das wohl wieder über iwheel in Tastendrücke (PageUp, PageDown drängen sich dann wohl auf) übersetzen lassen. Das geht ja zum Glück abhängig von der Anwendung, wie für Galeon gezeigt.
Opera bekommt immer nur einen Zeilenvorschub befohlen.
Ich könnte sicher Page Down/Up mappen, aber das wäre dann zuviel. In Windows hat dieser Intellipoint Treiber sowas wie "Accelerated Scrolling", d.h. es gibt eine direkte Verbindung zwischen der Winkelgeschwindigkeit des Rades und der Scrollgeschwindigkeit.
An diesem Notebook funktioniert Scrollen am Besten mit dem synaptics X.org-Treiber. Und mit dem geht es ja auch stufenlos und vor allem "schnell".
Ich glaube, das dieses Mappen auf Keyboard-Tasten nciht bringt. Und mit dem Browser hat es auch nur bedingt was zu tun, weil dieses rastenweise überall nervt. Mein Rad hat keine Rasten.
Und jetzt bin ich im Turing Test gescheitert.
I kept fiddling for a long while and i got it working with xorg 7.0 . The details are gentoo specific but make sure you get udev working, cause that's where i failed. If cat /dev/input/event? fails that is bad :). The rest is really painless with xorg 7. Just look for yourself:
I didn't add these lines he instructed his readers to do, because I thought that it had to do with making the forward and back buttons 4 and 5 NOT work as forward and back, but as button 2, which I didn't want:
Plus I went into firefox and about:config and changed the mousewheel.horizscroll setting, only the
mousewheel.horizscroll.withcontrolkey.sysnumlines to true
Now, after doing those things, I can scroll but when I click the forward and back buttons (4 and 5 thumb buttons) it scolls up or down by a few lines with each depress, instead of going forward and back, and using the tilt function of the mousewheel makes Firefox go back and forward webpages I have browsed.
Can anyone suggest anything, I think I am getting closer here, but I am a bit confused, he talks about how:
So our thumb-buttons (8,9) are (4,5) inside imwheel
Since 8,9 in X are 4,5 inside of imwheel, they're 6,7 inside of xemacs. Sure, we could make a special case for xemacs in ~/.imwheelrc, but just for practice, here goes (~/.xemacs/init.el snippet):
So I am under the impression that the different programs see the mouse buttons as being different numbers, and what I think is worse is that with SuSE 10.1 things got mixed up more, because I have to have my mouse.sh files in /home/bucky/.kde/Autostart reading as this:
xmodmap -e "pointer = 1 2 3 8 9 4 5 6 7 10 11"
I am wondering if I should eliminate mouse.sh by temporarily renaming it and moving it to a non Autostart directory, and if I should add the lines ( in imwheelrc):
None, Button5, Button2 [NOT use this line]
None, Button4, Button2 [Not use this line]
Control_L, Button5, Alt_L|Left
Control_L, Button4, Alt_L|Right
Shift_L, Button5, Button1|Home
Shift_L, Button4, Button1|End
So I am going to try those things and then see what happens, if anyone has any ideas or knows of how I can figure out which mouse button is which for these programs, HELP, please!
What is happening now is that my thumb buttons do nothing, the scroll wheel scrolls normally, but the tilt of the scroll wheel moves me forward or backward to webpages I have browsed, so evidently, the tilt wheel is doing what the thumb buttons are supposed to do. I have been trying different things to no avail. Can someone talk me through this somehow, or give me ideas.
I ran xev, and my mouse, the first button is the left mouse button normal, the middle (tilt wheel) button is normal as button 2, and the right button is normal as button 3. xev shows the scroll part of the scroll wheel to be 4 and 5 for up and down, and the tilt part of the wheel as 6 and 7. xev shows the thumb buttons to be 8 and 9.
I tried putting 9 in the place of 5 and 8 in the place of 4 in the above and that changed nothing, which surprises the heck out of me. Can someone help me here, please?
signmeuptoo: on line 18 of your post, I think the numbers 8967 need to be separated by a space. that is:
imwheel -k -b "8 9 6 7"
easy to try and i can't find my source, although i think it was at thte xorg website. iirc, the numbers had to be together for version 6.8, and higher they had to be separated by a space. something like that. good luck.
Copy the exact value of the name line (N: Name="xyz") to xorg.conf ( Option "Name" "xyz"), no need to muck around with Device, Dev Name, Dev Phys fu. And if you needed it, there's a symlink dir in /dev/input/by-id now.
See comments of the article on the Evoluent mouse for more details.
"much less painful now"? SuSE 10.3 was a snap. SuSE 11.0 is EXTREME pain. It is completely nutty to spend two days at this and still be unable to have a working scroll. "imwheel" does not exist, so scrap all those instructions. Why are there four buttons for the Z axis? I'd think up and down were enough.