The EmulateWheelTimeout feature which should emit a button click if the butten is only held for a short time shorter than the configured timeout does no longer work. The scrollwheel events are generated regardless of the time the wheel button is pressed. This broke with the checkin from rev 1.14 to 1.15. Thanks! Mathias Fröhlich
Please post the input device section of your xorg.conf and the exact current and expected behavior. Then I'll check what my cleanup broke. Please note that I'm on vacation for the next 3 weeks...
Created attachment 3960 [details] The xorg conf I use with revision 1.14 of mouse.c
If it helps, I'm also seeing this behaviour, using 6.9-1.cvs20051215.2.mdk2006.0.mde No matter what I do, if I want emulated wheel, I cannot get button 2 events. [It's a laptop, which makes the emulate3buttons unhelpful since you have to use both thumbs simultaneously!] Incidentally, I noticed that emulate3buttons is on by default, even if the relevant line in xorg.conf is omitted. Furthermore, specifically saying Option "Emulate3Buttons" "off" does NOT disable it. My input section is: Section "Input Device" Identifier "Mouse1" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/input/ps2mouse" #symlink to mouse0 by udev Option "Emulate3Buttons" "on" Option "Emulate3Timeout" "50" Option "EmulateWheel" "on" Option "EmulateWheelButton" "2" Option "EmulateWheelTimeout" "200" Option "YAxisMapping" "4 5" Option "XAxisMapping" "6 7" Option "ZAxisMapping" "10 11" EndSection
I tried the configuration in comment #3, increased the timeout to 500. I cannot get a Button 2 event, neither with or without the patch. For the quick test I tried SUSE 10.0 (which has no ButtonMapping) and the current alpha (which includes the patch). Maybe I should try 9.3 or baseline as well. So please tell me how am I supposed to get a button 2 event? I thought simply by clicking the wheel for a short enough time period. Option "Emulate3Buttons" "off" does work as intended for me. Yes, the default is "on" AFAIK.
In Xorg 6.9.0 (the release made last week), everything is now working fine. I have this configuration: Option "Emulate3Buttons" "on" Option "Emulate3Timeout" "50" Option "EmulateWheel" "on" Option "EmulateWheelButton" "2" Option "EmulateWheelTimeout" "0" which is a bit unusual. My behaviour is: Left button (1) = Left click Right button (3) = Right click Center button = middle click Bottom button (2) + mouse drag = scroll My trackpoint is laid out such that Center button is the "imaginary" button where you can press both (1) and (3) with the same finger. Bottom button is the physical button (2). See here for a picture of the mouse layout: http://www.richard.neill.hemscott.net/a22p-mdk9-1.html#x-tp But dis-regard the configuration stuff on that page - it is out of date.
Matthias, You see me somehow confused. Which patch are you refering to? Also I do not completely understand if Richard's problem is the same. But what I understand is that I do not have his 'imaginary' middle button, since my thinkpad is not layed out the way, you can press the left and the right mouse button with one finger. For the original problem of this bugid, just forget that imaginary buttons ... As an additional note on a private mail: That it worked the way described below was *not* a sideeffect of the old code. There was a patch of me which got incorporated somewhere between the 6.8.2 series and the current release. I will tell you how I expect it to work and how it worked prior and including rev 1.14. My configuration includes the "EmulateWheel" "on" option - see attachment above. I expect to get wheel events when I press the EmulateWheelButton mouse button long enough ( > EmulateWheelTimeout) and move the mouse. That is ok, and works. I expect to get a real original EmulateWheelButton press/release event if I press the middle mouse button and release it faster than EmulateWheelTimeout milliseconds. I do not get that with a handcompiled 6.9.rcwhatever. I traced the exact revision of the change which broke it in mouse.c. I als do not get that with the current fedora core devel xorg modular release. This even happened - with the cvs version < 1.14 that already contained that patch from me incorporated by a collegue of you - regardless the setting of Emulate3Buttons. So, I do *not* expect the Emulate3Buttons setting to influence the behavour of the way the EmulateWheelButton works. Greetings Mathias
This is just what I expected it should work like. However, I couldn't get it to work with the old SUSE version, so maybe we already had some code change that disabled this feature. I'll check the code today. (I was refering to my patch about ButtonMapping which got in very late in the release cycle)
Created attachment 4316 [details] [review] Fix for mouse wheel button pass-through This patch fixes the mouse wheel button pass-though I presumably broke with my mouse driver cleanup. I'm not exactly sure, as pass-through didn't work before for me either, but at least it does now :-P This patch has been created against the monolitic tree, as I don't have my build system up and running ATM, so please test, and if everything works as anticipated, I'll commit to the modularized tree.
For testing combinations of all features I used the following mouse section: Section "Input Device" Identifier "m" Driver "mouse" Option "Protocol" "explorerps/2" Option "Device" "/dev/input/mice" Option "Emulate3Buttons" "on" Option "Emulate3Timeout" "50" Option "EmulateWheel" "on" Option "EmulateWheelButton" "2" Option "EmulateWheelTimeout" "200" Option "YAxisMapping" "4 5" Option "XAxisMapping" "6 7" Option "ZAxisMapping" "8 9" Option "ButtonMapping" "3 2 1" EndSection Just for info. Please report if the above patch fixes your problems.
Matthias, Your attached patch brings that feature up again! Many thanks!!!!!! Greetings to Nuernberg Mathias
Commited to CVS. Waiting for discussion about 6.9.x/7.0.x submission.
this is not a server issue; removing it from the tracker. however this sounds significant enough to warrant bumping the mouse driver. matthias if you agree I can take care of that.
(In reply to comment #12) > this is not a server issue; removing it from the tracker. however this sounds Ah, right. Still have to get used to modular :-] Don't we need a mouse tracker? ;^) > significant enough to warrant bumping the mouse driver. matthias if you agree I > can take care of that. I'd love that. Thanks! Close when done.
Adam: Any news on the mouse driver issue? :)
Sorry for the bugspam, I didn't notice the recent activity. Thanks for working on this!
new mouse driver pushed, closing.
(In reply to comment #16) > new mouse driver pushed, closing. Hello, It's my first xorg's bugtrack contact, so... Hello everyone! :) I've got a question regarding the bug in 1.0.3 version of mouse input driver. (Repaired later in 1.0.4?) Is the fix going to be implemented in the 6.9.X line of xorg? Is there a patch against the 6.9.0 xorg version?... Best regards, Piotr Wierzchowski, piotr-spam+wie at gmail.com
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.