Bug 4212

I can confirm this issue here, with both 2.6.13-gentoo-r2 and 2.6.13-hardened
kernels, and Gentoo's modular xorg builds.

"xmodmap -pp" will confirm that the pointer mapping has changed, but buttons 2
and 3 are still the wrong way around.

I can confirm this aswell with Gentoo's modular X build and evdev driver.
Running Linux 2.6.13-gentoo-r3.

With the latest patch against CVS from bug #968 I get a server crash when
clicking the mouse-wheel after running xmodmap to set the buttons in the correct
order.

I'm seeing the same thing, though with 'mouse' instead of 'evdev'.  I read
through the mouse driver source, and AFAICT, the xmodmap translation isn't done
in the driver anyway, so this seems like a server(?) problem.  xmodmap reports
the correct mapping, but the reality doesn't quite match up.

Anyway, not sure what versions to report with all the various version numbers,
but the server is:

X Window System Version 6.99.99.901 (7.0.0 RC 1)

and mouse_drv is:

(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input/mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
        compiled for 6.99.99.901, module version = 1.0.0
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 0.5

I am probably suffering from this bug and reported it in bug #4913. I think it
describes the problem better and is in the right Product/Component so maybe this
could be marked as a duplicate of it, but I don't mind if my bug is marked as a
duplicate of this. I leave the decision to the xorg people.

(In reply to comment #4)
> I am probably suffering from this bug and reported it in bug #4913. I think it
> describes the problem better and is in the right Product/Component...

I disagree.  I don't believe there is anything wrong with xmodmap, as I am
changing the button mapping programmatically, using XChangePointerControl(). 
xmodmap is reporting the correct mapping, so the Xlib function call is
apparently succeeding, but the X server isn't paying attention to the mapping.

Oddly, another data point:  I upgraded my laptop (trackpoint mouse + synaptics
touchpad, two-button) to 7.0rc1 last night, and the button mappings work
perfectly; I can switch between right- and left-handed mouse just fine ('mouse'
driver).  It's just my desktop (Logitech USB optical 3-button wheel mouse) that
has the problem (again, 'mouse' driver).

Please attach config and log files.

Created attachment 3697 [details]
xorg.conf

Created attachment 3698 [details]
Xorg.1.log

Another data point: If I run Xnest on top of X (with the mouse button mappings
not working), and then change the mappings of the mouse inside Xnest, button
clicks behave as they should inside Xnest, but are still broken in normal X. 
Not sure if that's useful info or not.

Created attachment 3702 [details]
another xorg.conf

Created attachment 3703 [details]
Another log file.

So, are all of you guys using the nvidia driver? If so, does it also happen with
the nv driver?

No, I'm using the radeon driver. 

Created attachment 3718 [details]
Still Another Xorg.conf

Here's my xorg.conf. Log coming shortly..

Created attachment 3719 [details]
Still another logfile

Corresponding logfile.

Created attachment 3723 [details]
My xorg.conf

This is my xorg.conf. Normaly ZAxisMapping would be set to "6 7", but since
xmodmap isn't working I had to set it to "4 5" to use my scroll wheel. I'm
using an MX700 connected to my USB port, using the mouse driver.

Created attachment 3724 [details]
My log

Created attachment 3740 [details]
Still another logfile

Corresponding logfile.

That's strange, somehow it got reposted days later, with a different log... must
be something with firefox :/

The different log might help though, not sure if those errors are from synergy
or from the mixed up mouse buttons.

*** Bug 4913 has been marked as a duplicate of this bug. ***

Created attachment 3787 [details]
Morten's log.

Created attachment 3788 [details]
Morten's xorg.conf

I also have this problem.

Mouse: Logitech MX1000
xorg: 7.0.0_rc2
Dist.: Gentoo

I didn't have a problem before then I ran 6.8.99.15.

Can anyone confirm for me that xmodmap doesn't work even for the normal mouse
driver.  I don't think the problem is with evdev at all.

xmodmap -e "pointer = 1 3 2 4 5"

That should switch middle/right mouse buttons with the normal mouse button, but
it doesn't seem to.

As I mentioned before, xmodmap -pp shows that the mapping has actually changed.
 But the event codes don't get changed to match...

One more tidbit, xmodmap is actually doing something..

For example: xmodmap -e "pointer = 1 3 4 5 2"

Button     Result 
------------------
Left     =    1
Middle   =    4 
Right    =    5
Scroll U =    2
Scroll D =    3

Now, to me that looks like something is going
  button = map[button]
Then something else is doing the same thing at a later point.

xf86PostButtonEvent (hw/xfree86/common/xf86Xinput.c) is getting the correct
keycode, so something that occurs after that must be messing up the button code.

(In reply to comment #24)
> Can anyone confirm for me that xmodmap doesn't work even for the normal mouse
> driver.  I don't think the problem is with evdev at all.
> 

Look at the .conf files and you see at I am at least using the normal mouse
driver. I updated to rc2 and now my sixth and seventh buttons don't give
anything in xev.

Okay.. I have things working (seemingly) correctly here now.  Though I have no
idea if I've discovered the actual problem, or if I've just done some horrible
hack around something else.

Anyway, it seems that from within dix/events.c, XFree86Server isn't defined. 
This causes the code to execute this for both ButtonPress and ButtonRelease.
  xE->u.u.detail = butc->map[key];

Where key is assigned from xE->u.u.detail further back in the code.  This value
has already been translated from button code to X event code by
xf86PostButtonEvent, so it redoes the mapping and then sends off a borked code..

Hopefully this'll help someone fix this properly, I commented out the lines for
now as I know nothing about the build system and would've just #included
"xorg-config.h"..

Created attachment 3814 [details] [review]
Seems to fix the xmodmap issue in both "mouse" and "evdev"

Okay, this is what I came up with.  It's probably not the best way of doing
things, but it seems to work fine for me.

Perhaps it would be better to have XFree86Server defined in dix-config.h?

(In reply to comment #28)
> Created an attachment (id=3814) [edit]
> Seems to fix the xmodmap issue in both "mouse" and "evdev"
> 
> Okay, this is what I came up with.  It's probably not the best way of doing
> things, but it seems to work fine for me.
> 
> Perhaps it would be better to have XFree86Server defined in dix-config.h?

Applied this patch after ebuild xorg-server unpack and now xmodmap works again. 

#3814 should not be approved.  either we should just admit that we're upstream
and unconditionally build that into the DIX, or we should fix our DDXes to work
around the current DIX behaviour.

(In reply to comment #30)
> #3814 should not be approved.  either we should just admit that we're upstream
> and unconditionally build that into the DIX, or we should fix our DDXes to work
> around the current DIX behaviour.

Yes, I recall you mentioning this on irc.  3814 just matches the behaviour of
7.0 to that of the monolith.

Would the changes you mention to properly fix the issue be something that could
be done this late in the release cycle?  If not, *something* should be done to
address this issue before the release even if it isn't the right way.

(In reply to comment #31)
> Would the changes you mention to properly fix the issue be something that could
> be done this late in the release cycle?  If not, *something* should be done to
> address this issue before the release even if it isn't the right way.

I think you *have* to do something before the release. I for example would be
very pissed to try out the much talked modular xorg release and find out that
xmodmap is not working.

I'm shocked that you guys might release with this issue still pending... This
makes Xorg very unusable.

(In reply to comment #33)
> I'm shocked that you guys might release with this issue still pending... This
> makes Xorg very unusable.

we're not releasing as long as the list of open bugs blocking bug #1690 is
non-empty.  let's not go into hysterics here.

the issue is that we have to add XFree86Server to dix-config.h, and we're
currently testing that fix.  this should land before the week is out.

Comment on attachment 3814 [details] [review]
Seems to fix the xmodmap issue in both "mouse" and "evdev"

this fix is wrong

(In reply to comment #34)
> (In reply to comment #33)
> > I'm shocked that you guys might release with this issue still pending... This
> > makes Xorg very unusable.
> 
> we're not releasing as long as the list of open bugs blocking bug #1690 is
> non-empty.  let's not go into hysterics here.
> 
> the issue is that we have to add XFree86Server to dix-config.h, and we're
> currently testing that fix.  this should land before the week is out.

Ah, that's good to see.  I figured that'd be a better way of going about it, but
daniels mentioned on irc that it was also not correct. 

The problem with the swapped mousebuttons seems to be fixed in rc3. xmodmap
still reports 32 buttons when i only have 12 (logitech mx1000 with evdev driver).

verified that this is fixed in head as a result of kem's XFree86Server define
ninja hack.

Reassign to the new evdev maintainer.

I have the following situation:

I built the new evdev 1.1.0 driver against Xorg 7.0 on an ubuntu dapper system
and then dropped the resulting binary into a slackware-current system with Xorg 6.9.

The driver seems to work fine except that I have this xmodmap problem - none of
my button remapping attempts have any effect: "xmodmap -pp" shows the change but
xev shows the original mapping for events.