Bug 125922 - Menus don't work when I remap mouse buttons with xmodmap
Summary: Menus don't work when I remap mouse buttons with xmodmap
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-14 05:36 UTC by Joe Bayes
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-07-14 22:07:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of xev (20.00 KB, text/plain)
2004-07-08 17:50 UTC, Joe Bayes
no flags Details
.twmrc that causes menus to appear with non-remapped buttons (1015 bytes, text/plain)
2004-07-08 17:52 UTC, Joe Bayes
no flags Details
xorg.conf (3.09 KB, text/plain)
2004-07-12 17:03 UTC, Joe Bayes
no flags Details

Description Joe Bayes 2004-06-14 05:36:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040211 Firefox/0.8

Description of problem:
I have my window manager set up to display menus when I click on the
desktop. This worked fine from RH5.2 all the way through Fedora Core
1. It still works fine, as long as I use the default mouse button
configuration. However, if I do a:

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

then suddenly only the middle mouse button brings up a menu. The left
and right mouse buttons each briefly flash a menu, then display the
"left/right mouse button depressed" cursor as long as the left/right
button is held down. 

This occurs with both the twm and tvtwm window managers.

Version-Release number of selected component (if applicable):
xorg-x11-6.7.0-2

How reproducible:
Always

Steps to Reproduce:
1.Set up your window manager to display a menu when you push a mouse
button while the cursor is on the background of the desktop
2. xmodmap -e "pointer = 3 2 1 4 5"
3. Push the left or right mousebutton
    

Actual Results:  A menu flashed for a millisecond, then the cursor
changed to a little picture of a mouse with the left/right mousebutton
depressed 

Expected Results:  A menu should have popped up, and the cursor should
have changed to a little arrow pointing to the left. 

Additional info:

Comment 1 Kristian Høgsberg 2004-07-08 17:20:20 UTC
I could not reproduce this.

What does xev report for each of the three mouse buttons after
remapping them?  Can you reproduce it with an out-of-the box twm (i.e.
no custom configuration)?  How are other programs affected by the
button remapping?

Comment 2 Joe Bayes 2004-07-08 17:48:59 UTC
With an out-of-the-box twm (from xorg-x11-twm-6.7.0-5), an .xsession
that just says "exec twm", and the attached .twmrc, I'm still seeing
the aforementioned behavior. Attached is the output of xev (using the
out-of-the-box twm), where I remapped the buttons (xmodmap -e "pointer
= 3 2 1 4 5"), started xev, moved the pointer over the xev window,
then pressed and released the left, middle, and right buttons, then
killed xev. 

I noticed a problem with firefox, too: after remapping the buttons, if
I left-click on a tab, nothing happens, but if I right-click on a tab,
it both brings that tab to the foreground, and pops up the "new tab /
reload tab / reload all tabs / close tab" menu that normally pops up
when you right-click without remapping the buttons. 

Comment 3 Joe Bayes 2004-07-08 17:50:42 UTC
Created attachment 101726 [details]
output of xev

I remapped the buttons, started xev, moved the pointer over the xev window,
then pressed and released the left button, middle button, right button, then
killed xev.

Comment 4 Joe Bayes 2004-07-08 17:52:20 UTC
Created attachment 101727 [details]
.twmrc that causes menus to appear with non-remapped buttons

Comment 5 Joe Bayes 2004-07-08 17:58:38 UTC
Actually, you don't need my .twmrc to reproduce the behavior. I get
the same behavior with no .twmrc at all. 

Comment 6 Kristian Høgsberg 2004-07-12 15:29:44 UTC
That is weird, buttons 1 and 3 also generate 3 and 1 button events. 
What does your xorg.conf look like?  Do you have two mice set up? 
Maybe xmodmap only changes one of the mice...

Comment 7 Joe Bayes 2004-07-12 17:03:57 UTC
Created attachment 101819 [details]
xorg.conf

No, just one mouse, USB. I'm pretty sure I haven't touched xorg.conf since the
switch from XF86. It looks pretty kosher to me, though there are a few settings
in there that I'd be hard pressed to tell you exactly what they do.

Comment 8 Kristian Høgsberg 2004-07-12 17:29:46 UTC
You have two mouse devices configured in the xorg.conf file though.

Try to remove this line from the "ServerLayout" section:

	InputDevice    "DevInputMice" "AlwaysCore"

Did you edit xorg.conf by hand at some point, or was this generated by
a setup tool?

Comment 9 Mike A. Harris 2004-07-12 19:22:19 UTC
Prior to Fedora Core 2 with the 2.6.x kernel and unified
/dev/input/mice, our config tool configured the primary mouse
normally and added a secondary configuration for an AlwaysCore
USB mouse automatically, so if you plugged in a USB mouse, it
would just work without configuration.  This was an often
requested feature of laptop users who often plugged USB mice
into their lappys, as well as other users.

Now that it is no longer needed however, any pre-existing config
files with this extra configured mouse there, will still have
it after upgrade, as there is no way of knowing wether our
config tool put it there or the user did.  Automatically removing
it can potentially cause problems too, so we just leave it there.

It's safe to comment out though, as it can always be uncommented
if needed.

Comment 10 Joe Bayes 2004-07-12 20:40:14 UTC
That xorg.conf was generated by a setup tool. 

I commented out the extra section, and now button remapping works
normally. 

It seems there's still an issue with inappropriate behavior when there
are (for some reason or another) two mice configured, but I really
don't care about that. Thanks for the fix. 


Note You need to log in before you can comment on or make changes to this bug.