# Xorg 7 Extra Mouse buttons

## XenoTerraCide

There is a new way to map mouse buttons in Xorg 7. which can be used to replace xmodmap. It may have in some ways made xmodmap deprecated (don't quote me on that I'm not sure). 

xorg 7.1 broke evdev for me (which causes X to crash) so for the time being I'm using the normal drivers for my mx1000.

```
Section "InputDevice"

# Identifier and driver

    Identifier  "Mouse1" 

    Driver      "mouse" 

    Option      "Protocol"      "Auto"  # Auto detect

    Option      "Device"        "/dev/input/mice" 

    Option      "Buttons"       "12" 

    Option      "ZAxisMapping"  "4 5" 

    Option      "ButtonMapping" "1 3 2 8 9 6 7 10 11 12"

EndSection
```

Identifier 

is a string that can be set however you choose. However it must match the string in the server layout section. I don't recommend changing it from the default unless you have reason to.

Driver  

Possible settings :

 "mouse" # a generic mouse driver. good enough for most people

 "evdev" # the event device interface, used for horizontal scrolling. you must have this in your kernel to use. stable in 7.0. but broken for me in 7.1

 "synaptic" #used for touchpads. doubt you'll have extra buttons if your'e using this  :Wink: 

 ... help me fill in others or if I have errors

Option "Protocol"

Possible settings:

"auto" #should be good enough for most people auto detects protocol needed.

... Help me fill in others

Option "Device"

Most Common setting is going to be "/dev/input/mice" if you're using udev however if you aren't using udev or created a special rule it may be something else.

Option "Buttons"

The number of button events your mouse generates. a standard mouse with a wheel has 5 buttons (left, right, middle, scroll up, scroll down) so what would be considered a "5-button mouse" has 7 buttons in X. 

Option "ZAxisMapping"

This maps the wheel. I think it should be set to "4 5" on all mice that even works on my 12 button mouse. try it... if it doesn't work let me know. I know in the past It would often be set to higher numbers if you had more buttons.

Option "ButtonMapping"

leave the wheel mapping out of this. varies based on mouse and system. 

troubleshooting your button mapping 

```
emerge xev xmodmap
```

 xev used to be packaged with xorg (I think) but now it's a seperate package. if you run it from the command line 

```
xev
```

it should pop a box up on your desktop which if you click in it it will tell you what event you button is mapped to.

```
ButtonRelease event, serial 27, synthetic NO, window 0x1e00001,

    root 0x4c, subw 0x0, time 1361751085, (171,177), root:(204,231),

    state 0x210, button 2, same_screen YES
```

you can see on the third line of my click it says button 2. originaly I noted it was set to button 3 so I had to change the first three numbers in my "ButtonMapping" from 1 2 3 to 1 3 2 because I noted that right click was not generating the proper event and that they were reversed and therefore changed the order.

xmodmap although no longer need for setting the order is usefull because It can print out what the hardware buttons are mapped to. 

```
xmodmap -pp
```

 gives me 

```
There are 16 pointer buttons defined.

    Physical        Button

     Button          Code

        1              1

        2              3

        3              2

        4              4

        5              5

        6              8

        7              9

        8              6

        9              7

       10             10

       11             11

       12             12

       13             13

       14             14

       15             15

       16             16

```

 the left collum tells you the hardware button and the right SHOULD tells you what button event its mapped to. this doesn't seem to apply if they're mapped to an already defined event... for example some of my other buttons are mapped to buttons 1 2 or 3 and that's the event they  generate... I found a way to fix that once but I can't recall how now. also it may show more buttons than you actually have, I'm not sure why but this shouldn't matter, just use the numbers that you actually have. (IE if you have a 7 button mouse only worry about 1-7)

----------

## Headrush

I've found with xorg-7.0 and the proper evdev support included in it, I don't need either of these lines anymore and things work the way they are suppose to:

```
Option      "Buttons"       "12" 

Option      "ZAxisMapping"  "4 5"
```

Xorg knows how many buttons I have and which ones are the wheel mouse.

I've also read that in xorg-7.1 the Device option isn't needed anymore and a Name option that is more static is used. (Bye bye custom udev rules for mouse)

Edit: I think a lot of people will appreciate knowing about the ButtonMapping option. Should make things simple for those with issues and help diagnosing problems when people have left over xmodmap commands they forgot about.Last edited by Headrush on Sun Jul 09, 2006 3:17 am; edited 1 time in total

----------

## XenoTerraCide

 *Quote:*   

> I've found with xorg-7.0 and the proper evdev support included in it, I don't need either of these lines anymore and things work the way they are suppose to:

  this is true but not for all people (as I understand). As I mentioned in X11R7.1 evdev breaks for me ( so I wouldn't rely on it too much ) and I don't know if it will get fixed before they mark it stable    :Mad:   X won't even start if I run evdev in 7.1 it crashes. I've filed bugs upstream and with gentoo but haven't gotten anywhere.

----------

## halfgaar

I'm having loads of problems with my mouse since I upgraded to Xorg 7. The "mouse" driver is not able to handle all the buttons of my Logitec MX500; some are ignored, others act simply as button 1 for example. Using evdev solves it, but for some reason, button 6 and 7 (which are browser back and forward I believe) are nowhere to be found. They are skipped, and the highest button number reported by xev is 12, while the mouse only has 10 buttons. I of course used the logitech applet to disable "cruite control" (it's a stupid function anyway). Also, the ButtonMapping option doesn't seem to do anything.

Headrush: can you post your entire mouse section?

 *Quote:*   

> I've also read that in xorg-7.1 the Device option isn't needed anymore and a Name option that is more static is used. (Bye bye custom udev rules for mouse) 

 

I was able to do that with 6.8, like so: 

```
#Section "InputDevice"

#    Identifier  "Mouse[0]"

#    Driver      "mouse"

#    Option      "CorePointer"

#    Option      "Protocol" "evdev"

#    Option      "Dev Name" "B16_b_02 USB-PS/2 Optical Mouse" # cat /proc/bus/input/devices

#    Option      "Dev Phys" "usb-*/input0" # cat /proc/bus/input/devices

#    Option      "Buttons" "10"

#    Option      "ZAxisMapping" "9 10"

#EndSection
```

But that doesn't work anymore. And, it was flakey, because it was unable to handle replugs of the mouse.

I think I would prefer a custom udev rule, because I don't think my mouse will always be /dev/input/event3. Do you have a custom rule I can adapt for my use?

----------

## halfgaar

Ok, I got it partially working. My xorg.conf section looks like:

```
Section "InputDevice"

    Identifier  "Mouse[0]"

    Driver      "evdev"

    Option      "Device" "/dev/input/mx500"

    Option      "Buttons" "10"

EndSection
```

In /etc/profile I execute xmodmap (because buttonmappings doesn't work) and xbindkeys to map keys to my extra 3 mouse buttons:

```

# This is a dirty way to make sure this code only gets executed when loging in

# with X present and only when loging in using xdm, where the terminal is

# dumb. This should also mean that this code gets executed once.

if [ $DISPLAY ] && [ $TERM == "dumb" ]; then    

    # There is a ButtonMapping option in xorg.conf, but it does nothing.

    xmodmap -e "pointer = 1 3 2 4 5 8 9 6 7 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32" > /dev/null 2>&1

    # Load xbindkeys if not already running for this user.

    XBINDKEYS=`ps --user \`whoami\`|grep xbindkeys|grep -v grep`

    if [ ! -n "$XBINDKEYS" ]; then

        xbindkeys > /dev/null 2>&1

    fi

fi
```

My entry in the udev file 10-local.rules is:

```

# My logitech mouse

KERNEL=="event*", SYSFS{name}=="B16_b_02 USB-PS/2 Optical Mouse", SYMLINK="input/mx500"
```

The device name I got from /proc/bus/input/devices. Using the device name in the xorg.conf doesn't work, despite what this howto (this section) says.

The browser buttons work now, but buttons 8 and 9 are still skipped, meaning my other buttons are 10, 11 and 12, whereas it was 8, 9 and 10 with xorg 6.8. But, I guess I can live with it.

Any improvements (escpially the buttonmapping option problem) are welcome.

----------

## Headrush

halfgaar, here is my xorg.conf section for modular X for my Logitech MX510. (everything works)

```
Section "InputDevice"

        Identifier  "Logitech MX510"

        Driver      "evdev"

        Option      "Device"        "/dev/input/MX510"

        Option      "CorePointer"

EndSection
```

/de/input/MX510 is a custom udev rule I have to make a staic device node.

```
BUS="usb", SYSFS{idVendor}="046d", SYSFS{idProduct}="c01d", NAME="input/MX510", GROUP="kdemouse", MODE="664"
```

I have no xmodmap commands and don't need to turn cruise control off with the logitech-app. All 10 buttons are recognized. Numbers 6 and 7 are skipped, but this is since they are usually mapped to horizontal scroll wheels.

----------

## halfgaar

As an additional suggestion, you can increase the CPI (counts per inch) of the optical sensor with the logitech applet. Without the applet, the sensors runs at only 400. Increasing the CPI is useful for todays screen resolutions, so that you don't have to enable an extreme amount of acceleration in your mouseconfig. 

Anyway, you have about the same what I have now, except the modmap command. 

 *Quote:*   

> Numbers 6 and 7 are skipped, but this is since they are usually mapped to horizontal scroll wheels.

 

Ah, so that's the official function. I've got them mapped to the side buttons, which is convinient for firefox.

When using a mouse in Windows with side buttons for browsing BTW, does that also just give off horizontal scrolling signals, or do the windows drivers manipulate the IE component directly?

----------

## MrNugget

I got a Logitech MX500 and used to map the buttons like this with my old xorg-installation:

```
/usr/X11R6/bin/xmodmap -e "pointer = 1 2 3 6 7 4 5" &

/usr/bin/imwheel -k -f -p -b 67 &
```

Is there any way i can get my mouse working without recompiling the kernel and using evdev?

----------

## Headrush

 *halfgaar wrote:*   

>  *Quote:*   Numbers 6 and 7 are skipped, but this is since they are usually mapped to horizontal scroll wheels. 
> 
> Ah, so that's the official function. I've got them mapped to the side buttons, which is convinient for firefox.
> 
> When using a mouse in Windows with side buttons for browsing BTW, does that also just give off horizontal scrolling signals, or do the windows drivers manipulate the IE component directly?

 

I'm not suggesting that it is official, but same way most apps built think buttons 4 and 5 are vertical scroll wheel, many default to 6 and 7 for horizontal. Its more an app default than anything else.

My guess is on Windows if it works out of the box, they have setup that feature in IE to work on specific buttons by default.

----------

## halfgaar

 *MrNugget wrote:*   

> I got a Logitech MX500 and used to map the buttons like this with my old xorg-installation:
> 
> ```
> /usr/X11R6/bin/xmodmap -e "pointer = 1 2 3 6 7 4 5" &
> 
> ...

 

You can compile evdev as module, and install it.

imwheel is not necessary BTW, and is only in the way. Get rid of it  :Smile: 

----------

## XenoTerraCide

you get it working? with ButtonMapping were you registering button clicks with xev? you may need to stop using xmodmap and any other tools (imwheel, xbindkeys, etc).

did you try this 

```

Option "ZAxisMapping" "4 5"

Option "ButtonMapping" "1 3 2 8 9 6 7 10"
```

I think the virtual mapping of your buttons needs to be like this (left, middle, right, {scroll forward, scroll backward}, forward, backward, <h-scrolls here?> {don't include these if you're using button mapping}) so I would try mapping hardware in that order. and yes the forward backward is somewhat application specific. However I believe in kde you can change the mapping to match it.

the reason that you can't unplug and replug your mouse using evdev is that X doesn't support hotplugging. and if you're using an non-static udev rule it will change your event number when you plug it back in. In xorg 7.2 (not released yet) the XInputHotplug patch/module is supposed to be included and should allow for the dynamic plugging of input devices. 

I reverted to xorg 7.0 I'll see what I can do to play with evdev again.

headrush that udev rule goes in /etc/udev/rules.d/50-udev.rules right? does it matter where? I've been wanting to do one for a while but never bothered. I'll try to add something about it at the top.

----------

## Headrush

 *XenoTerraCide wrote:*   

> headrush that udev rule goes in /etc/udev/rules.d/50-udev.rules right? does it matter where? I've been wanting to do one for a while but never bothered. I'll try to add something about it at the top.

 

The rules just goes in /etc/udev/rules.d/##-udev.rules

The filename has to end in .rules The number is arbitrary, but remembers that udev scans these files lowest to highest and the first rule that matches for a device is the one it uses. So for my udev rules I add them all to /etc/udev/rules.d/10-local.rules This way my rules should always take precedence over any added by Gentoo.Last edited by Headrush on Sun Jul 09, 2006 6:09 pm; edited 1 time in total

----------

## halfgaar

When I tried the ButtonMapping option, I did not run xmodmap or xbindkeys, although the latter wouldn't have mattered. I indeed used xev to register clicks. The ButtonMapping option in xorg.conf just doesn't seem to do anything, the mapping remained 1:1, 2:2, 3:3, 4:4 etc.

 *Quote:*   

> did you try this
> 
> ```
> Option "ZAxisMapping" "4 5"
> 
> ...

 

I'm not sure if I've tried that exact combination, but it's very likely. I have tried all kind of combinations along these lines, including and excluding button 4 and 5.

 *Quote:*   

> I think the virtual mapping of your buttons needs to be like this (left, middle, right, {scroll forward, scroll backward}, forward, backward, <h-scrolls here?>

 

I thought horizontal scroll and forward/backward was the same.

 *Quote:*   

> However I believe in kde you can change the mapping to match it. 

 

I can't find any option in the KDE control panel related to special mouse buttons. Konquerer also doesn't respond to button 6 and 7 (which act as forward/backward in Firefox).

 *Quote:*   

> headrush that udev rule goes in /etc/udev/rules.d/50-udev.rules right? does it matter where? I've been wanting to do one for a while but never bothered. I'll try to add something about it at the top.

 

No, put it in 10-local.rules, or any other file with a lower prefix number than 50. If you put custom changes in system files, they get overridden when you update the software.

----------

## Headrush

I just tried the "ButtonMapping" option and it did absolutely nothing. Maybe it doesn't work with the evdev driver?

XenoTerraCide, i noticed in your first post you are using the mouse driver, not the evdev driver.

----------

## XenoTerraCide

hmmm the mapping should work.... I'm going to look up my source it was on gentoo-wiki.com somewhere I stopped using xmodmap yesterday because it stopped recognizing my buttons. and know the horizontal scroll isn't the same. I once mapped those buttons to switch tabs in firefox   :Very Happy:  I just think they are initially mapped the same. The setting in kde you are looking for is in shorcuts. and its in konqueror. just remap the forward and backward shortcuts to the mouse clicks.

----------

## XenoTerraCide

you might be right... like I said because they broke evdev in 7.1 and that's what I was on.  :Mad:  I'll see in a minute.

----------

## Headrush

 *XenoTerraCide wrote:*   

> you might be right... like I said because they broke evdev in 7.1 and that's what I was on.  I'll see in a minute.

 

Doesn't matter for me, my system is working fine the way it is.

When you say evdev is broke in 7.1, what does that exactly mean? Totally, some features? What source did you get that info from?

----------

## XenoTerraCide

sorry for the fast multiple posts. http://gentoo-wiki.com/HOWTO_Advanced_Mouse is where I got my info

 *Quote:*   

> 
> 
> I believe this is the correct way to use the button mapping in XOrg 7. You have X buttons, not including the wheel up/down, only the wheel click. In the case of my IMExplorer, 2 side buttons, left, right, and wheel click... 5 buttons. Set buttons to 5. Set your wheel number with the ZAxis mapping. Then do not use those numbers in the button mapping, only the 5 buttons. This replaces the need for xmodmap. Hope this helps.
> 
> File: /etc/X11/xorg.conf
> ...

 

----------

## XenoTerraCide

this thread moves too fast. I mean totally when I tried running an evdev module in xorg 7.1 it CRASHED. X would NOT START. who did I get that from? ME. it may work for you.... I don't know that it's completely broke but I filed bugs upstream I filed bugs with gentoo... never got a resolution. xorg basically pisses me off about it.

----------

## Headrush

 *XenoTerraCide wrote:*   

> this thread moves too fast. I mean totally when I tried running an evdev module in xorg 7.1 it CRASHED. X would NOT START. who did I get that from? ME. it may work for you.... I don't know that it's completely broke but I filed bugs upstream I filed bugs with gentoo... never got a resolution. xorg basically pisses me off about it.

 

I just checked the wiki article you posted. The input section you posted originally is the section for xorg-6.8.2

Edit: The buttonmapping option does seem to pertain to xorg-7.0 though.Last edited by Headrush on Sun Jul 09, 2006 6:32 pm; edited 1 time in total

----------

## XenoTerraCide

works in xorg 7 for me but I know most of that was for xorg 6.8. I'm going to check out to see if it works for evdev for me. and my evdev along with some other issues is why x86 didn't have xorg 7.1 marked stable the other day. A lot of architectures did.

----------

## halfgaar

 *XenoTerraCide wrote:*   

> I once mapped those buttons to switch tabs in firefox   

 

How do you map mouse buttons to actions in firefox?

 *XenoTerraCide wrote:*   

> The setting in kde you are looking for is in shorcuts. and its in konqueror. just remap the forward and backward shortcuts to the mouse clicks.

 

Strange, forward and back are configured as XF86Back and XF86Forward, but it doesn't seem to work. In firefox is works fine.

Very logical BTW that the options exist under keyboard shortcuts...

----------

## XenoTerraCide

k I just tested with evedev and my mappings are still working.... do you have protocol configured with evdev you shouldnt' need that. also I tried creating a rule for udev and it didn't work.

should this work? 

```
BUS="usb", SYSFS{idVendor}="046d", SYSFS{idProduct}="c70a, NAME="input/MX1000", GROUP="users", MODE="664"
```

```
slave-i ~ # cat /proc/bus/input/devices 

I: Bus=0003 Vendor=046d Product=c70e Version=4000

N: Name="Logitech Logitech BT Mini-Receiver"

P: Phys=usb-0000:00:02.1-4.2/input0

S: Sysfs=/class/input/input2

H: Handlers=kbd event0 

B: EV=120003

B: KEY=10000 7 ff800000 7ff febeffdf ffefffff ffffffff fffffffe

B: LED=1f

I: Bus=0003 Vendor=046d Product=c70a Version=4000

N: Name="Logitech Logitech BT Mini-Receiver"

P: Phys=usb-0000:00:02.1-4.3/input0

S: Sysfs=/class/input/input3

H: Handlers=kbd mouse0 event1 

B: EV=f

B: KEY=c0002 400 0 0 fff0001 f80 78000 6639fa d841d7ad 9e0000 0 0 0

B: REL=1c3

B: ABS=1 0

```

<edit> as far as how I mapped that I think I had to map them to different keys using xbindkeys. give me a little while and I'll do it again.  :Wink: 

----------

## Headrush

 *XenoTerraCide wrote:*   

> k I just tested with evedev and my mappings are still working.... do you have protocol configured with evdev you shouldnt' need that. also I tried creating a rule for udev and it didn't work.
> 
> should this work? 
> 
> ```
> ...

 

You don't have a rule that takes precedence before this one do you? That looks ok. What file did you put it in?

FYI: An easier way to find Vendor and Product IDs is to use lsusb

I did a little testing to see why the buttonmappings wasn't doing anything, so I check the xorg log /var/log/Xorg.0.log

One way or the other, something should be there even if it isn't a recognized option. The weird part, not a mention of it even seeing the option. Very odd.

----------

## XenoTerraCide

same here and yet my mappings work... I'll check to see if I get something using the mouse driver in a minute... 

its in /etc/udev/rules.d/10-local.rules and I had to create that file nothing else in it.

----------

## Headrush

 *XenoTerraCide wrote:*   

> same here and yet my mappings work... I'll check to see if I get something using the mouse driver in a minute... 
> 
> its in /etc/udev/rules.d/10-local.rules and I had to create that file nothing else in it.

 

That should work fine. Are you restarting udev with udevstart?

Ya looking at the xorg log, as soon as Xorg sees evdev as the drive and gets the device node location, it autoprobes/determines the rest of the information. If I add other "phony" options, it ignores them too, so it's not just buttonmappings. With previous xorg versions, X used to gag when bogus options were in xorg.confLast edited by Headrush on Sun Jul 09, 2006 7:05 pm; edited 1 time in total

----------

## halfgaar

 *XenoTerraCide wrote:*   

> k I just tested with evedev and my mappings are still working.... do you have protocol configured with evdev you shouldnt' need that. also I tried creating a rule for udev and it didn't work.
> 
> should this work? 
> 
> ```
> ...

 

I don't have protocol defined with evdev: my config can be seen above. It also shows how I set up xbindkeys, so if that's how you set up firefox, then I won't need help, because I've already got that working.

As headrush said, this just seems to be a 7.0 bug.

----------

## XenoTerraCide

it might be.... how come it retains my mappings   :Confused:  my xorg log with evdev. 

```
(II) Mouse1: Found mouse buttons
```

with mouse

```
(**) Option "Buttons" "12"

(==) Mouse1: Emulate3Buttons, Emulate3Timeout: 50

(**) Mouse1: ZAxisMapping: buttons 4 and 5

(**) Option "ButtonMapping" "1 3 2 8 9 6 7 10 11 12"

(**) Mouse1: Buttons: 16

(II) 3rd Button detected: disabling emulate3Button

```

 like I said I've always had to map the buttons it never gets them right...

<edit> because I couldn't remember udevstart... I rebooted. which would have applied it. </edit>

----------

## Headrush

It occurred to me that with the move to modular X we could also be using different versions of evdev. So for the sake of completeness, I have the following"

```
[ebuild   R   ] x11-drivers/xf86-input-evdev-1.0.0.5  USE="-debug%" 0 kB

[ebuild   R   ] x11-drivers/xf86-input-mouse-1.0.4  USE="-debug" 0 kB

[ebuild   R   ] x11-drivers/xf86-input-keyboard-1.0.1.3  USE="-debug%" 0 kB
```

It appears that the evdev driver probes the device for buttons and sets them properly if possible. A vertical scroll wheel to buttons 4 and 5 and if a horizontal scroll wheel to buttons 6 and 7. If you have a button with lots of buttons (+3), but not a horizontal scroll wheel, it seems it is smart enough to not use 6 and 7. (Looks like the devs are trying to make things more standard)

I don't know if this is official, but appears to me like this is what is happening.

Edit: XenoTerraCide, I notice I don't get the emulate3buttons defaults in my logs either, we must be running different versions.Last edited by Headrush on Sun Jul 09, 2006 10:14 pm; edited 1 time in total

----------

## XenoTerraCide

```
* x11-drivers/xf86-input-evdev 

     Available versions:  1.0.0.5 ~1.1.2-r1

     Installed:           1.0.0.5

     Homepage:            http://xorg.freedesktop.org/

     Description:         X.Org driver for evdev input devices

```

 as of right now if your using xorg 7 you will need to use 1.0.0.5 and if you're using 7.1 you'll use 1.1.2-r1. maybe they are attempting to standardize.

I restarted the machine instead of udev because I couldn't remember that command and was lazy.

----------

## halfgaar

I use:

evdev: 1.0.0.5

mouse: 1.0.4

keyboard: 1.0.1.3

xorg: 7.0-r1

The same as headrush, and our problems are the same as well as I understand it.

 *Quote:*   

> If you have a button with move buttons, but not a horizontal scroll wheel, it seems it is smart enough to not use 6 and 7.

 

I asume you meant a mouse with move buttons... But since firefox maps 6 and 7 to forward and back, it would find it logical if the h-scroll would be mapped to 6 and 7. On the other hand, since Konquerer is configured to respond to XF86Backward and Forward, but doesn't respond to my backward/forward buttons, perhaps button 6 and 7 being horizontal scroll is indeed how it's supposed to be, and that firefox just handles them wrong. 

But, when remapping so that the side buttons are logical button 8 and 9, Konquerer doesn't respond either.

edit: without running xmodmap, the side buttons are 8 and 9, but they both act as button 1, in every program. This way, the side buttons also aren't working in konquerer as forward and backward. Strange stuff...

----------

## XenoTerraCide

I've semi determined how I got the konqueror and tab switching thing you're going to need xvkbd. 

```
emerge xvkbd
```

 I called that program from xbindkeysrc.

I've also determined that the mouse thing does indeed NOT work with evdev... I checked to see if my settings were taking effect and they are not.   :Embarassed: 

----------

## XenoTerraCide

got it.

my .xbindkeyrc

```
 # back and forward

"xvkbd -xsendevent -text "\[Alt_L]\[Left]""

m:0x10 + b:8

"xvkbd -xsendevent -text "\[Alt_L]\[Right]""

m:0x10 + b:9

# full screen

#"xvkbd -xsendevent -text "\[F11]""

#m:0x10 + b:10

# the up and down by the wheel pages up and down

"xvkbd -xsendevent -text "\[Page_Up]""

m:0x10 + b:11

"xvkbd -xsendevent -text "\[Page_Down]""

m:0x10 + b:12

# Left and Right on the wheel switch tabs

"xvkbd -xsendevent -text "\[Control_L]\[Page_Up]""

m:0x10 + b:8

"xvkbd -xsendevent -text "\[Control_L]\[Page_Down]""

m:0x10 + b:9 

```

----------

## XenoTerraCide

got it.

my .xbindkeyrc

```
 # back and forward (b:6 is button 6 in xvkbd)

"xvkbd -xsendevent -text "\[Alt_L]\[Left]""

m:0x10 + b:6 

"xvkbd -xsendevent -text "\[Alt_L]\[Right]""

m:0x10 + b:7

# Left and Right (horizontal scroll) on the wheel switch tabs (use xev to test which even you have for this 

"xvkbd -xsendevent -text "\[Control_L]\[Page_Up]""

m:0x10 + b:8

"xvkbd -xsendevent -text "\[Control_L]\[Page_Down]""

m:0x10 + b:9 

```

well that makes firefox work... needs work in konqueror... <edit> k I had changed something earlier I figured it out. this has been edit to resemble the change. don't forget to change the alternate shortucut for activate next /previous tab in konqueror</edit>

----------

## halfgaar

I already told you, I have a working xbindkeys setup, also using xvkbd, which sends keystrokes. There was no need to explain it. Not for me at least.

----------

## Headrush

 *halfgaar wrote:*   

>  *Quote:*   If you have a button with move buttons, but not a horizontal scroll wheel, it seems it is smart enough to not use 6 and 7. 
> 
> I asume you meant a mouse with move buttons... But since firefox maps 6 and 7 to forward and back, it would find it logical if the h-scroll would be mapped to 6 and 7. On the other hand, since Konquerer is configured to respond to XF86Backward and Forward, but doesn't respond to my backward/forward buttons, perhaps button 6 and 7 being horizontal scroll is indeed how it's supposed to be, and that firefox just handles them wrong. 
> 
> But, when remapping so that the side buttons are logical button 8 and 9, Konquerer doesn't respond either.
> ...

 

I fixed my wording, I was in a rush as I went out the door.

I meant the evdev support seems to find the buttons without configuration, and by default it tries to make the vertical scroll wheel map to buttons 4 and 5 and the horizontal scroll wheel map to buttons 6 and 7.

If you don't have either, it skips those buttons, hopefully starting to establish a standard.

As we've all pointed out, the apps screw it up by each expecting a different button for different actions. Although you can remap the button order this tends to fix one app yet cause another to fail. In this case you have to change more than just the button order with xmodmap or buttonmappings and need to change the setting within the application.

----------

## halfgaar

 *Quote:*   

> As we've all pointed out, the apps screw it up by each expecting a different button for different actions. Although you can remap the button order this tends to fix one app yet cause another to fail. In this case you have to change more than just the button order with xmodmap or buttonmappings and need to change the setting within the application.

 

Until now, Firefox is the only app which I've been able to let understand one of the extra mouse buttons at all. Do you have any other apps which respond to mousebuttons without the use of external software (like xbindkeys)?

----------

## XenoTerraCide

I believe konqueror does by default the problem is the default is different from firefox. I'm sure there are others but I prefer to set my own keyboard and mouse shortcuts. like the windows key brings up my terminal.

----------

## halfgaar

 *Quote:*   

> I believe konqueror does by default the problem is the default is different from firefox.

 

I just discovered that konquerer indeed uses button 6 and 7 as horizontal scroll. I wasn't smart enough to include a horizontal scrollbar in my previous tests...

But, the issue remains which of the logical keys it sees as browser back and forward, because I can't get it to respond to any button as forward/backward. It could also be that it's an X signal that is not generated properly. After all, Konquerer is configured by default to respond to XF86Forward and XF86Backward. Perhaps those signals need to be generated somehow. I will try to look into it tomorrow.

----------

## XenoTerraCide

sigh... you need to CHANGE THAT. set xbindkeys like I have and both firefox and konqueror will work.

----------

## halfgaar

 *XenoTerraCide wrote:*   

> sigh... you need to CHANGE THAT. set xbindkeys like I have and both firefox and konqueror will work.

 

It may work, but it's very annoying, limited and a kludge. Annoying because in apps which don't have forward and backward, like blender or a terminal, pressing that mousebutton does all kinds of stupid things. Limited, because in Firefox, under certain conditions with pages with flash animations or movie windows or something similair, the keycode won't work. You have to click somewhere else in the page first. A kludge because there are supposed to be standard signals for this. Microsoft figured this out 8 years ago... 

There are a whole bunch of those XF86xxxx signals, like stop, forward, backward, refresh, mail, etc. This page confirms that firefox handles them incorrectly. You can map those signals with xmodmap to certain keys. To map them to mousebuttons, you can also use xbindkeys with xvkbd. Instead of letting it send a key, you send the signal, like so: 

```
"xvkbd -xsendevent -text '\[XF86Back]'"
```

Kind of a kludge however, because it won't work out of the box, and any Linux user without skills won't be able to set that up. I start xbindkeys in /etc/profile for each user logged in, as described earlier. Another annoyance of using xbindkeys is, that the call to xvkbd can take a long time when there is harddisk activity, and the program is not in cache anymore.

I filed a bugreport at the firefox bugzilla. I was unable to find any similair bugs, but I'm almost positive I get a "this bug is a duplicate of bug...". I always do, somehow. Or perhaps there is something about this whole mouse issue that escapes me and the bug is invalid anyway  :Smile: 

Edit, OK, it's a duplicate. Of a bug filed on 2001-01-25... You know, I don't get it. I know I have searched for more than one of the words present in that bug report, but it never came up. Bugzilla needs a new search engine...

----------

## XenoTerraCide

I wouldn't know about all that kde stuff I use fluxbox.   :Wink: 

----------

## Headrush

 *XenoTerraCide wrote:*   

> I wouldn't know about all that kde stuff I use fluxbox.  

 

If you're referring to the things halfgaar said, I didn't think any of that was KDE specific, it is a problem with X and apps.   :Razz: 

----------

## XenoTerraCide

right.... to early this morning...

----------

## doubleagent

Thank you - this was very helpful.  I got my mouse working in only a few minutes!  :Very Happy: 

----------

