Basically, if I make a "click and drag" gesture (selection box, move a window, select a part of a text... ) with my mouse there's a very slight delay before it starts drawing the box. So far what I found : - It does not happen under win XP - I tried under KDE and GNOME, it is the same behaviour - I tried to tweak X11 parameters for my Logitech Trackman marble [ Option "Resolution", Option "SampleRate", Option "BaudRate" ], same behaviour - I switched to a standard USB mouse, same behaviour. When you click AND move the mouse it seems that the "mouse down" event is taken into account at the next mouse point instead of current one or it has been bufferize in some way. For every "click and move" gesture it is annoying : you put your pointer on an area, click and move quickly and the system click outside the area (button, window, widget ...) Each time you click you have to press "hard" = "with a slight pause" the left button in order to be sure to have a correct GUI response. I continued to investigate... Nothing changed when : - I tried a quick sampling mouse patch - I switched from 64bits to 32bits kernel. - I switched for an usb mouse - I tried on another completely different computer with a totally different mouse - A friend saw the defect and reproduced it on Cygwin (!) with Xfree86 So it appears that it is not a problem of linux or mouse related pb but definitively an X problem.
Yes, this is definitely an X problem. Attaching strace to the X server while clicking in xev gives this: read(7, "\t\0\0\0", 64) = 4 read(7, ")\3\365\0", 64) = 4 read(7, ")\2\350\0", 64) = 4 read(7, ")\1\346\0", 64) = 4 The first read() is a button click, the three next read()s are motion events. But xev reported: MotionNotify event, serial 27, synthetic NO, window 0x2e00001, root 0x49, subw 0x0, time 36219508, (86,51), root:(1257,332), state 0x10, is_hint 0, same_screen YES ButtonPress event, serial 27, synthetic NO, window 0x2e00001, root 0x49, subw 0x0, time 36219510, (86,51), root:(1257,332), state 0x10, button 1, same_screen YES MotionNotify event, serial 27, synthetic NO, window 0x2e00001, root 0x49, subw 0x0, time 36219532, (90,99), root:(1261,380), state 0x110, is_hint 0, same_screen YES MotionNotify event, serial 27, synthetic NO, window 0x2e00001, root 0x49, subw 0x0, time 36219548, (92,151), root:(1263,432), state 0x110, is_hint 0, same_screen YES
It looks like this happens when Emulate3Buttons is on. Apparently when the Emulate3Buttons code sees a button press, it doesn't immediately post the event; instead it waits for a brief while to see if the user also presses the second button. In that period of time, motion events are posted as normal, causing the delay. So an immediate fix for users is to just turn off Emulate3Buttons, but I'd say that what the code does currently is probably wrong. Events should not be reordered; instead the motion events should be deferred until after the timeout.
Yes, I confirm when I put Options "Emulate3Buttons" "no" in xorg.conf I cannot reproduce the bug. It should not be on by default when your mouse is declared with 5 buttons ! Especially if it is buggy ... Thanks for the diagnosis.
It is fixable, it should not freeze the moves until it receives Imagine this series of events : left_click, move1, move2, [timeout for listening to the other button], move3, move4 Current behavior : move1, move2, left_click, move3, move4 Correct behavior : move1, move2, left_click, -move1, -move2, move3, move4 Because move1 & 2 has to be send right away for user responsivemeness. -move1 = the move that cancel move1
I've tested again, SuSE 9.2, and find that I was always running with Emulate3Buttons off... In SaX2, the bug is very noticable (I assume it's a pure X application), Just grab one of the windows and it's there. It's like having to be a little careful (hard-clicking is quite descriptive) when wanting to drag something, an unneeded annoyance. And, for the record, Mac OS X has this detail done right. I tested for it and found that I get the window edge correctly each and every time.
(In reply to comment #1) > Yes, this is definitely an X problem. Attaching strace to the X server while > clicking in xev gives this: > The first read() is a button click, the three next read()s are motion events. > But xev reported: > > MotionNotify event, serial 27, synthetic NO, window 0x2e00001, > root 0x49, subw 0x0, time 36219508, (86,51), root:(1257,332), > state 0x10, is_hint 0, same_screen YES > > ButtonPress event, serial 27, synthetic NO, window 0x2e00001, > root 0x49, subw 0x0, time 36219510, (86,51), root:(1257,332), > state 0x10, button 1, same_screen YES This looks right. An extra Motion event before the click comes. Fits with the behaviour I'm experiencing.
On my Athlon 1800 XP with ATI 9200 gfx card, this is easy to reproduce. Position the mouse pointer in a window titlebar. At the same time, click the mouse button and start moving the mouse quickly up from the window. This should 'grab' the title bar, but usually the click is interpreted as being outside the window instead.
Does disabling silken mouse make a difference?
(In reply to comment #8) > Does disabling silken mouse make a difference? What is 'silken' mouse??
This is a lot easier to reproduce if you increase the Emulate3Timeout value to something like 2 seconds. (2000 as it is counted in milliseconds)
updated summary: 3-button emulation involves a delay, which is appreciable. we should be turning it off if we can tell that the mouse has more than 2 buttons.
(In reply to comment #11) > updated summary: 3-button emulation involves a delay, which is appreciable. we > should be turning it off if we can tell that the mouse has more than 2 buttons. I believe we're already doing this, it's not a complete fix for this problem. Emulate3Buttons is _off_ on my system and always was. I'm *still* experiencing this bug. Presumably a hardcore X user would be more used to it - when I switch between Windows (or Mac OSX) and any of the free XWindows, I notice this annoyance. Actually the subject line of this bug is misleading, I believe.
There should be a way to force it on even if you detect more than 2 buttons, since hotplugging may change the number of buttons, and OS'es that present multiple mice via a single device may have a 2-button laptop internal device and 3-button external mouse coming in the same device stream.
Comment #4 is wrong. It says : left_click, move1, move2, [timeout for listening to the other button], move3, move4 Current behavior : move1, move2,[timeout], left_click, move3, move4 Correct behavior : move1, move2, left_click, -move1, -move2, move3, move4 ---- But the real correct behavior would be : move1, move2,[timeout], -move1, -move2, left_click, move3, move4 (otherwise the click is at the wrong screen position)
(In reply to comment #12) > I believe we're already doing this, it's not a complete fix for this problem. > Emulate3Buttons is _off_ on my system and always was. I'm *still* experiencing > this bug. Presumably a hardcore X user would be more used to it - when I switch > between Windows (or Mac OSX) and any of the free XWindows, I notice this annoyance. Emulate3Buttons is off by default on my machine too. But I still have the delay unless I add Emulate3Buttons "false" to the config file.
(In reply to comment #15) > Emulate3Buttons is off by default on my machine too. But I still have the delay > unless I add Emulate3Buttons "false" to the config file. "off" also works :) When adding this line to xorg.conf, I confirm that clicking edges while moving the mouse works reliably. Everytime I grab something, I actually get it. Good Thing. Would Emulate3Buttons be _on_ by default if no line is present in the xorg.conf file?
This is from my Xorg.0.log file when Emulate3Buttons is commented out in xorg.conf: (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 And then later down also: (II) 3rd Button detected: disabling emulate3Button So it's definitly off by default. But then I have the delay anyway. So it's nessecary to explicitly tell xorg to turn it off to have a responsive mouse. I think a good workaround for this bug would be to always have Emulate3Buttons off by default in xorg.conf file unless the users choose to turn it on.
(In reply to comment #14) > Would Emulate3Buttons be _on_ by default if no line is present in the xorg.conf > file? Yes. See http://lists.freedesktop.org/archives/xorg/2005-November/011137.html.
(In reply to comment #16) > (In reply to comment #14) > > Would Emulate3Buttons be _on_ by default if no line is present in the xorg.conf > > file? > > Yes. See http://lists.freedesktop.org/archives/xorg/2005-November/011137.html. Interesting. A tad more complex than I expected, but fully explains what's happening. Since 2 button mice are quite a minority these days (wheel mice are also 3 button mice), the second suggested fix (eliminating E3SOFT altogether) looks like the one right solution. It looks like a kludge anyway. Any users with real 2 button mice still have the option to enable Emulate3Buttons. Good to see it properly analyzed, hopefully soon fixed.
While two button devices you hold in your hand are becoming rare, two button input devices using the mouse driver are still common thanks to laptops with two button built-in trackpads/joysticks. (Of course, in that world, auto-detection of Emulate3Buttons seems even more broken, since it would work as long as you used the trackpad, but if you plug in a real mouse for a bit, it would then be disabled and when you unplug the real mouse, your trackpad would thus be unable to generate the third mouse button.)
Created attachment 3804 [details] [review] make Emulate3Buttons off by default when Xorg -configure is run, and idsarm handlers when we detect middle button.
Attached please find a candidate patch. After talking with Kevin Martin, we decided to leave the "auto" behaviour the way it is, but to remove the handlers when we detect a middle button, and to default to "off". Of course that default will only kick in if you actually rerun Xorg -configure.
Created attachment 3806 [details] [review] New patch to remove extraneous setting of emulate3Buttons in SetMouseProto()
I see several prolems with the patch: Setting emulate3Buttons to on in SetMouseProto() in the 'soft' case is there so that when changing the mouse the emulation is turned back on - in case the mouse is a 2 button mouse. This code should not cause problems in normal operations as SetMouseProto() should not be called unless something happens with the mouse or on a vt switch. The same is true for removing the BlockAndWakeupHandler(). If this is gone reenabling the emulation isn't possible. The 'soft' emulation is on by default so that the unexperienced user gets emulation in case he needs it. It will be disabled as soon as he presses the middle button. In this case the 'delay' problem that has been reported would also be gone. Therefore I don't see why the handler should be removed. People who see this delay problem during their session probably never use their middle button. I agree that there is a problem on laptops when somebody uses an external mouse. If this mouse is an USB mouse the problem can be fixed when viewing the internal and external mice as separate devices as the state of emulation is private to the device. If the external mouse is a PS/2 mouse one will have to live with this as the two mice are 'combined' together in the hardware. I also agree that the 'reordering' that happens is not good. Fixing this would require to record mouse events when a timeout is pending and replay them when either seeing the other button or when the timeout has occurred. I don't like to change the default as it will provide a disadvantage to people with laptops. Since the presence of a middle button cannot be detected a configuration would not know how to set this option.
Created attachment 3885 [details] [review] Alternative solution This patch lets the button timer timeout immediately when it sees a motion event. This happens before the motion events are posted thus the order is correct. Please note that this behavior is only true for soft emulation as it makes handling of the 3 button emulation slightly more awkward. But I think I can live with this on my laptop. (if not someone will have to bribe me with one of these tiny laptop usb mice ;-) )
(In reply to comment #22) > I see several prolems with the patch: > Setting emulate3Buttons to on in SetMouseProto() in the 'soft' case is there so > that when changing the mouse the emulation is turned back on - in case the mouse > is a 2 button mouse. This code should not cause problems in normal operations as > SetMouseProto() should not be called unless something happens with the mouse or > on a vt switch. One question: How do you "turn it back on" once its been disabled? If it is possible to detect when it is turned back on, when it was previous off, then that would be an appropriate place to re-install the handlers. > The same is true for removing the BlockAndWakeupHandler(). If this is gone > reenabling the emulation isn't possible. See above. > The 'soft' emulation is on by default so that the unexperienced user gets > emulation in case he needs it. It will be disabled as soon as he presses the > middle button. In this case the 'delay' problem that has been reported would In discussions on IRC, it was deemed that the number of people with 2 button mice pales into insigificance versus those with three. I'm all for helping the unexperienced user, but not if it is at the expense of the majority of users. Thus, I think the default for E3B should be off, and if a user has a 2 button mouse they should enable it. It's really not that hard to comment out one line in the config file, even for inexperienced users. > People who see this delay problem during their session probably never use their > middle button. Well thats the cruz of the problem. I *very* rarely use my middle mouse button, but I am paying the "penalty" of E3B detection becuase of it. Your proposed alternate solution makes the problem less aggregious, to be sure, but there is still a more complicated code path followed by the majority of users if they don't press their middle mouse button.
(In reply to comment #23) > Created an attachment (id=3885) [edit] > Alternative solution > > This patch lets the button timer timeout immediately when it sees a motion > event. This happens before the motion events are posted thus the order is > correct. Please note that this behavior is only true for soft emulation as it > makes handling of the 3 button emulation slightly more awkward. > But I think I can live with this on my laptop. (if not someone will have to > bribe me with one of these tiny laptop usb mice ;-) ) There is an important part of my patch that is missing. It is vital that E3BSOFT is set immediately in MouseCommonOptions() and not left solely to SetMouseProto(). SetMouseProto() is not called for an OS that defines its own MouseProc. Thus, on those platforms, it will be impossible to ever disable E3B, even when a middle button is pressed.
Kean, I don't understand. We do set emulate3ButonSoft in CommonOptions. What you add is a line setting emulate3buttons = TRUE. Without this line you would never get a 3 button emulation unless explicitely set in the config file (ie the soft version) if you don't call SetMouseProto(). However you talk about not being able to disable it ever. Disabling is done in MouseDoPostEvent(). This should also be called on a system providing its own mouseProc, shoudln't it? I see where adding this one line would hurt anything. So yes, the chunk for line 399 would be OK.
Created attachment 3888 [details] [review] Updated patch Kean, does this do the trick for you?
I'm wondering why we're trying to be so clever and have to automatically turn things on/off depending on what hardware the user appears to have. If I was to apply the KISS principle :), I would set E3B off by default, and then require the user to turn it on manually, if he needs so. Remove the detection and automatic change of setting. Less complexity, smaller code, no penalty to the average 3 button user. Would it hurt anyone to simplify things like that? If I'm missing some obvious reason for the complexity, please tell me and I'll quiet up :)
The KISS principle doesn't apply here. Otherwise we can apply it to everything and create a real simple model world which does not map on the real world around us. The real world sees an increasing number of laptops deployed. Most of them don't have a middle button. You want to add this feature without the user having to change a configuration. I briefly thought about turning the emulation off when a wheel event is seen. Unfortunately a lot of laptops have some sort of wheel action but still not middle button. I was thinking if I should add a gesture to turn the emulation on. I don't have an idea how, though. With the timeout-on-drag feature most annoyances should be gone now.
(In reply to comment #27) > Created an attachment (id=3888) [edit] > Updated patch > > Kean, does this do the trick for you? Since I never actually had the problem and was only trying to fix it, I'd say yes :) The key is setting E3BSOFT right up top, plus your change to adjust for motion should cover all bases. At the very least, its an improvement.
Created attachment 4062 [details] [review] Timeout on move Egbert, unfortunately, your updated patch doesn't quite work right. The problem is that the third part of the patch effectively says to not handle emulate3buttons if you simulaneously move the mouse. This seems to mess up the state machine (but I haven't had time to dig into it further). It manifests itself as button 1 or 3 getting stuck in the down position until you press it and release it again. If you remove the third part of the patch, then the code appears to work correctly. I'm trying to understand the logic behind the third part of your patch. Could you explain more or see if you agree that removing it will work correctly (see attached patch)? Also, at this point of the release cycle, I'm tempted to hold off changing this code until after 7.0.
Comment on attachment 3806 [details] [review] New patch to remove extraneous setting of emulate3Buttons in SetMouseProto() As noted by Egbert, we don't want to use this method. See latest comment in bug for more info on the latest patch attempt.
(In reply to comment #32) > (From update of attachment 3806 [details] [review] [edit]) > As noted by Egbert, we don't want to use this method. See latest comment in > bug for more info on the latest patch attempt. I must be honest, I never did really agree with Egbert. I understand the desire to support laptops, and thats a noble goal, but X is primarily a workstation thing, and although a modern laptop is almost a workstation, its not quite there. On non-laptop machines, which still accounts for the vast majority of machines, and where you almost certainly have 3 buttons on your mouse, it seems as if the price we are paying to support laptops with no configuration assistance is too high. Not only in these comments here but also in IRC< when this bug was discussed at length, everyone agred that my original patch was the way to go. Even Kevin, but he wanted to wait for Egbert to weight in. Thus far Egbert is the only one against the idea of making E3B off by default and having a configuration option turn it on. Of course his opinion is highly respected, but I would like to try and change his mind. Part of the problem is we cannot reliably detect the number of mouse buttons. Thus, mice dont fall neatly into the auto-configuration strategy. The notion of actually waiting for an event *way* past the point of initialization to try to determine hardware is, IMHO, intrinsically flawed. I offer as evidence the sheer complexity of the code and the amount of discussion and confusion this bug has caused. Egbert, is it *really* that bad that if you want to emulate 3 buttons that you have to edit the config file to do so? There are so many other things you need to edit the file for, why is there so much resistance to this one?
Having had time to think about this further, I think "auto" behavior should be the default and "Xorg -configure" should leave "auto" as the default. My reasons are as follows: Editing a configuration file is very easy for all of us here; however, for the average consumer, it's very difficult. Anything that we can do to make it easier for the average consumer while not significantly affecting the experienced user is worth doing in my book. I think that the latest patch accomplishes both by leaving the "auto" behavior as the default and solving the originally reported problem. The way it solves the originally reported problem is by posting the button event as soon as any mouse motion is detected in the "auto" case. Previously, you'd have to wait until the timeout occurred and several mouse motion events could have been delivered during that span of time. With the patch, any motion will cause the button event to be posted both immediately and before the motion event is posted. > Not only in these comments here but also in IRC< when this bug was discussed at > length, everyone agred that my original patch was the way to go. Even Kevin, but > he wanted to wait for Egbert to weight in. Actually, what I agreed to was that "auto" behavior should remain the default unless you have an explicit "Emulate3Buttons" option in your xorg.conf file. However, I did not take hotplug into account. So, I agree with Egbert that your patch went a bit too far. The latest patch solves this problem as well as the originally reported problem.
Kevin, indeed the state machine works differently than I remembered. We *always* have to pass thru it - even when we have timeout'ed before. Therefore your solution is correct. Kean: > Egbert, is it *really* that bad that if you want to emulate 3 buttons that you > have to edit the config file to do so? There are so many other things you need > to edit the file for, why is there so much resistance to this one? Yes, from a support point of view it is. The present sceme eliminates the need for the user to wander thru various menues of a config utility and find an option that he barely knows. Also please remember that for a change in the config file to take effect you would have to end your currently running session before you can change this option. In the future we are looking into a lot more 'hotplug' solutions that will add hardware at a point way past the initial detection and initialization. Currently the only argument against this solution is really the complexity of the code. However we are frequently going thru a great deal of complextiy to make live for the user easier. The problem about IRC discussions is that they leave very few traces and things are mostly discussed among the people who happen to be present at a given time.
The new patch works great. With it having no emulate3buttons setting is just as responsive as having emulate3buttons="false". But the annying delay still comes back with emulate3buttons="true". Shouldn't this timeout on move always be used, even if you explicitly turn emulate3buttons on?
(In reply to comment #36) > The new patch works great. With it having no emulate3buttons setting is just as > responsive as having emulate3buttons="false". Thanks for testing it! I've checked in the fix for 6.9/7.0. > But the annying delay still comes > back with emulate3buttons="true". Shouldn't this timeout on move always be used, > even if you explicitly turn emulate3buttons on? This is something to consider for 7.1 since we are very close to the 6.9/7.0 release now. I think it would be good to have a config file option to allow the behavior to be selectable (either traditional delay or new timeout on movement). Also, we can discuss which one should be the default. So that we can continue to track this issue, I'm going to move it over to block bug 5041 (the 7.1 release blocker).
Yes, I've also considered to use the timeout on moves all the time with 3 button emulation. I've convinced myself how bad it is by increasing the timeout value.
(In reply to comment #38) > Yes, I've also considered to use the timeout on moves all the time with 3 button > emulation. I've convinced myself how bad it is by increasing the timeout value. So is there any motion on this? 7.1 approacheth.
(In reply to comment #39) > (In reply to comment #38) > > Yes, I've also considered to use the timeout on moves all the time with 3 button > > emulation. I've convinced myself how bad it is by increasing the timeout value. > > So is there any motion on this? 7.1 approacheth. Nine days and no reply means this clearly isn't important enough to block 7.1. Moving out.
I don't think there is any urgency here. The major annouance has been fixed with the timeout on moves when softly emulating the 3rd button.
I just tried v7.1.1 (as shipped on Ubuntu Edgy Knot 2 prelease CD *) and it is not fixed as I see it. The click delay is still there. xorg.conf settings : Option "Emulate3Buttons" "true" Option "Emulate3Timeout" "300" * - http://www.ubuntu.com/testing (if they still dont list Knot 2, just go to the Knot 1 download page, linked inthe announcement, and replace knot-1 in URL with knot-2)
I just recently stumbled on this and I had to read the comments here to find the explanation. X decides that even if I have Emulate3Buttons on it should disable the emulation once I press the wheel. It shouldn't. I strongly prefer not to use the wheel but the 1-2 button simultaneous click. I've been using this since I've started using X back in the days and its wired in my muscle memory. The wheel certainly has its use , but using it as a button has always been a problem for me.
marginal usecase: not blocking 7.2 for it.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
The click delay bug is still there in v 7.2
As there has been no activity for almost a year, and this bug is over three years old: Please don't forget this issue. It's affecting each and every Ubuntu user (Ubuntu Bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/54191 , which is assigned to _this_ upstream-bug).
Please note that this is still (again?) an issue in Xorg 7.4 (Ubuntu Intrepid). (In reply to comment #43) > I don't think there is any urgency here. > The major annouance has been fixed with the timeout on moves when softly > emulating the 3rd button. I don't know what was fixed - but the click delay, that makes you miss the window border when trying to resize a window, wasn't. I experience it *right now* on Ubuntu Intrepid (Xorg 7.4) with a 3-button USB mouse. What makes things worse is that old workaround Option "Emulate3Buttons" "false" doesn't seem to help anymore.
Sorry for the spam, but i found the new workaround, and i guess it may be helpful for you to know it. The workaround is still to disable Emulate3Buttons, but this time in /etc/hal/fdi/policy/mouse-3button.fdi . This fixes the delay completely. Details: http://ubuntuforums.org/showpost.php?p=6450743&postcount=5
Fixed now. commit 21a2ac818e75ef918d320ce1e88b6263e68e598d/ Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri May 28 09:47:17 2010 +1000 Disable middle mouse button emulation by default.
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.