Mouse button click delayed

Bug #54191 reported by David Balažic
74
This bug affects 10 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Low
xserver-xorg-input-evdev (Ubuntu)
Fix Released
Low
Unassigned
xserver-xorg-input-mouse (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: xorg

If the Emulate3Buttons is on (which it is by default), mouse click are detected with a delay.

Example , try to enlarge a window :
 - point on the windows edge
 - press and hold left mouse button
 - move the mouse

Expected :
 - the window edge is dragged

Actual :
 - as the mouse click is delayed, the system detects the click when the pointer already moved off the window edge. Whatever is under the pointer in this momemt, will be clicked.

Bug known upstream : https://bugs.freedesktop.org/show_bug.cgi?id=1752

Workaround :
Set in xorg.conf in the InputDevice section for the mouse :
 Option "Emulate3Buttons" "false"

Revision history for this message
Simon Strandman (nejsimon) wrote :

I see no reason to enable emulate3buttons in xorg.conf. It's autodetected anyway and autodetection also enables a timeout on move for the 3 button emulation, eliminating this annoying problem.

Could someone take a look at this?

Revision history for this message
David Balažic (xerces8) wrote :

Ubuntu 7.04 "Feisty Fawn" - Alpha i386 (20070215)

bug still there ...

Changed in xorg-server:
status: Unknown → In Progress
Timo Aaltonen (tjaalton)
Changed in xorg:
status: Unconfirmed → Confirmed
Revision history for this message
David Balažic (xerces8) wrote :

still in Herd 5
(xorg 7.2-0ubuntu1)

Revision history for this message
David Balažic (xerces8) wrote :

still the same in Feisty beta

Changed in xserver-xorg-input-mouse:
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
David Balažic (xerces8) wrote :

Same in 7.10

Revision history for this message
MihailNaydenov (garfieldhq) wrote :

Same in 7.10, and is noticeable in all apps (Inkscape!!!) and games (quake 3), not just the window manager.
 It is very annoying!

Revision history for this message
Simon Strandman (nejsimon) wrote :

I guess this will be fixed as a result of having most devices autodetected in 8.10, unless ubuntu's scripts continues to add "Emulate3Buttons" to xorg.conf for no reason as it does today.

Revision history for this message
Paul Stone (launchpad-net-pdjs) wrote :

Setting Emulate3Buttons to false no longer fixes this problem in 8.10. I'm guessing this has something to do with evdev.

Revision history for this message
Simon Strandman (nejsimon) wrote :

@paul

Check your X log to see if evdev is being used. I haven't tried 8.10 myself yet.

Btw, fedora 10 uses evdev and has a similar problem. But the delay is only noticable for a few minutes after starting X, then the delay disappears. This might be a bug in evdev if ubuntu has the same problem.

Revision history for this message
Paul Stone (launchpad-net-pdjs) wrote :

Yes, evdev is being used:

$ grep evdev /var/log/Xorg.0.log
(II) LoadModule: "evdev"
(II) Loading /usr/lib/xorg/modules/input//evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"

I managed to work around this problem creating an .fdi file in /etc/hal/fdi/policy to set Emulate3Buttons to false for my mouse (similar to how this is done here: http://psung.blogspot.com/2008/09/scrolling-with-thinkpads-trackpoint-in.html)

However, this workaround shouldn't be necessary. xorg knows that my mouse has 3 buttons (the log states so), therefore it should automatically set Emulate3Buttons to false in this situation.

I don't know anything about HAL or the .fdi files (there appears to be no documentation anywhere). Is it possible to detect 3 mouse buttons and change the Emulate3Buttons setting purely through .fdi files? Or, are changes to code necessary - if so, which code would need to be changed?

Revision history for this message
Brad Clements (bkc) wrote :

I have two mouse-like devices on my system, a logitech mouse and a FingerWorks iGesture pad.

Both of these worked great under Ubuntu 7.04. This weekend I upgraded to 8.10, and now the iGesture pad has trouble with click and drag. I have tried adjusting drag threshold and so forth, but still I have to wait 1/2 second after 'clicking' with the iGesture pad before I can move it to make a selection.

This problem exists always, no matter how long the system has been running.

my Xorg.0.log file shows that evdev is being used, but it says it only detects 1 mouse button on the iGesture pad. I'm sorry I do not know what it used to detect under 7.04

I've attached my Xorg.0.log

look at this part:

(II) config/hal: Adding input device FingerWorks iGesture Pad USB
(**) FingerWorks iGesture Pad USB: always reports core events
(**) FingerWorks iGesture Pad USB: Device: "/dev/input/event5"
(II) FingerWorks iGesture Pad USB: Found x and y relative axes
(II) FingerWorks iGesture Pad USB: Found 1 mouse buttons
(II) FingerWorks iGesture Pad USB: Configuring as mouse
(II) XINPUT: Adding extended input device "FingerWorks iGesture Pad USB" (type: MOUSE)
(**) FingerWorks iGesture Pad USB: YAxisMapping: buttons 4 and 5
(**) FingerWorks iGesture Pad USB: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout
: 200

but hmm, xinput says:

"FingerWorks iGesture Pad USB" id=10 [XExtensionPointer]
 Num_buttons is 32
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
  Min_value is -1
  Max_value is -1
  Resolution is 1
 Axis 1 :
  Min_value is -1
  Max_value is -1
  Resolution is 1

(32 buttons, not 1)

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

The workaround for the click delay in Intrepid:

1. Execute
xinput list
and note your mouse name. For me, this is "Logitech USB-PS/2 Optical Mouse".

2. Create the file /etc/hal/fdi/policy/mouse-3button.fdi, containing (replace the mouse name with yours!):
<match key="info.product" string="Logitech USB-PS/2 Optical Mouse">
 <merge key="input.x11_options.Emulate3Buttons" type="string">false</merge>
</match>

3. Unplug your mouse and replug it. (This won't suffice if it's a PS/2 mouse i guess. In this case reboot.)

Revision history for this message
positivek (anonyhole) wrote :

Still in 8.10 with all the latest auto-updates.

I'm not sure what the internals are like in this, but it seems that such a "delay" means that (at least certain) mouse events are not being delivered accurately to the system or app. I think this is more serious than a simple UI annoyance as it introduces indeterminancy where there should be none (and probably did not exist prior to bug). That is, if the mouse button went down at one point, the app should not have to wait for the system to provide it with some sampled coordinates at an arbitrary later time.

Given that people have found a work around by disabling the Emulate3Buttons opoeution, does it mean that for those who do use or need Emulate3Buttons, this bug remains a problem?

See attached screenshot for the same behavior with the RMB on window title bars.

Description: Ubuntu 8.10
Codename: intrepid
Linux machname 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux
Gnome 2.24.1
compiz 1:0.7.8-0ubuntu4.1

Revision history for this message
Anthony Chianese (achianese) wrote :

Bug confirmed in the Jaunty final release. The same fix suggested by Jakob works again. My mouse is:

Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Looks like the bug is in the server, not the driver. Jaunty uses -evdev anyway.

affects: xserver-xorg-input-mouse (Ubuntu) → xorg-server (Ubuntu)
Revision history for this message
huug (dsjarw) wrote :

Bug confirmed in Karmic final release.
At least the fix suggested by Jakob still works.

Timo Aaltonen (tjaalton)
Changed in xserver-xorg-input-mouse (Ubuntu):
status: New → Invalid
Revision history for this message
Anthony Chianese (achianese) wrote :

This bug is still present for me in the release of Lucid, on a fresh install with updates installed as of May 3, 2010. Jakob's fix, which worked up to Karmic, no longer works in Lucid. Anyone know how to turn off 3 button emulation in Lucid?

Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi David,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 54191

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 54191 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/54191

Changed in xorg-server (Ubuntu):
status: Triaged → Incomplete
tags: added: needs-retested-on-lucid-by-june
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Still get this on Lucid,
   $ apt-cache policy xserver-xorg
   xserver-xorg:
     Installed: 1:7.5+5ubuntu1

The workaround in /etc/hal/fdi/policy/mouse-3button.fdi seems to be useless now. But:
The problem goes away once i click the middle mouse button (the scroll wheel)! Reboot or mouse unplug-replug bring the problem back.

Revision history for this message
Anthony Chianese (achianese) wrote :

Ditto.. it's the same for me. Clicking the middle button fixes it.

Revision history for this message
In , Jakob Unterwurzacher (jakobunt) wrote :

Left-click seems to be delayed, symptoms:
When i try to resize (or move) a window quickly, i miss the border (or titlebar). When i select text quickly, i miss the first few characters or even words. I have to "click hard" to make it do what i want.

The delay goes away once i have clicked the middle mouse button. It is then fixed until reboot or mouse unplug-replug.

This is Xorg 7.5 on Ubuntu 10.04 (Lucid) with a 3-Button mouse (left, right, scrollwhell).

Xorg.0.log of mouse replug: http://pastie.org/978307

Revision history for this message
In , Alan Coopersmith (alan-coopersmith) wrote :

Sounds like the default mode of having 3rd button emulation mode on "auto",
in which case it's disabled the first time an actual third (middle) button
is pressed, but until then it has to wait for the timeout on presses of
either button 1 (left) or button 2 (right) to see if you'll hit the other
one fast enough to trigger the button 3 emulation.

You should be able to "fix" by changing the configuration of mice that
actually have 3 buttons to disable 3rd button emulation, though I'm not
up-to-date on how to do that with udev/evdev.

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

log copied from pastie.org.

(II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/mouse2)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/event8)
(**) Logitech USB-PS/2 Optical Mouse: Applying InputClass "evdev pointer catchall"
(**) Logitech USB-PS/2 Optical Mouse: always reports core events
(**) Logitech USB-PS/2 Optical Mouse: Device: "/dev/input/event8"
(II) Logitech USB-PS/2 Optical Mouse: Found 3 mouse buttons
(II) Logitech USB-PS/2 Optical Mouse: Found scroll wheel(s)
(II) Logitech USB-PS/2 Optical Mouse: Found relative axes
(II) Logitech USB-PS/2 Optical Mouse: Found x and y relative axes
(II) Logitech USB-PS/2 Optical Mouse: Configuring as mouse
(**) Logitech USB-PS/2 Optical Mouse: YAxisMapping: buttons 4 and 5
(**) Logitech USB-PS/2 Optical Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Logitech USB-PS/2 Optical Mouse" (type: MOUSE)
(II) Logitech USB-PS/2 Optical Mouse: initialized for relative axes.

Please attach log files here directly so we don't have to rely on other websites keeping our information.

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

10.04 uses server 1.7, right?

Alan is right, the option you're looking for is Option "Emulate3Buttons" "off", see evdev(4) for more info. Configuration instructions are on https://fedoraproject.org/wiki/Input_device_configuration

in your fdi file, add an x11_options for the above option, example from the fedora wiki site:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
        <merge key="input.x11_options.TapButton1" type="string">1</merge>
    </match>
  </device>
</deviceinfo>

then restart HAL, make sure that lshal shows the option and then restart X.

Revision history for this message
In , Jakob Unterwurzacher (jakobunt) wrote :

Yes, i have xserver 1.7.6.

The fdi thingy does not work any longer (it used to work in Ubuntu 9.10 - xserver 1.6.4).
lshal gives
udi = '/org/freedesktop/Hal/devices/usb_device_46d_c00e_noserial_if0_logicaldev_input'
[...]
  input.product = 'Logitech USB-PS/2 Optical Mouse' (string)
  input.x11_options.Emulate3Buttons = 'false' (string)
  linux.device_file = '/dev/input/event8' (string)
[...]
which looks good but does not change anything. Hal is dead, no?

I am quite happy with the workaround of pressing the middle button to stop this. But only since i found out by accident!
When you search the web, there are quite a few people struggling with this (whoa, fedora user from 2004: http://forums.fedoraforum.org/showthread.php?t=15704 )

Shouldn't Emulate3Buttons be off from the start when i have 3 buttons already?

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

On Thu, May 27, 2010 at 02:07:23AM -0700, <email address hidden> wrote:
> --- Comment #4 from Jakob Unterwurzacher <email address hidden> 2010-05-27 02:07:23 PDT ---
> Yes, i have xserver 1.7.6.
>
> The fdi thingy does not work any longer (it used to work in Ubuntu 9.10 -
> xserver 1.6.4).
> lshal gives
> udi =
> '/org/freedesktop/Hal/devices/usb_device_46d_c00e_noserial_if0_logicaldev_input'
> [...]
> input.product = 'Logitech USB-PS/2 Optical Mouse' (string)
> input.x11_options.Emulate3Buttons = 'false' (string)
> linux.device_file = '/dev/input/event8' (string)
> [...]
> which looks good but does not change anything. Hal is dead, no?

uhm, yes. in 1.8, not in 1.7. AFAIK Ubuntu and Debian have some partial udev
backport, I don't quite know which bits apply and which ones dont. check
x11_input.rules or so in the udev files.

Julien?

> I am quite happy with the workaround of pressing the middle button to stop
> this. But only since i found out by accident!

it's in the man page :)

> When you search the web, there are quite a few people struggling with this
> (whoa, fedora user from 2004:
> http://forums.fedoraforum.org/showthread.php?t=15704 )
>
> Shouldn't Emulate3Buttons be off from the start when i have 3 buttons already?

well, that's the theory but IIRC for usb mice that field is always set,
curtesy of the PS/2 protocol not allowing any button detection.

it's one more of these things that should just have a checkbox in the GUI
instead of relying on unreliable autodetection...

Revision history for this message
In , Jakob Unterwurzacher (jakobunt) wrote :

On 27/05/10 11:51, <email address hidden> wrote:
>> I am quite happy with the workaround of pressing the middle button to stop
>> this. But only since i found out by accident!
>
> it's in the man page :)

Oh! That's true :)

>> Shouldn't Emulate3Buttons be off from the start when i have 3 buttons already?
>
> well, that's the theory but IIRC for usb mice that field is always set,
> curtesy of the PS/2 protocol not allowing any button detection.

What's this then? (from Xorg.0.log)

(II) Logitech USB-PS/2 Optical Mouse: Found 3 mouse buttons

Thanks,
Jakob

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

On Thu, May 27, 2010 at 03:10:41AM -0700, <email address hidden> wrote:
> > well, that's the theory but IIRC for usb mice that field is always set,
> > curtesy of the PS/2 protocol not allowing any button detection.
>
> What's this then? (from Xorg.0.log)
>
> (II) Logitech USB-PS/2 Optical Mouse: Found 3 mouse buttons

we're getting that data from the kernel though. the kernel sets those based
on the HID protocol descriptors but for older mice (though arguably those
don't matter much anymore) it's the PS/2 protocol. and that doesn't have a
detection mechanism so the kernel always sets those bits (link below, line 568).

so evdev will always think there's a 3+ button mouse because that's what the
kernel tells us. Now, the interesting thing would be what happens for
2-button USB mice - I don't actually know and I don't think I've got such a
device available to me.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/mouse/psmouse-base.c;h=979c50215282025fef1c7fa795a6bf20fedfcad4;hb=HEAD

Revision history for this message
In , Jakob Unterwurzacher (jakobunt) wrote :

Hm, damn.

USB mice are a lot smarter but I am not sure if the kernel takes advantage of that. It looks like this code was just setting every mouse to have 3 buttons:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/hid/usbhid/usbmouse.c#l180

 180 input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) |
 181 BIT_MASK(BTN_RIGHT) | BIT_MASK(BTN_MIDDLE);

Anyway, I think 2-button USB mice are so rare that they can be ignored. 2-button touchpads in laptops are common, but they are all PS2 as far as I have seen.

Could we default Emulate3Buttons to off for USB mice, then?

Revision history for this message
In , Julien Cristau (jcristau) wrote :

> --- Comment #5 from Peter Hutterer <email address hidden> 2010-05-27 02:51:23 PDT ---
> On Thu, May 27, 2010 at 02:07:23AM -0700, <email address hidden>
> wrote:
> > --- Comment #4 from Jakob Unterwurzacher <email address hidden> 2010-05-27 02:07:23 PDT ---
> > Yes, i have xserver 1.7.6.
> >
> > The fdi thingy does not work any longer (it used to work in Ubuntu 9.10 -
> > xserver 1.6.4).
> > lshal gives
> > udi =
> > '/org/freedesktop/Hal/devices/usb_device_46d_c00e_noserial_if0_logicaldev_input'
> > [...]
> > input.product = 'Logitech USB-PS/2 Optical Mouse' (string)
> > input.x11_options.Emulate3Buttons = 'false' (string)
> > linux.device_file = '/dev/input/event8' (string)
> > [...]
> > which looks good but does not change anything. Hal is dead, no?
>
> uhm, yes. in 1.8, not in 1.7. AFAIK Ubuntu and Debian have some partial udev
> backport, I don't quite know which bits apply and which ones dont. check
> x11_input.rules or so in the udev files.
>
> Julien?
>
on debian we've ended up backporting the whole udev+inputclass work from
1.8 (except for the NIDR api break). i'm not sure anymore what ubuntu
10.4 ended up shipping with, but i think something like the following in
xorg.conf should work:

Section "InputClass"
        Identifier "3 buttons"
        MatchIsPointer "on"
        MatchVendor "Logitech"
        Option "Emulate3Buttons" "off"
EndSection

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

commit 21a2ac818e75ef918d320ce1e88b6263e68e598d
Author: Peter Hutterer <email address hidden>
Date: Fri May 28 09:47:17 2010 +1000

    Disable middle mouse button emulation by default.

Changed in xorg-server:
status: In Progress → Unknown
Changed in xorg-server:
importance: Unknown → Low
status: Unknown → Fix Released
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for reporting this bug.

As per upstream bug, this issue fixed. Marking as such.

Changed in xorg-server (Ubuntu):
status: Incomplete → Fix Released
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

I think no Ubuntu package that fixes this has been released so far - setting to "Fix Commited"

Changed in xorg-server (Ubuntu):
status: Fix Released → Fix Committed
Changed in xorg-server:
importance: Low → Unknown
Revision history for this message
KennoVO (kenno-xs4all) wrote :

This bug was actually fixed as a side effect of the Ubuntu installer not generating an xorg.conf anymore and letting X autodetect the hardware on startup instead. X by default does not enable the Emulate3Buttons flag (I speculate having this flag enabled in the default xorg.conf file was an Ubuntu-specific "feature"), so the problem is gone. I believe this "fix" first occurred in Jaunty, and the first LTS version that has it is Lucid. However, I also believe the Ubuntu upgrader keeps the old xorg.conf file, so merely upgrading to a current version won't make this problem (or the Emulate3Buttons flag that causes it) go away - this can only be accomplished by editing xorg.conf or by installing the current version from scratch.

Revision history for this message
KennoVO (kenno-xs4all) wrote :

Oops sorry, forget my previous post. In Jaunty and Lucid, X will start up having the problem, but it will go away as soon as the middle button is pressed (I'm on Lucid and use the middle button so often I forgot the bug is still there).

Can anyone check whether the problem is still present in Maverick?

Revision history for this message
Brad Clements (bkc) wrote :

Hi KennoVO,

My xorg.conf has

    Option "Emulate3Buttons" "no"

still has the problem. I guess your 2nd post corrects the first?

a middle mouse click fixes this for me until X restarts

Revision history for this message
KennoVO (kenno-xs4all) wrote :

Yes, my second post corrects the first. The fact that you're getting the problem at all (I presume you're using Maverick?) pretty much confirms Jakob Unterwurzacher's post of 2010-09-14 for the case of Maverick, so we now know that "fix committed" is still the correct status. What I don't fully understand is by what mechanism the importance was changed from "Low" to "Unknown".

Also, that option in your xorg.conf should prevent the problem from occurring at all, no matter what X version you're using, so something doesn't make sense here. I think you *might* have used incorrect syntax in your xorg.conf, where the correct syntax would be (note not only the section but also "off" instead of "no"):

Section "InputClass"
        Option "Emulate3Buttons" "off"
EndSection

Revision history for this message
Brad Clements (bkc) wrote :

I am running lucid (10.04.1), not maverick.

The Emulate3Buttons option is in an InputDevice section, not InputClass. I do not know if that matters.

man page for xorg.conf says:

the following boolean option values are recognised as FALSE:

           0, off, false, no

So I think I'm ok using "no" instead of "off".

Cheers!

Revision history for this message
KennoVO (kenno-xs4all) wrote :

OK, can anyone check whether the problem is still present in Maverick?

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Yes, the problem is still present in Maverick.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

This is currently fixed in natty, but there's currently discussions going on whether the emulation should be re-enabled.

affects: xorg-server (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Changed in xserver-xorg-input-evdev (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote : Re: [Bug 54191] Re: Mouse button click delayed

Am 17.02.2011 14:23, schrieb Timo Aaltonen:
> This is currently fixed in natty, but there's currently discussions
> going on whether the emulation should be re-enabled.

ZOMG really? Where?

Changed in xorg-server:
importance: Unknown → Low
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Bug 710762, but it was decided to not change the default, instead let owners two-button usb mice to open new bugs so we can add model specific quirks for those.

Revision history for this message
Third Replicator (thirdreplicator) wrote :

It's amazing that in August 2015, this but filed in 2006 is still affecting people. I sincerely hope that I'm an outlier.

I'm using a 2-button built-in touchpad as my pointing device to my system 76 laptop. To fix this annoying click-and-miss-to-drag-resize-window-or-select-text issue I edited the following two files:

/usr/share/X11/xorg.conf.d/11-evdev-trackpoint.conf
/usr/share/X11/xorg.conf.d/11-evdev-quirks.conf

and set

Option "Emulate3Buttons" "false"

in both files. This fixed the problem in 14.04.1 Trusty Tahr for my 2-button laptop.

Here is my "xinput list"

xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Power Button id=8 [slave keyboard (3)]
    ↳ Sleep Button id=9 [slave keyboard (3)]
    ↳ BisonCam, NB Pro id=10 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)]

Ffs, people, it's 2015. Get your shit together. :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.