I've installed modular X.org and switched to the evdev driver (Previously used the gentoo patch). Now the mouse buttons 2 and 3 are switched. It doesn't help to switch them with xmodmap or commenting out the "map[3/2] = 2/3" lines in evdev.c. I'm currently running Linux Kernel 2.6.13-rc6 on an AMD64 machine.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.