Bug 1752

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.