Bug 459018 - Regression: Xorg receives mouse button emulation events twice
Regression: Xorg receives mouse button emulation events twice
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: 122274
  Show dependency treegraph
 
Reported: 2008-08-13 15:40 EDT by W. Michael Petullo
Modified: 2009-12-18 01:18 EST (History)
8 users (show)

See Also:
Fixed In Version: 2.0.6-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:18:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X server log (108.13 KB, text/plain)
2008-08-13 15:40 EDT, W. Michael Petullo
no flags Details

  None (edit)
Description W. Michael Petullo 2008-08-13 15:40:50 EDT
Created attachment 314243 [details]
X server log

Description of problem:
I have been using the kernel's mouse button emulation feature on an Apple iBook through several versions of Fedora. I recently upgraded from Fedora 9 to Fedora 10 Alpha. After I upgraded, my X server no longer seemed to respond to the kernel's mouse button emulation settings.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.4.99.906-5.fc10.ppc

How reproducible:
Every time

Steps to Reproduce:
1. Configure the kernel to emulate right and middle clicks using keys:

/sbin/sysctl -w dev.mac_hid.mouse_button_emulation="1"
/sbin/sysctl -w dev.mac_hid.mouse_button2_keycode="87"
/sbin/sysctl -w dev.mac_hid.mouse_button3_keycode="96"

2. Press the key with keycode 87.
  
Actual results:
X treats key 87 as a keyboard key and does not respond to a mouse click event.

Expected results:
X should respond to a mouse click event when key 87 is pressed.

Additional info:
I am not certain that the problem is in X, but I thought this would be a good place to start.
Comment 1 Peter Hutterer 2008-08-14 00:46:53 EDT
Thanks for reporting that, I was completely unaware of this issue. The problem is caused by evdev grabbing the devices.

The mouse emulation is in-kernel. If the original device however is grabbed with EVIOCGRAB, it stops sending the event to the emulation device. evdev grabs all devices automatically to avoid duplicate events or conflicts with hotplugged devices.

The problem has been fixed upstream.

btw. it worked before because F9 didn't use evdev for keyboards, hence the grab wasn't issued.
Comment 2 Peter Hutterer 2008-08-17 21:11:20 EDT
just an update - the upstream fix has been reverted again due to a number of issues with it. 
See also http://lists.freedesktop.org/archives/xorg/2008-August/038032.html
Comment 3 Peter Hutterer 2008-08-29 04:05:40 EDT
actually, the link should be http://lists.freedesktop.org/archives/xorg/2008-August/037744.html
Comment 4 Peter Hutterer 2008-10-16 23:02:07 EDT
Fixed with xorg-x11-drv-evdev-2.0.6-3 and xorg-x11-server-1.5.2-5.

More info at http://who-t.blogspot.com/2008/10/new-keyboard-configuration-handling.html
Comment 5 Benjamin Jacobs 2008-10-23 21:32:14 EDT
The mac mouse button emulation works again but there is a new issue: the mouse events are interleaved with events from the key used to emulate the mouse button. A common consequence of this is that when you're right-clicking in a window (assuming the right button is emulated by the alt key), the wm's window menu is raised (the wm interprets alt+right-click).

This is what happend when I press fn+left_ctrl (middle buttton), release, press 'x', release, press fn+left_alt (right button), release, in xev.

KeyPress event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 557321, (39,72), root:(41,74),
    state 0x0, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

ButtonPress event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 557321, (39,72), root:(41,74),
    state 0x8, button 3, same_screen YES

KeyRelease event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 557451, (39,72), root:(41,74),
    state 0x408, keycode 108 (keysym 0xffea, Alt_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

ButtonRelease event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 557451, (39,72), root:(41,74),
    state 0x400, button 3, same_screen YES

KeyPress event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 558861, (39,72), root:(41,74),
    state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XmbLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False

KeyRelease event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 558951, (39,72), root:(41,74),
    state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False

KeyPress event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 559850, (39,72), root:(41,74),
    state 0x0, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

ButtonPress event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 559850, (39,72), root:(41,74),
    state 0x4, button 2, same_screen YES

KeyRelease event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 559970, (39,72), root:(41,74),
    state 0x204, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

ButtonRelease event, serial 23, synthetic NO, window 0x600001,
    root 0x66, subw 0x0, time 559970, (39,72), root:(41,74),
    state 0x200, button 2, same_screen YES

Expected result: no key events generated on mouse button emulation.

Sys info:
% rpm -qa |egrep '^xorg-x11-(server-Xorg|drv-evdev)'
xorg-x11-drv-evdev-2.0.7-3.fc10.ppc
xorg-x11-server-Xorg-1.5.2-8.fc10.ppc

My middle button is mapped to fn+left_ctrl and the right to fn+left_alt, I believe this is the default since I've no keycode settings in my sysctl.conf. Anyways, those are pretty handy settings, I find.
% sysctl -a |grep mac_hid
dev.mac_hid.mouse_button_emulation = 1
dev.mac_hid.mouse_button2_keycode = 97
dev.mac_hid.mouse_button3_keycode = 100
Comment 6 Peter Hutterer 2008-10-27 19:47:12 EDT
I'm shoving this one off to the kernel now, there isn't much we can do in X.

The in-kernel emulation of the mouse button discards the event instead of sending it through the standard keyboard device (drivers/char/keyboard.c). The evdev device however (drivers/input/evdev.c) still forwards the event to userspace.

So for X, which listens to all evdev devices, the same event pops up once as a keyboard event and once as a mouse button event on a different device. X however has no way of knowing that these two are associated.
Comment 7 Bug Zapper 2008-11-25 21:46:09 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Alex Markley 2008-12-21 14:50:01 EST
I also am having trouble with mac_hid in Fedora 10 on my MacBook.

I believe mac_hid is configured properly because evtest shows expected mouse events on key presses if I run the test while not in X. However, when in X (tested with xev) keypresses are seen as key codes, not mouse button presses.

This is somewhat crippling, as I don't always have the luxury of a USB mouse when using the laptop.

+1 to any efforts to get this resolved.
--Alex
Comment 9 Alex Markley 2009-01-23 17:55:21 EST
Some recent yum update appears to have solved my issue. My assigned right- and middle-click buttons appear to be generating right- and middle-click events as expected.

Thanks to everyone who worked on this!
--Alex
Comment 10 W. Michael Petullo 2009-01-25 17:24:13 EST
I just pulled all of the current Fedora 10 updates on my iBook. This problem still exists. If I press my mouse emulation keyboard key I still get both a mouse event and a keyboard event.
Comment 11 Alex Markley 2009-01-25 18:27:46 EST
I can confirm, using xev, that both mouse and keyboard events are being received by X applications in my current configuration.

I haven't experienced any related usability issues yet, but even if there are one or two, this behavior is far preferable to the previous issue I was experiencing. (Previously I could not use mac_hid keys to trigger mouse button presses in X at all.)
Comment 12 Sarab 2009-01-31 06:57:08 EST
I agree with you guys this problem sucks bad.
here is a solution that will work though:

Add to /etc/X11/xorg.conf the following flags. If you dont have xorg.conf just create one with these contents:

Section "ServerFlags"
       Option "AllowEmptyInput" "false"
       Option "AutoEnableDevices" "false"
EndSection

This will make the mouse functions work just as in fc9. I dont use full gnome or kde so dont know how it will work with that. I just run a simple fvwm or metacity wm with xterms, And things are working just as well as in fc9.


Hope this helps
Comment 13 Olivier Mehani 2009-07-15 11:07:48 EDT
I just reported the bug upstream on the Linux Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=13778
Comment 14 W. Michael Petullo 2009-09-06 15:27:39 EDT
I no longer have an iBook to test with.
Comment 15 Bug Zapper 2009-11-18 03:15:57 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-12-18 01:18:28 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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