![[lang]](/images/eye.png)
middle mouse frustration |
2010-08-05
|
Sometimes I get annoyed about a simple problem and want to fix it the right way and have it fixed forever. Right now is such a time.
Middle click stopped working. Not sure when - maybe on my last update or reboot ?
I know what's wrong - xev tells me that clicking that middle mouse button tells me it thinks it's button 6 when it should probably think it's button 3.
Now, in the Old Days you'd tweak xorg.conf and add a funky option.
In the New Days Xorg is trying to be all about not needing xorg.conf and I support that vision. But, what is now the proper way to fix these issues ?
a) is this a bug, and should some hal file provide enough info for this mouse type to do the remapping ?
b) can evdev be configured on the fly and/or permanently to fix this mapping ?
c) which part of the stack is getting it wrong ?
If it helps, this particular machine is on Fedora 12, and the mouse is a simple Dell mouse with two buttons, a scroll wheel (the 'third button') and two up/down buttons.
Didn’t you hear? xorg.conf is cool again: http://who-t.blogspot.com/2010/01/new-configuration-world-order.html
What does xmodmap -pp print? Altough these days it’s probably xinput get-button-map “device name”; use xinput list to find the device name. You should be able to remap the buttons by using xinput set-button-map.
Comment by Marius Gedminas — 2010-08-05 @ 17:07
Thanks Marius! Here’s what I did:
xinput –list
That showed me:
⎜ ↳ Dell Premium USB Optical Mouse id=11 [slave pointer (2)]
Then
[thomas@level meetings]$ xinput get-button-map 11
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
and then
[thomas@level meetings]$ xinput set-button-map 11 1 6 3
[thomas@level meetings]$ xinput get-button-map 11
1 6 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Now it works…
Is xorg.conf the only way to make that persistent ? Is there a device config file somewhere that should get this stored based on the device string/id ?
Comment by Thomas — 2010-08-05 @ 17:51
[…] Thomas […]
Pingback by middle mouse frustrationthomas.apestaart.org | 9nd.pl — 2010-08-05 @ 17:09
I think I remapped my mouse with ~/.Xmodmap containing:
pointer = 1 8 3 4 5 7 6 2 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
This is local to the user though.
Comment by Christof — 2010-08-05 @ 19:32
Two separate issues here, the more interesting one (for me :) is why the middle button is suddenly button 6. Please check your device with evtest and see if the kernel forwards the button as BTN_MIDDLE still. If not, then there’s a kernel issue at hand. Logical button 6 (logical buttons are what xev reports) is usually interpreted as horizontal scroll left so it may be that that button is now interpreted as wheel – for whatever reason.
Next to check is the logical button mapping on the virtual core pointer and on the device itself. your device map as above looks fine, so it’s likely that the map on the virtual core pointer is messed up, xmodmap -pp should print this out for you. Given that your fix of mapping device button 2 to logical button 6 solved it, my guess is that on the VCP you have buttons 6 and 2 mapped the wrong way. How that happened – I don’t know though but it might be something in the session screwing up. Easily verified in a plain X server with nothing but xterm (and xev of course).
more info about button mapping is here http://who-t.blogspot.com/2009/06/button-mapping-in-x.html
(fwiw, middle button is button 2, right button is button 3)
https://fedoraproject.org/wiki/Input_device_configuration has the info on how to configure things, in the case of F12 that’s still HAL and fdi files.
Comment by Peter Hutterer — 2010-08-06 @ 01:51
Hi Peter,
so, after a fresh reboot, evtest reports the middle button as code 274/MiddleBtn, so that looks good.
xmodmap -pp indead shows that physical button 2 maps to button code 6.
The manual fix is being reset at times in my session, so that would support your theory that something in the session is doing it.
When starting a minimal xterm session with either root or my user, copy/paste works and xmodmap -pp shows the normal order.
Comment by Thomas — 2010-08-09 @ 17:46
Narrowing it down further – if I start an X session with xinit, everything is fine. If I launch gnome-session from that terminal, it stays fine – no remapping of middle button.
But if I start an X session with startx, it starts GNOME and middle button gets remapped.
I see this message in .xsession-errors that looks suspicious and points to something touching button mapping:
Warning: Only changing the first 20 of 18 buttons.
But google (neither normal nor code search) gives me a hint where this may be coming from. I thought gnome-settings-daemon at first, but it doesn’t have that string AFAICT…
Comment by Thomas — 2010-08-09 @ 18:49
That string is from xmodmap.
Comment by James — 2010-08-10 @ 18:51