Bugzilla – Bug 222505
Lefthanded mouse-option doesn't work during installation
Last modified: 2006-11-26 14:07:10 UTC
+++ This bug was initially created as a copy of Bug #166973 +++ During installation I accidentally right clicked on "Next". I was offered to revert the mouse buttons, which I accepted - but nothing changed, the mouse button setup was still "right handed". suse102b2:~ # hwinfo --mouse 27: PS/2 00.0: 10500 PS/2 Mouse [Created at input.159] UDI: /org/freedesktop/Hal/devices/platform_i8042_i8042_Aux_Port_logicaldev_input Unique ID: AH6Q.zl07e6mUyw1 Hardware Class: mouse Model: "ImExPS/2 Generic Explorer Mouse" Vendor: int 0x0210 Device: int 0x0025 "ImExPS/2 Generic Explorer Mouse" Device File: /dev/input/mice (/dev/input/mouse0) Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event2, /dev/input/by-path/platform-i8042-serio-0-event-mouse, /dev/input/by-path/platform-i8042-serio-0-mouse Device Number: char 13:63 (char 13:32) Driver Info #0: Buttons: 5 Wheels: 2 XFree86 Protocol: explorerps/2 GPM Protocol: exps2 Config Status: cfg=new, avail=yes, need=no, active=unknown Although it is stated, that this functionality should work it does not work for me. This is on another system, than the system used for bug #166973 .
Marcus, any clue? The code is unchanged from what I pasted into bug #166973 . If that xmodmap -e "pointer = 1 2 3" does not work, what else can I do?
I tested xmodmap -e "pointer = 3 2 1" # left hand xmodmap -e "pointer = 1 2 3" # right hand and it works for me. xmodmap said: Warning: Only changing the first 3 of 9 buttons. but that's only a warning. The call is right there is nothing you should change for the call. By the way I was just thinking on what is happening if the device is not handled by the mouse driver but by the synaptics driver does xmodmap work as well... Matthias please enlighten us ;) Thanks
That's right, it is only a warning. Huha, "pointer = 1 2 3" is the default ordering, you probably meant "pointer = 3 2 1". xmodmap is working on the server side, no driver involved. As soon xmodmap imposes a mouse button mapping, every event is mapped just before it's delivered to the client application. There's an *additional* "ButtonMapping" option per device, but that cannot be changed dynamically during runtime. Huha, you can check the mapping that's in place with 'xmodmap -pp'. Maybe it wasn't delivered correctly to the xserver? I just tested this in SL 10.2 b2+, no xmodmap line in y2log, and calling DISPLAY=:0 xmodmap -e 'pointer = 3 2 1' on the console *does* work.
yes it works for me as well
I found it. The semantics of the return value of QMessageBox::question() seems to have changed in recent libqt versions: It no longer returns the button position (the first button ("Yes") being button #0), it now returns an enum that corresponds to the button label (!). So the necessary check is --- YQUI_x11.cc (Revision 34249) +++ YQUI_x11.cc (Arbeitskopie) @@ -571,7 +571,7 @@ QMessageBox::No, QMessageBox::Cancel | QMessageBox::Escape ); - if ( button == 0 ) // Yes + if ( button == QMessageBox::Yes ) { const char * command = I wonder how many similar land mines we have all over the place due to that change. :-(
*** Bug 166973 has been marked as a duplicate of this bug. ***
Stefan, thanks for looking into this issue again. It something not easy to find as the code looks correct! Will this be part of upcoming 10.2 release candidate to be released on thursday. If so, it will be the 1st that I'll test :))
IT WORKS!!!! And I really like that. Thanks for fixing!