Bug 141205

We fixed that problem within the mouse driver itself. If you don't
mind have a look at the xorg bugzilla ID: 4915

   https://bugs.freedesktop.org/show_bug.cgi?id=4915

Well, barring that the new default mapping will break programs designed for the old mapping ... no doubt necessary given the existing 4D and tiltwheel mice though.

Given the size change in the mouse event descriptor, they must also have a backwards-compatible access for pre-6.9 software. Do they have a means to specify which 7 buttons are presented to such software? Seems this doesn't completely resolve the issue for a software stadpoint, it just moves the question to another part of the code.

Hmm, I think there is no problem with backward compatibility. The patch
for the mouse driver will leave a gap for the buttons 4 5 6 7 which are
reserved for mouse wheels ( a maximum of 2 wheels ). The remapping you did
with xmodmap is done in the driver automatically. The number of buttons
is automatically increased to Buttons + 4.

I cannot see a problem here because all older applications are expecting the
wheel on button 4 and 5. The events for 6 and 7 are visible as well and the
handling depends on the application. The configuration sax creates with
Buttons 7 and ZAxisMapping to 4 and 5 is working with the old and the new
mouse driver

Steve, your mouse should work out-of-the-box with a standard (i.e. sax2 generated) mouse profile (use 'sax2 -r' to ignore your old one) and no(!) xmodmap. Buttons 1-3 should producess button 1-3 events, the wheel 4+5, the additional buttons 8+9. Buttons 6+7 are reserved for a secondary wheel.

This setting has been explicitely designed to be backwards-compatible without any changes to programs.

In fact, if you use the xmodmap afterwards the mouse buttons might not work any more. Maybe that's all you are seeing.

You might also want to read the mouse (4) manpage of X11:

       Option "ZAxisMapping" "N1 N2 N3 N4"
              Set the mapping for the Z axis  (wheel)  motion  to  buttons  or
              another  axis  (X  or  Y).   Button  number  N1 is mapped to the
              negative Z axis motion and button number N2  is  mapped  to  the
              positive  Z  axis motion.  For mice with two wheels, four button
              numbers can be specified, with the negative and positive  motion
              of the second wheel mapped respectively to buttons number N3 and
              N4.  Default: "4 5 6 7".

       Option "ButtonMapping" "N1 N2 [...]"
              Specifies how physical mouse buttons are mapped to logical  but‐
              tons.   Physcial button 1 is mapped to logical button N1, physi‐
              cal button 2 to N2, and so forth.  This enables the use of phys‐
              ical buttons that are obscured by ZAxisMapping.  Default: 1‐to‐1
              mapping.

The ButtonMapping default description is actually wrong - it is "1 2 3 8 9 10 11 ..." in order to avoid the gap used for ZAxisMapping.

The problem is, older versions of X - and programs written to be compatible with them - expect buttons numbered 1-7. For example, Opera (versions from one of the 7.6 betas to current stable and development versions) expects the mouse's Back button to be button 6 and the Forward button to be button 7. So it would then be necessary to map 8 to 6 and 9 to 7. Likewise, Firefox 1.5 works properly with my configuration, though I really didn't test it with the original configuration.

I have informed Opera's developers of this change, though they haven't responded at this time. (I'm a volunteer providing product support for them.)

The config I listed in the original post, with the system set for 5 buttons, ZAxisMapping of "6 7" and xmodmap -e "pointer = 1 2 3 6 7 4 5" works for both browsers in Xorg 6.8 and prior versions, while the default setting did not.

Older programs typically don't have any knowledge about buttons above 5 (4 and 5 for the wheel). Opera is an exception.

To my knowledge, 4-7 has always been reseved for mouse wheels. So if we chose to use buttons 6+7, we would break other (probably more) applications.

You can easily use
  Option "ZAxisMapping" "4 5"
  Option "ButtonMapping" "1 2 3 6 7 8 9"
to get the same configuration as before, without the need for using xmodmap, which is broken by design.

At the moment we are waiting for reports in order to verify the behavior. Can you check these options and check how opera and firefox work in their default configuration? Eventually we could change the default configuration as well, but only if this really improves default application behavior.

The original setup was no button mapping specified, number of buttons specified as 7, and ZAxisMapping "4 5". Well, that's not quite correct - for some reason the original setting isn't listed in SaX2. The original setting was named ImEx PS/2, I tested a couple of other settings to see if they'd work and then had to leave it as Explorer PS/2 as the original setting wasn't listed.

Anyway ... the original Explorer PS/2 setting then ... showed absolutely no reaction from the extra buttons using xev. Before I actually made any manual changes to xorg.conf I did test it with xev. That in itself should be fairly definitive. Not yet having SUSE 10.1 to play with - I saw that there was a development version listed - nor Xorg 6.9/7.0, I can't say whether those perform as intended.

I see a saved backup or so in /etc/X11 which presumably reflect the original settings, I will test that with xev, Opera and Firefox and then add the button mapping and see if that helps. Expect an update later tonight.

Now that's strange ... restoring my settings to those saved in xorg.conf.install, this is how xev reports the Back button:

ButtonPress event, serial 29, synthetic NO, window 0x2400001,
    root 0x3b, subw 0x0, time 271502, (82,123), root:(758,149),
    state 0x10, button 216, same_screen YES

ButtonRelease event, serial 29, synthetic NO, window 0x2400001,
    root 0x3b, subw 0x0, time 271610, (82,123), root:(758,149),
    state 0x10, button 216, same_screen YES

This is how xev lists the Forward button:

ButtonPress event, serial 29, synthetic NO, window 0x2400001,
    root 0x3b, subw 0x0, time 274176, (78,123), root:(754,149),
    state 0x10, button 232, same_screen YES

ButtonRelease event, serial 29, synthetic NO, window 0x2400001,
    root 0x3b, subw 0x0, time 274297, (78,123), root:(754,149),
    state 0x10, button 232, same_screen YES

There is no listing at all for the wheel, as ZAxisMapping was not part of the xorg.conf.install settings, and I see no evidence of any program responding to the wheel. Buttons 1, 2 and 3 were as expected.

That's with the settings

Section "InputDevice"
  Driver     "mouse"
  Identifier "Mouse[1]"
  Option     "Protocol" "Auto"
  Option     "Device"   "/dev/input/mice"
EndSection

Apparently, the version of X in 10.0 doesn't support ButtonMapping at all. Adding the previously-listed lines for ZAxisMapping and ButtonMapping had the same effect as originally given - the wheel as buttons 4 and 5, and the extra buttons not showing in xev. Throwing in "Buttons" "7" from the Explorer PS/2 config also had no effect. Finally I put it back as I'd had it when I sent the first message (other than using Xmodmap) and could now see all buttons and the wheel, though of course the buttons and wheel were reversed.

As far as Opera, through version 7 they treated buttons 6 and 7 as the second wheel. After communication from other Linux users and confirmed by myself that most Linux versions at the time were assigning Explorer buttons as 6 and 7 ("at the time" being a little over a year ago) they took a very simple solution - they made buttons 6 and 7 configurable, though by default mapped as Back and Forward. If anyone actually was using a 4D mouse, they could map the buttons as ScrollLeft and ScrollRight, and thus everyone was happy. Hence the biggest problem here is not 4D mice, but the compatibility issue with older versions of Linux. Until recently, they were still producing a package compatible with RedHat 7's libraries.

In that sense, I suppose this has become a compatibility question for Xorg - but it would be nice if you fixed SaX2 in 10.0 to produce a meaningful configuration with Explorer mice, instead of mapping both the buttons and wheel to the same logical buttons.

Ah, you got OpenSuSE 'Released' aka 10.0, not 'Development' aka 10.1. You should have noted that earlier, this is a very new feature. Sax didn't do anything here, as this required action from the user side (xmodmap) which is not done easily in a consistant manner.

The new approach is much cleaner and more consistent. Yes, WRT this feature 10.1 is not backwards compatible (you have to nuke the xmodmap in your files), but sometimes you have to break things to make them right.

BTW - the 'openSUSE' product means the infrastructure. Changed that.