Enabling Thumb Buttons on Logitech MX-1000 Mouse?

mac57 · 2007-08-19 19:39:20

I have just installed Arch 2007.08, and am looking for the xorg.conf (or other file) settings needed to enable the thumb buttons on this multi button mouse. The same settings that worked on Arch 0.7.1 don't seem to work here on Arch 2007.08. Left and Right Click, and scroll wheel all work, but not the thumb buttons. Normally, it is a matter of setting the Buttons and ZAxisMapping options in xorg.conf and then doing a "xmodmap -e pointer = 1 2 3 6 7 4 5" in .xinitrc. This is not working in Arch 2007.08 however.

Is there a new recommended way? Does anyone have the thumb buttons working on their Logitech MX1000 mouse and would be willing to post their settings? Thanks!

Last edited by mac57 (2007-08-19 21:29:53)

Abadaar · 2007-08-19 22:31:28

I have an MX510 and this is my mouse section:

Section "InputDevice"
    Identifier     "Logitech MX510"
    Driver         "mouse"
    Option         "Buttons" "7"
    Option         "CorePointer"
    Option         "Device" "/dev/input/mice"
    Option         "Protocol" "ExplorerPS/2"
    Option         "ZAxisMapping" "4 5"
    Option         "ButtonMapping" "1 2 3 6 7"
    Option         "Resolution" "800"
EndSection

Gilneas · 2007-08-19 22:47:00

You'll have to go up to twelve for the MX1000 I believe. After that try it out with xev.

Also check out http://wiki.archlinux.org/index.php/Get … ns_Working
If you use evdev, make sure your InputDevice section doesn't contain unnecessary info, it messed up my setup.
Mine just has an identifier, driver (evdev), name, and corepointer.

mac57 · 2007-08-20 00:36:34

Thanks all - I will try these ideas out and get back to you. Cheers!

mac57 · 2007-08-20 04:14:35

OK, I tried out the evdev approach and it worked to a limited extent, although I still do not have the use of the Forward and Back buttons on the mouse.

After following the evdev approach, the Forward and Back functions are now available, but are somehow mapped onto the left and right horizontal scroll functions of the scroll wheel.

After some Googling, I found someone who suggested using xvkbd and xbindkeys to remap these functions onto the actual Forward and Back buttons on the mouse itself, but when I did what they suggested, it made no difference.

Any suggestions anyone? Is anyone out there using an MX1000 mouse from Logitech? Thanks!

MrWeatherbee · 2007-08-20 05:24:50

Using evdev was the correct choice as was going with xbindkeys and xvkbd.

I don't have a Logitech, I have a Wireless IntelliMouse Explorer. But here is my setup and you can compare to your mouse and make changes as necessary.

Buttons without modification are as follows (as shown by using xev):

1 Left-click Button - Normal Behavior
2 Middle-click Wheel / Button - Normal Behavior
3 Right-click Button - Normal Behavior
4 Scroll-up Wheel - Normal Behavior
5 Scroll-down Wheel - Normal Behavior
6 Scroll-left Tilt-Wheel - Abnormal Behavior - Behaves as Back Button
7 Scroll-right Tilt-Wheel - Abnormal Behavior - Behaves as Forward Button
8 Thumb-bottom Button - Abnormal Behavior - Behaves as Scroll-Left Tilt-Wheel
9 Thumb-top Button - Abnormal Behavior - Behaves as Scroll-Right Tilt-Wheel

Adding this to the top of ~/.xinitrc:

 
xmodmap -e "$(cat ~/.Xmodmap)"

and creating ~/.Xmodmap with this text:

pointer = 1 2 3 4 5 8 9 6 7

changes mapping to the following (as shown by using xev)

1 Left-click Button - Normal Behavior
2 Middle-click Wheel / Button - Normal Behavior
3 Right-click Button - Normal Behavior
4 Scroll-up Wheel - Normal Behavior
5 Scroll-down Wheel - Normal Behavior
8 Scroll-left Tilt-wheel - Normal Behavior
9 Scroll-right Tilt-wheel - Normal Behavior
6 Thumb-bottom Button - Normal Behavior (Now Back Button Behavior)
7 Thumb-top Button - Normal Behavior (Now Forward Button Behavior)

Then to get the tilt-wheel and side buttons to behave correctly in Gnome apps such as Nautilus, create ~/.xbindkeysrc and add these lines:

# Mouse Buttons
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Left]""
m:0x0 + b:6 
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Right]""
m:0x0 + b:7
"/usr/bin/xvkbd -xsendevent -text "\[Left]""
m:0x0 + b:8 
"/usr/bin/xvkbd -xsendevent -text "\[Right]""
m:0x0 + b:9

For xbindkeys to work, be sure it is started when your session is started. For example, if you use Gnome, you can add it to Start Menu > System > Preferences > Sessions

And we can't forget /etc/X11/xorg.conf:

Add to Section "ServerLayout":

    InputDevice    "Evdev Mouse" "CorePointer"

and add entire section:

Section "InputDevice"
  Identifier      "Evdev Mouse"
  Driver          "evdev"
  Option          "Name" "ImExPS/2 Generic Explorer Mouse"
  Option          "CorePointer"
EndSection

Hope this helps.

Note:

Which files you use (e.g., ~/.xinitrc, ~/.Xmodmap, etc) may vary depending on your set-up as well. But hopefully you get the idea of the interaction between processes and set things up to your liking or requirements.

Last edited by MrWeatherbee (2007-08-20 08:45:22)

mac57 · 2007-08-20 14:39:34

MrWeatherbee, thank you, thank you, thank you. That did the trick. I did a few variations on the theme. For example, I just put the xmodmap command directly into my ~/.xinitrc, but other than that, pretty much just what you suggested, and it worked just fine. I have written the whole thing out and will post a mini HOWTO shortly.

Meantime, how did you arrive at this magic result? I have never understood the mapping of the button numbers for these mice. How did you come up with the magic sequence of numbers to put in the "pointer" command? I would love to figure that out. This is along the lines of the old adage "give a man a fish and you feed him for a day, teach him how to fish and you feed him for a lifetime". It would be great to *understand* the magic vs. just using it. Thanks!

MrWeatherbee · 2007-08-20 20:08:09

mac57 wrote:

MrWeatherbee, thank you, thank you, thank you.
...
Meantime, how did you arrive at this magic result? I have never understood the mapping of the button numbers for these mice. How did you come up with the magic sequence of numbers to put in the "pointer" command?

First of all, you're welcome.

Second of all, it's not magic (as I know you are aware).

Third of all, I'm no expert, but I'll try to explain the way I conceptualize the process. Here we go:

- Using evdev is essential for getting mouse buttons beyond 7 to work.

For example, when I was just using (in xorg.conf):

Driver          "mouse"

my tilt-wheel was not recognized (as verified by xev). If a "button" on a mice is not recognized, no amount of fitzing around with Xmodmap or utilities like xbindkeys is going to do any good. Installing evdev and modifying xorg.conf to read:

Driver          "evdev"

did the trick. All "buttons" are now recognized.

- use 'xev' to determine the original mapping of buttons.

While 'xev' outputs "button number" information in response to button / wheel input, you should also visualize these numbers as positions on the mouse:

Position 1 = xev Button 1
Position 2 = xev Button 2
Position 3 = xev Button 3
Position 4 = xev Button 4
Position 5 = xev Button 5
Position 6 = xev Button 6
Position 7 = xev Button 7
Position 8 = xev Button 8
Position 9 = xev Button 9

A position represents a physical location or button on the mouse and a 'xev' Button (as displayed in 'xev' output) represents a click-event.

While the distinction between "position" number and xev "button click-event" number seems odd at this point since they are currently the same, it will become clearer when we want to change "button" behavior. But for now be aware that when using "pointer" (i.e., in the Xmodmap file of your choice), an implied position exits (but is not a required part of the code):

# 1 2 3 4 5 6 7 8 9 = implied static physical button position
pointer 1 2 3 4 5 6 7 8 9 # equals 'xev' click-event number

Finally, note that at this point, 'xev' has only defined a "click-event" number relative to the physical mouse button / wheel, it does not define or reveal what that "click-event" does when used within a particular application.

- now that we have button positions and click-event numbers via xev (and we are lucky enough to find all buttons / wheel(s) recognized), we need to find out exactly what these click-events do in the real world. To do this, open up an application (Firefox or the web-browser of choice is usually the prime candidate) and experiment with the mouse. For our test mouse, say we find that:

1 / 1 = Left-click Button  /  Normal or Expected or Desired Behavior
2 / 2 = Middle-click Wheel Button  /  Normal or Expected or Desired Behavior
3 / 3 = Right-click Button   /   Normal or Expected or Desired Behavior
4 / 4 = Scroll-up Wheel  /  Normal or Expected or Desired Behavior
5 / 5 = Scroll-down Wheel  /  Normal or Expected or Desired Behavior
6 / 6 = Scroll-left Tilt-Wheel  /  Abnormal or Unexpected or Undesired Behavior  (Behaves as Back Button)
7 / 7 = Scroll-right Tilt-Wheel  /  Abnormal or Unexpected or Undesired Behavior (Behaves as Forward Button)
8 / 8 = Thumb-bottom Button  /  Abnormal or Unexpected or Undesired Behavior (Does nothing)
9 / 9 = Thumb-top Button  /  Abnormal or Unexpected or Undesired Behavior (Does nothing)

Note:
1 / 1 represents Position 1 / Xev Click-Event Number 1
2 / 2 represents Position 2 / Xev Click-Event Number 2
etc.

Now we see that we need to work on 6 / 6, 7 / 7, 8 / 8 and 9/ 9 because they do not do what we Expect or Desire. Since we would like to have the thumb buttons be our back and forward controls, we look for the desired behavior as determined by our Firefox / browser experimentation. Noting that Xev Click-Event 6 yields "back" behavior and Xev Click-Event 7 yields "forward" behavior at Positions 6 and 7, respectively, and we desire those behaviors at physical Position 8 (Thumb-Bottom Button) and physical Position 9 (Thumb-Top Button), respectively, we remap our button behaviors to the desired physical positions using pointer:

# 1 2 3 4 5 6 7 8 9 = implied static physical button position
pointer 1 2 3 4 5 8 9 6 7 # equals 'xev' click-event number

After restarting X, we see that 'xev' confirms the remapping of the click-events to the desired positions, and testing in our application confirms that the desired position / button yields the desired click-event behavior.

- But what about the tilt-wheel? The above "pointer" remapping simply placed click-events 8 & 9 at the desired positions (6 & 7, respectively), but as demonstrated in our Firefox tests, click-events 8 & 9 didn't really do anything. So now is where 'xbindkeys' and 'xvkbd' come in.

Through additional experimentation, we determine that scroll-left behavior and scroll-right behavior are achieved via keyboard keys left-arrow and right-arrow, but again, our mouse, by default, just can't perform these behaviors. To get our mouse buttons to perform the same behaviors we can achieve with our keyboard keys, we create a ~/.xbindkeysrc with this code:

"/usr/bin/xvkbd -xsendevent -text "\[Left]""
m:0x0 + b:8 
"/usr/bin/xvkbd -xsendevent -text "\[Right]""
m:0x0 + b:9

After restarting X, we test again to find our desired behaviors are achieved, i.e., left-tilting the mouse tilt-wheel ('xev' click-event 8) invokes a left-arrow keystroke thus scrolling left, and right-tilting the mouse tilt-wheel ('xev' click-event 9) invokes a right-arrow keystroke thus scrolling right.

- But ... later we find that other applications do not exhibit the desired behavior that we achieved in Firefox. For example, we know a bottom-thumb button-click should send us back in our file manager browsing history (e.g., Nautilus file manager), but the button does not do this (same is true for the top-thumb button-click). So, it looks like we are not through with 'xbindkeys'.

After additional experimentation or research, we determine that Alt+Left-Arrow causes back behavior and that Alt+Right-Arrow causes forward behavior. With this info, we can add to our ~/.xbinkeysrc:

"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Left]""
m:0x0 + b:6 
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Right]""
m:0x0 + b:7

Voilà ... mouse buttons / wheels and behaviors are all working as desired in Firefox and other applications that support mouse input.

Note:
Using:

xbindkeys -k

can help you determine the specifics about a particular mouse button or keystroke, i.e., it is similar to xev, but gives information on what code to paste into ~/.xbindkeysrc. If that does not provide enough information to get things set properly, please see the online documentation for xbindkeys and / or xvkbd.

Final note:
I apologize in advance if this post makes matters more difficult to understand. I wrote this while heavily distracted and may come to regret the post when I read it more thoroughly later in the day.

Last edited by MrWeatherbee (2007-08-20 20:10:14)

mac57 · 2007-08-21 15:00:32

MrWeatherbee, please no need to apologize - this the best treatment of this subject matter I have ever seen - once again I owe you great thanks. I will be saving this post off.

One last question: everything you do relies heavily on xev. I have tried this once or twice myself, but it generates such a flood of information that I have never found it useful. As a practical matter, there is no way I can press a button on my mouse without also moving the mouse a little bit. This generates so many mouse position movement events that I have never found a reasonable way to separate out the button push events to see what they are. Hence, I cannot even use xev to see if a given button is even recognized! Way too many motion events to even SEE if there was a button press event. How do you resolve this?

I hope that this isn't a stupid question with an obvious answer like redirecting stdout and using grep, but I will ask nonetheless! Thanks again!

Last edited by mac57 (2007-08-21 15:03:49)

shining · 2007-08-21 16:45:36

mac57 wrote:

MrWeatherbee, please no need to apologize - this the best treatment of this subject matter I have ever seen - once again I owe you great thanks. I will be saving this post off.
One last question: everything you do relies heavily on xev. I have tried this once or twice myself, but it generates such a flood of information that I have never found it useful. As a practical matter, there is no way I can press a button on my mouse without also moving the mouse a little bit. This generates so many mouse position movement events that I have never found a reasonable way to separate out the button push events to see what they are. Hence, I cannot even use xev to see if a given button is even recognized! Way too many motion events to even SEE if there was a button press event. How do you resolve this?
I hope that this isn't a stupid question with an obvious answer like redirecting stdout and using grep, but I will ask nonetheless! Thanks again!

heh, you're giving the answer in the question
what about something like :

xev |grep -A3 Button

MrWeatherbee · 2007-08-21 18:01:01

mac57 wrote:

MrWeatherbee, please no need to apologize - this the best treatment of this subject matter I have ever seen - once again I owe you great thanks. I will be saving this post off.

Wow. Thank you for the praise.

mac57 wrote:

One last question: everything you do relies heavily on xev. I have tried this once or twice myself, but it generates such a flood of information that I have never found it useful. As a practical matter, there is no way I can press a button on my mouse without also moving the mouse a little bit. ... How do you resolve this?

- less caffeine
- super glue
- an assistant
- use both hands

I understand your frustration. Holding the mouse steady to limit output can be problematic. However, the only time this has been an issue for me is when testing the tilt-wheel as the side-to-side motion seems to be more difficult to control ... for me anyway.

By the way, a single mouse click generates this (I think I got it all) in amongst everything else that is getting recorded:

ButtonPress event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x3800002, time 114880969, (43,31), root:(1000,74),
    state 0x10, button 2, same_screen YES

EnterNotify event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x0, time 114880970, (43,31), root:(1000,74),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 528

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x3800002, time 114881014, (43,31), root:(1000,74),
    state 0x210, button 2, same_screen YES

LeaveNotify event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x0, time 114881014, (43,31), root:(1000,74),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

mac57 wrote:

I hope that this isn't a stupid question with an obvious answer like redirecting stdout and using grep, but I will ask nonetheless! Thanks again!

Drum roll please ..... ..... ..... .....

Yes, it's good old 'grep' to the rescue. All you are looking for in this particular usage of 'xev' is which button is mapped. As you can see from the output I posted above, the ButtonPress event and the ButtonRelease event have the info we need (the button number), so this command will limit output quite nicely for the purpose at hand:

$ xev | grep button

Output will look similar to this when I click my right mouse button:

state 0x410, button 3, same_screen YES

However, to get a more accurate picture of the ButtonPress and ButtonRelease events, you can add context to 'grep' output. Here I will use the "B" option which will provide specified lines of context before our 'grep'd line:

$ xev | grep -B 2 button

Output looks like this when I click my right mouse button:

--
ButtonPress event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x3800002, time 120538036, (26,59), root:(983,102),
    state 0x10, button 3, same_screen YES
--
ButtonRelease event, serial 31, synthetic NO, window 0x3800001,
    root 0x4d, subw 0x3800002, time 120538191, (26,59), root:(983,102),
    state 0x410, button 3, same_screen YES

Just for accuracy's sake, repeat button tests multiple times to make sure you are satisfied with the result (i.e., sometimes you may think you tilted the wheel when you rolled the wheel, so do it several times each to make sure you are capturing button info for the event you intended).

Also note that once you introduce 'xbindkeys' and re-map certain buttons to keystrokes, 'xev' sees those particular button clicks as keystrokes (and why not?), so for instance, if you wanted to see those buttons' 'xev' output, you could do this:

$ xev | grep -C 2 keysym

Note: the -C 2 option will provide 2 lines of context above and 2 lines of context below the 'grep'd line.

Output will look like this when I click my re-mapped bottom-thumb mouse button:

--
KeyRelease event, serial 31, synthetic YES, window 0x3800001,
    root 0x4d, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x8, keycode 100 (keysym 0xff51, Left), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
--
KeyRelease event, serial 31, synthetic YES, window 0x3800001,
    root 0x4d, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Note that my bottom-thumb has been re-mapped to Alt+Arrow Left (combo key), so the keyboard events reported for the single click of the thumb button will be 2, one for Left [arrow left] and one for Alt_L (left Alt key). Buttons mapped to only one keyboard key will show one event, etc.

Have fun.

Edit:

Sorry, shining.

I wrote this up on and off over a period of time, and your post wasn't there when I started ... again, slow going due to distractions. However, hopefully my post fleshes out your answer. I guess I should have checked for thread updates before hitting the 'submit' button.

Last edited by MrWeatherbee (2007-08-21 18:14:47)

mac57 · 2007-08-22 03:46:11

Thanks once more MrWeatherbee. I don't know why I didn't try the grep approach before - I was almost joking when I suggested it in my original post - but it works like a charm. Thanks again for some outstanding posts - you put a lot of work into those and I really appreciate it!

AndyRTR · 2007-08-22 04:39:05

can you please put a summary into our wiki?

thx

SP: i'm also having a mx1000 and have never found the time to setup the additional keys after xorg 7.0 update when i lost their simple functionality done by xmodmap

MrWeatherbee · 2007-08-22 12:34:01

AndyRTR wrote:

can you please put a summary into our wiki?

I think Mac57 has that in process as stated over here in post #4:

http://bbs.archlinux.org/viewtopic.php?id=36470

mac57 wrote:

Thanks once more MrWeatherbee

I'm very pleased that I may have been helpful to you, so I hate to introduce a potential wrench in the works at this late date, but based on this post:

Gilneas wrote:

You'll have to go up to twelve for the MX1000 I believe.

and this quote from me in my first post:

MrWeatherbee wrote:

I don't have a Logitech, I have a Wireless IntelliMouse Explorer. But here is my setup and you can compare to your mouse and make changes as necessary.

I have to ask if you attempted to get any of the additional buttons / functions beyond the 9 button functionality that I described in my Intellimouse Explorer example guide?

mac57 · 2007-08-22 15:17:11

Yup, stay tuned. I will be posting an MX1000 specific wiki entry over the next day or so, detailing how to get the thumb buttons working.

I would love to add horizontal scrolling too, but I don't even know where to start. I can figure out the button presses now, many thanks to MrWeatherbee's excellent primers for this, but I don't have a clue what to map them too in order to make horizontal scrolling work in say Firefox, Opera and Konqueror. Does anyone know? Cheers!

MrWeatherbee · 2007-08-22 18:46:32

mac57 wrote:

I would love to add horizontal scrolling too, but I don't even know where to start. I can figure out the button presses now, many thanks to MrWeatherbee's excellent primers for this, but I don't have a clue what to map them too in order to make horizontal scrolling work in say Firefox, Opera and Konqueror. Does anyone know? Cheers!

Hmm ... I was hoping the following from one of my posts above would at least qualify as a clue:

MrWeatherbee wrote:

- But what about the tilt-wheel? The above "pointer" remapping simply placed click-events 8 & 9 at the desired positions (6 & 7, respectively), but as demonstrated in our Firefox tests, click-events 8 & 9 didn't really do anything. So now is where 'xbindkeys' and 'xvkbd' come in.
Through additional experimentation, we determine that scroll-left behavior and scroll-right behavior are achieved via keyboard keys left-arrow and right-arrow, but again, our mouse, by default, just can't perform these behaviors. To get our mouse buttons to perform the same behaviors we can achieve with our keyboard keys, we create a ~/.xbindkeysrc with this code:
"/usr/bin/xvkbd -xsendevent -text "\[Left]""
m:0x0 + b:8 
"/usr/bin/xvkbd -xsendevent -text "\[Right]""
m:0x0 + b:9
After restarting X, we test again to find our desired behaviors are achieved, i.e., left-tilting the mouse tilt-wheel ('xev' click-event 8) invokes a left-arrow keystroke thus scrolling left, and right-tilting the mouse tilt-wheel ('xev' click-event 9) invokes a right-arrow keystroke thus scrolling right.
- But ... later we find that other applications do not exhibit the desired behavior that we achieved in Firefox. For example, we know a bottom-thumb button-click should send us back in our file manager browsing history (e.g., Nautilus file manager), but the button does not do this (same is true for the top-thumb button-click). So, it looks like we are not through with 'xbindkeys'.
After additional experimentation or research, we determine that Alt+Left-Arrow causes back behavior and that Alt+Right-Arrow causes forward behavior. With this info, we can add to our ~/.xbinkeysrc:
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Left]""
m:0x0 + b:6 
"/usr/bin/xvkbd -xsendevent -text "\[Alt_L]\[Right]""
m:0x0 + b:7
Voilà ... mouse buttons / wheels and behaviors are all working as desired in Firefox and other applications that support mouse input.
Note:
Using:
xbindkeys -k
can help you determine the specifics about a particular mouse button or keystroke, i.e., it is similar to xev, but gives information on what code to paste into ~/.xbindkeysrc. If that does not provide enough information to get things set properly, please see the online documentation for xbindkeys and / or xvkbd.

Of course, since I don't have access to an MX1000, I don't know what you experience when trying to modify my process to fit the MX1000. I am willing to continue to help as am I very curious as to what went wrong. As it seems now, the only thing that my attempt at "teaching the fisherman to fish" achieved was a copy-and-paste of the Intellimouse example to get your side-buttons working.

I also notice in your HOWTO for the MX1000 (apparently the model for your upcoming wiki entry):

http://bbs.archlinux.org/viewtopic.php?id=36470

you leave this code in the ./xbindkeysrc you suggest for the MX1000:

"/usr/bin/xvkbd -xsendevent -text "\[Left]""
m:0x0 + b:8 
"/usr/bin/xvkbd -xsendevent -text "\[Right]""
m:0x0 + b:9

That code is the example code I provided which allows for left <-> right / horizontal scroll with the Intellimouse Explorer I have. So, with its inclusion in your HOWTO, I presumed the same code was allowing you to get your horizontal scroll working in the MX1000. But you say in your latest post that horizontal scroll isn't working! Why did you include it if it doesn't do anything? Maybe it does something else for the MX1000? If so, what?

I'm now confused.

*Note: hopefully the tone of this post isn't taken wrongly. If it seems I'm bustin' your huevos, it's all in good fun.

mac57 · 2007-08-23 19:45:49

Hi MrWeatherbee, no offense taken, no worries. Yes, I left this stuff in the HOWTO because it SHOULD be the answer - it just isn't! I did read too fast though - I missed the mapping to the left and right arrows. Not sure why! I haven't had the time yet to get back to it, and experiment with it and my newfound xev superpowers to determine what the issue is. I am sure I will resolve this BEFORE I complete the Wiki page... at least I plan to. If I just can't get it to go, I will eliminate this from the Wiki page.

However, all of that must wait for next week, since I am heading out of town for an extended weekend this coming weekend and won't really be able to put any work into this (or the Wiki entry) until then. In the meantime, I had prioritized getting Beryl going next as the higher priority item. Now that this is done, I will come back to the mouse issue and clean it up fully once and for all and then commit the solution to a Wiki page. I am looking forward to that as odd as that may seem. I have never added to a Wiki before. Always fun to learn new things.

THEN, onward and upwards to applying this newfound knowledge to a reluctant old Logitech Mouseman Wheel I have on an old VectorLinux setup (I have an old Dell XPS-R450 with VectorLinux 5.1 on it - for some reason, Arch 0.7.1 just wouldn't install on this box at the time). I have never been able to get the thumb button (there is just one - we are talking a 1998 mouse here) working under Linux. This will be the true test of whether I have really understood all of the above. If I can now apply it to a totally different situation and create a working solution, then you really have taught me how to fish MrWeatherbee! Cheers!

Last edited by mac57 (2007-08-23 19:53:32)

MrWeatherbee · 2007-08-23 19:53:33

mac57 wrote:

Hi MrWeatherbee, no offense taken, no worries. Yes, I left this stuff in the HOWTO because it SHOULD be the answer - it just isn't! I haven't had the time yet to get back to it, and experiment with it and my newfound xev superpowers to determine what the issue is. I am sure I will resolve this BEFORE I complete the Wiki page... at least I plan to. If I just can't get it to go, I will eliminate this from the Wiki page. However, all of that must wait for next week, since I am heading out of town for an extended weekend this coming weekend and won't really be able to put any work into this (or the Wiki entry) until then.

Excellent.

And have a fun and safe trip.

P.S.

I'm kind of glad you're taking a break from this ... 'cause it gives me a break, too.

mac57 · 2007-08-23 19:54:46

Owhhhh... now you are bustin' my huevos!!

Arch Linux

#1 2007-08-19 19:39:20

Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#2 2007-08-19 22:31:28

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#3 2007-08-19 22:47:00

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#4 2007-08-20 00:36:34

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#5 2007-08-20 04:14:35

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#6 2007-08-20 05:24:50

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#7 2007-08-20 14:39:34

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#8 2007-08-20 20:08:09

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#9 2007-08-21 15:00:32

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#10 2007-08-21 16:45:36

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#11 2007-08-21 18:01:01

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#12 2007-08-22 03:46:11

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#13 2007-08-22 04:39:05

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#14 2007-08-22 12:34:01

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#15 2007-08-22 15:17:11

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#16 2007-08-22 18:46:32

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#17 2007-08-23 19:45:49

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#18 2007-08-23 19:53:33

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

#19 2007-08-23 19:54:46

Re: Enabling Thumb Buttons on Logitech MX-1000 Mouse?

Board footer