Middle mouse (wheel-click) button stopped working after upgrade to 16.04

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1581088/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Identified "linux" as the package after reading https://wiki.ubuntu.com/Bugs/FindRightPackage.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1581088

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.6 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc7-wily/

Tested with 4.6.0-040600rc7-generic from the archive mentioned above.

No success: xev still only shows buttons 1 and 3, but not button 2 (the scroll-wheel (buttons 4, 5) is registered too).

I experience exactly the same bug after daily upgrade of my 16.04 this morning: my mouse middle button no longer works (LOGITECH M557, Bluetooth, running 4.4.0-22-generic #40-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux).

xev shows the left and right buttons, but no event for middle/scroll wheel button.

Middle button on my M557 BT mouse resumed normal expected functionality, no specific action on my part, even though I could swear it didn't work on firing up the PC this morning. Apt log shows no software updates during morning. Beats me.

Lucky you, Pascal. Still not working here and it's driving me crazy. :(

Any news on where this might originate from, anyone?

I don't want to hijack a bug report (see my test at #22), but I strongly believe that this should not be offloaded to "a buggy BIOS".

I am experiencing the same behaviour on quite a different system, it is (obviously?) a regression since it worked (on the same system) under 15.10 and previous versions. I agree that my BIOS is rather old but the notion "well, bad luck, you will have to buy a new motherboard to be able to use your mouse like before" gives me the creeps. I hope I am overreacting :-)
For completeness, my BIOS-Version
BIOS Information
 Vendor: American Megatrends Inc.
 Version: 3603
 Release Date: 05/10/2012
 BIOS Revision: 4.6

GIET85WW (2.35 )
03/10/2016

Hi,

as shown above, I performed the BIOS updated. This indeed gave some improvement, since the middle click now occasionally works. I would guess that with the chance of 1/2-1/8 the click works. In the remaining cases it does not.

I produced the following xev output by clicking 10 times:

EnterNotify event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 712557, (82,97), root:(119,198),
    mode NotifyUngrab, detail NotifyNonlinear, same_screen YES,
    focus YES, state 16

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 717995, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 718119, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 720032, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 720118, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 722695, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 722794, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 723863, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 723894, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 725879, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 725955, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

ButtonPress event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 727717, (82,97), root:(119,198),
    state 0x10, button 2, same_screen YES

ButtonRelease event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 727800, (82,97), root:(119,198),
    state 0x210, button 2, same_screen YES

LeaveNotify event, serial 25, synthetic NO, window 0x3c00001,
    root 0xd6, subw 0x0, time 731652, (82,97), root:(119,198),
    mode NotifyGrab, detail NotifyNonlinear, same_screen YES,
    focus YES, state 24

Please let me know if I can provide additional info.

Regards
Toby

tobyS, could you please test the latest mainline kernel (4.7-rc2) and advise to the results?

Hi Christopher,

done and done, thank you for caring :-)

kind regards

guntbert
> Guntbert Reiter, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
> ubuntu-bug linux
>
> Please feel free to subscribe me to it.
>
> For more on why this is helpful, please see
> https://wiki.ubuntu.com/ReportingBugs.
>

--
Guntbert Reiter
<email address hidden>

I just tried Kernel version

Linux tango-x240 4.7.0-040700rc2-generic #201606051831 SMP Sun Jun 5 22:33:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

as advised. The issue persists in the same way as with my original kernel (middle click works occasionally).

tobyS, to clarify, which prior Ubuntu release was this last working in?

I upgraded from 15.10 to 16.04.

tobyS, the next step is to fully commit bisect from kernel 4.2 to 4.4 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

After the offending commit (not kernel version) has been identified, then please mark this report Status Confirmed.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

I am still using Ubuntu 14.04 (on a MacBook Air). I have a Logitech wireless mouse M185, like the OP, and have just noticed the same problem: the middle button (wheel) is no longer recognized (checked with xev). Scrolling up and down (buttons 4 and 5) work fine. So this problem was presumably introduced with a recent kernel release. I am currently using 3.13.0-110-generic. Unfortunately, I was travelling without the mouse, so I don't know if the problem was introduced in -109 or -110, but I am sure that 3.13.0-108-generic was okay. (I strongly suspect -109 was okay too, because I was back home for a day or two before the upgrade to -110, and I didn't notice a problem.) I hope that helps isolate where the problem was introduced. Let me know if any other information could be useful.

This change was made by a bot.

I'm not sure this is a kernel issue. It appears to be something related to the evdev driver or how the files in xorg.conf.d are interpreted when setting up the evdev driver. the "Evdev Wheel Emulation" is "false" even though my config file xorg.conf.d is trying to set it to "true" - when I manually set it to "true" scrolling works fine.

I have a precise install (3.13.0-112-generic kernel) where the scrolling works. When I look at the output of "xinput --list-props XX" for my trackball, I see that "Evdev Wheel Emulation" is "true". On a Xenial install (4.8.0-41-generic kernel), using the same file in xorg.conf.d for my trackball, it shows Evdev Wheel Emulation as false.

Looking in the syslog, I see a line for:
"/usr/lib/gdm3/gdm-x-session[2042]: (**) Option "EmulateWheel" "true""
but the option isn't being set to true. I believe this is where the problem lies.

Here is a work around:

find the id of the device that won't scroll using "xinput --list", mine is 11

then check whether wheel emulation is true or false usng "xinput --list-props 11"

Here is what I see for list-props when I first boot and log in:

Evdev Wheel Emulation (297): 0

the 0 is false. Change this with the following:

xinput --set-property 11 297 1

where
11 - id of the device
297 - property number (shown in parenthesis from above)
1 is the boolean for true

After doing this, the output from "xinput --list-props 11" shows:
Evdev Wheel Emulation (297): 1

And now the scroll works as it did before I experienced this problem.

Can others check what they find using "xinput --list-props xx" to see if this is repeatable?

Thanks

typo in my previous post. Command is:

xinput --set-prop 11 297 1

Apologize for any confusion.

I followed John's instructions and am attaching the terminal output (from the script command) because it does show emulation set to zero as well as my type of mouse.
My scrolling has always worked, just not the middle mouse paste. Performing the steps john suggested did not make the pasting work.

I'm on Lubuntu 16.10 using lxde. The problem also was happening to me last year under the previous LTS (I think xubuntu 14.04) using xfce.

I meant to say that last year an update killed my middle mouse pasting, which had worked before. This install is a completely clean install of Lubuntu 16.10 after reformatting the hard drive.

The middle button paste may be set elsewhere. I'm using Ubuntu Gnome and there is an option for it in the gnome tweak tool. I think the default on install was off. It's "Middle-click Paste" and should be set to "ON"

There's probably lots of ways to set it, I do it through gnome tweak tool, which is a gui. I can't say for certain if this is available in lubuntu or xfce. On gnome, I search for "Tweak Tool" in applications or from a terminal window I can enter "gnome-tweak-tool" to launch it.

The setting for "Middle-click Paste" is under "Keyboard and Mouse" then the subheading "Mouse"

I was able to get this to work by doing something similar to jmanecke's advice:

instead of enabling "Evdev Wheel Emulation", I enabled "Evdev Third Button Emulation"

Tried the above but no luck as yet
xinput --list-props 11
Device 'Logitech USB-PS/2 Optical Mouse':
 Device Enabled (139): 1
 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (270): 0
 Device Accel Constant Deceleration (271): 1.000000
 Device Accel Adaptive Deceleration (272): 1.000000
 Device Accel Velocity Scaling (273): 10.000000
 Device Product ID (259): 1133, 49232
 Device Node (260): "/dev/input/event8"
 Evdev Axis Inversion (274): 0, 0
 Evdev Axes Swap (276): 0
 Axis Labels (277): "Rel X" (149), "Rel Y" (150), "Rel Horiz Wheel" (268), "Rel Vert Wheel" (269)
 Button Labels (278): "Button Left" (142), "Button Middle" (143), "Button Right" (144), "Button Wheel Up" (145), "Button Wheel Down" (146), "Button Horiz Wheel Left" (147), "Button Horiz Wheel Right" (148), "Button Side" (263), "Button Extra" (264), "Button Forward" (265), "Button Back" (266), "Button Task" (267), "Button Unknown" (262), "Button Unknown" (262), "Button Unknown" (262), "Button Unknown" (262)
 Evdev Scrolling Distance (279): 1, 1, 1
 Evdev Middle Button Emulation (280): 1
 Evdev Middle Button Timeout (281): 50
 Evdev Third Button Emulation (282): 1
 Evdev Third Button Emulation Timeout (283): 1000
 Evdev Third Button Emulation Button (284): 3
 Evdev Third Button Emulation Threshold (285): 20
 Evdev Wheel Emulation (286): 0
 Evdev Wheel Emulation Axes (287): 0, 0, 4, 5
 Evdev Wheel Emulation Inertia (288): 10
 Evdev Wheel Emulation Timeout (289): 200
 Evdev Wheel Emulation Button (290): 4
 Evdev Drag Lock Buttons (291): 0
-------------------------------------------------
anything obviously wrong there?

tompotts-

looking at your output, it looks like wheel emulation is still set to false:

Evdev Wheel Emulation (286): 0

I don't know what your trying to get it to do, but for me, my trackball works the way I want it to when I turn on the wheel emulation (set it to 1).

Based on the output you posted, you could try:

xinput --set-prop 11 286 1

which would turn on the wheel emulation

I am trying to get it to work as the middle button - so I can use blender. The wheel already works as a wheel but it doesnt work as a button.

only other thing to try is check that "Middle-click Paste" is set to ON in gnome-tweak-tool.

Try running xev and clicking the buttons with the mouse in the window. I see the button event when Middle-click Past is ON but not when it's OFF.

middle-click-paste is ON but no response from clicking wheel in xev.

Same problem for me today. Middle button was working one moment, not working the next. Xubuntu 14.04. Didn't update any packages or anything. Mouse is a Logitech M310 that I've had for years. A Dell USB wired mouse (shows up in xinput as "PixArt") works just fine. xev shows no events whatsoever from the middle click, but correctly registers every other mouse event. Was hoping a reboot would fix, but no such luck. It's not just middle-click that's stopped working; it's all middle-click functionality. xinput properties on the two mice look identical where third-button behavior is involved:

Device 'PixArt USB Optical Mouse':
 Device Enabled (142): 1
 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (269): 0
 Device Accel Constant Deceleration (270): 1.000000
 Device Accel Adaptive Deceleration (271): 1.000000
 Device Accel Velocity Scaling (272): 10.000000
 Device Product ID (258): 1121, 20002
 Device Node (259): "/dev/input/event11"
 Evdev Axis Inversion (273): 0, 0
 Evdev Axes Swap (275): 0
 Axis Labels (276): "Rel X" (152), "Rel Y" (153), "Rel Vert Wheel" (268)
 Button Labels (277): "Button Left" (145), "Button Middle" (146), "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149), "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151), "Button Side" (262), "Button Extra" (263), "Button Forward" (264), "Button Back" (265), "Button Task" (266), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261)
 Evdev Middle Button Emulation (278): 0
 Evdev Middle Button Timeout (279): 50
 Evdev Third Button Emulation (280): 0
 Evdev Third Button Emulation Timeout (281): 1000
 Evdev Third Button Emulation Button (282): 3
 Evdev Third Button Emulation Threshold (283): 20
 Evdev Wheel Emulation (284): 0
 Evdev Wheel Emulation Axes (285): 0, 0, 4, 5
 Evdev Wheel Emulation Inertia (286): 10
 Evdev Wheel Emulation Timeout (287): 200
 Evdev Wheel Emulation Button (288): 4
 Evdev Drag Lock Buttons (289): 0

----------------------------------------------------------------

Device 'Logitech M310':
 Device Enabled (142): 1
 Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (269): 0
 Device Accel Constant Deceleration (270): 1.000000
 Device Accel Adaptive Deceleration (271): 1.000000
 Device Accel Velocity Scaling (272): 10.000000
 Device Product ID (258): 1133, 4132
 Device Node (259): "/dev/input/event7"
 Evdev Axis Inversion (273): 0, 0
 Evdev Axes Swap (275): 0
 Axis Labels (276): "Rel X" (152), "Rel Y" (153), "Rel Horiz Wheel" (267), "Rel Vert Wheel" (268)
 Button Labels (277): "Button Left" (145), "Button Middle" (146), "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149), "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151), "Button Side" (262), "Button Extra" (263), "Button Forward" (264), "Button Back" (265), "Button Task" (266), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Un...

OK, I feel stupid now. My middle-click functionality is broken because the physical button inside the mouse is failing. Apparently clicking a mouse button 8 hours a day for 3 years causes a certain amount of wear. I tested the mouse on another computer, it had the same problem, and on a whim I tried just pressing down harder, which suddenly made it work. The way it failed so abruptly and specifically (the rest of the mouse is fine) made me sure the problem was somehow software related.

Wow Mike, thanks to your comment I realized I had the exact same problem with my Logitech M210 wireless mouse. I notice that it seems the majority of other reports here also are reported using Logitech mice, so this particular issue may very well be a chronic Logitech mouse problem and not software related at all.

Comments like these make me even more suspicious that this is hardware related and not software related:
"Middle button on my M557 BT mouse resumed normal expected functionality, no specific action on my part, even though I could swear it didn't work on firing up the PC this morning." -The faulty switch probably got knocked back into place.

"the middle click now occasionally works. I would guess that with the chance of 1/2-1/8 the click works. In the remaining cases it does not." -Since the click can register with extra force, this would explain why a user might see it working sometimes and not others.

"The failed mouse device was a "Logitech USB Receiver", USB ID 046d:c517
On runtime I attached another Logitech mouse, USB ID 046d:c52f, running absolutely fine in this regards." -another mouse works fine

In sum, I think this issue likely has nothing to do with the Linux kernel or any other package, and may be a candidate for closure.

This shouldn't be confused with the mouse scroll issue that John M reported, which does appear to be software related, but that should be filed as a different bug as it has to do with the scrolling function of the wheel and not the middle mouse click.

Probably not of interest to anyone, but I am going to try taking my mouse apart to see if I can bend something back into place.

I think we should focus on the the essential.
This bug has nothing to do with broken hardware. It's a regression. And as such, I think it should have HIGH importance, not medium.

xev shows the left and right buttons, but no event for middle/scroll wheel button.

I've used the middle button for many years, in many (X)Ubuntu releases, with many mouses. Now it's broken.

Just bought a Logitech M705 in a combo with a K520 keyboard. In Ubuntu 16.04 the middle button is not activated and not working. I've a stock Ubuntu 16.04 with all recent updates. I'm using Unity.

Output:

xinput --list-props 8
Device 'Logitech M705':
 Device Enabled (153): 1
 Coordinate Transformation Matrix (155): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
 Device Accel Profile (283): 0
 Device Accel Constant Deceleration (284): 1.000000
 Device Accel Adaptive Deceleration (285): 1.000000
 Device Accel Velocity Scaling (286): 10.000000
 Device Product ID (272): 1133, 4123
 Device Node (273): "/dev/input/event3"
 Evdev Axis Inversion (287): 0, 0
 Evdev Axes Swap (289): 0
 Axis Labels (290): "Rel X" (163), "Rel Y" (164), "Rel Horiz Wheel" (281), "Rel Vert Wheel" (282)
 Button Labels (291): "Button Left" (156), "Button Middle" (157), "Button Right" (158), "Button Wheel Up" (159), "Button Wheel Down" (160), "Button Horiz Wheel Left" (161), "Button Horiz Wheel Right" (162), "Button Side" (276), "Button Extra" (277), "Button Forward" (278), "Button Back" (279), "Button Task" (280), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275), "Button Unknown" (275)
 Evdev Scrolling Distance (292): 1, 1, 1
 Evdev Middle Button Emulation (293): 0
 Evdev Middle Button Timeout (294): 50
 Evdev Third Button Emulation (295): 0
 Evdev Third Button Emulation Timeout (296): 1000
 Evdev Third Button Emulation Button (297): 3
 Evdev Third Button Emulation Threshold (298): 20
 Evdev Wheel Emulation (299): 0
 Evdev Wheel Emulation Axes (300): 0, 0, 4, 5
 Evdev Wheel Emulation Inertia (301): 10
 Evdev Wheel Emulation Timeout (302): 200
 Evdev Wheel Emulation Button (303): 4
 Evdev Drag Lock Buttons (304): 0

Even if I enable "Evdev Middle Button Emulation", "Evdev Third Button Emulation" and "Evdev Wheel Emulation" it will not work. I hope that some will come with a solution.

As info06 clearly states this isn't a hardware issue, because of my newly acquired mouse (yesterday). Have also tried the LTS HWE xorg and kernel (4.10) but to no effect. Now I've downgraded again to the 4.4 stable kernel.
But as the bugreporter in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1704430 says, may the mainline kernel 4.13.0-041300rc1-generic fix the problem. I haven't time to test this but may it be possible that someone else could test this?

Nevermind it worked if I remapped the mouse with xinput. I discovered that the middle button actually was recognized, but it wasn't showing as button 2 as expected but 6.

1. The command "xev | grep button", gave me the button 6 if I clicked in the xev window with the middle button.
Then I had to remap the mouse buttons from 6 to 2 (2 is the middle button):
2. The command "xinput get-button-map 8" was giving me my buttons "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"
Then I remapped them:
3. "xinput set-button-map 8 1 2 3 4 5 2 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24", the sequence remapped my sixth button to number 2, the middle click was after that working.

To get it loaded each time I start Unity I autostarted that last command at login.

More testing shows that the problem isn't resolved. Two buttons on my mouse have the same number, number 6 (middle click and roller tilt left). But number 2 which should be the middle button isn't there, I can remap button 6 to button 2 for middle click to work but then the 'real' button 6 disappears (roller tilt left) and I've only roller tilt right on button 7. Ubuntu can't detect the button 2. What to do?

I have two machines, both running xubuntu. They use the same keyboard and mouse interfaced through a kvm.

The machine upgraded from 14.10 to 16.04 works fine.

The machine with a clean 16.04 fails. xev shows no middle button, but the wheel works fine.

Both are fully updated.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

Discovered this problem yesterday, which led me to this bug-report:

Middle-button clicking was dead and didn't work on a clean new xenial install,
same mouse works fine on an upgraded PC.

Testing with xev showed nothing on the new PC: Middle button clicks were not recognised.

"xinput list" told the mouse was:
 "PixArt HP USB Optical Mouse id=1 [slave pointer (2)]

Ran a few "xinput test <ID>" commands. (NOT only on the mouse's ID (15) but a another to initially, lower number, typo.)

And alas: Middle button clicks were suddenly detected and worked like charm - for half an hour.
Then it died again.

I repeated the "xinput test" deal, now on several ID's, lastly the mouse.
After this, the middle button clicks were once again detected.

This time i rebooted the PC, power-pff/on. Wheel-clicking survived the reboot and still works,
36 hours later or so.

I'm not a kernel person but as an old-time user I got a little back-flash to the days of kernel 2.0,
 when devices often had to be added and linked manually.

A look in /dev revealed several recent changes, from the time of the xinput tests.

Grep'ed around and found:

me@pc:/dev$ ls -latr |grep "11:48"
drwxr-xr-x 4 root root 520 Dec 16 11:48 input
drwxr-xr-x 21 root root 4200 Dec 16 11:48 .
crw------- 1 root root 247, 0 Dec 16 11:48 hidraw0
drwxr-xr-x 2 root root 4140 Dec 16 11:48 char

me@pc:/dev/input$ ls -latr |grep "11:48"
drwxr-xr-x 21 root root 4200 Dec 16 11:48 ..
drwxr-xr-x 4 root root 520 Dec 16 11:48 .
crw-rw---- 1 root input 13, 34 Dec 16 11:48 mouse2
crw-rw---- 1 root input 13, 80 Dec 16 11:48 event16
drwxr-xr-x 2 root root 220 Dec 16 11:48 by-path
drwxr-xr-x 2 root root 100 Dec 16 11:48 by-id

me@pc:/dev/input/by-path$ ls -latr |grep "11:48"
drwxr-xr-x 4 root root 520 Dec 16 11:48 ..
lrwxrwxrwx 1 root root 9 Dec 16 11:48 pci-0000:00:14.0-usb-0:1:1.0-mouse -> ../mouse2
lrwxrwxrwx 1 root root 10 Dec 16 11:48 pci-0000:00:14.0-usb-0:1:1.0-event-mouse -> ../event16

me@pc:/dev/input/by-id$
drwxr-xr-x 4 root root 520 Dec 16 11:48 ..
lrwxrwxrwx 1 root root 9 Dec 16 11:48 usb-PixArt_HP_USB_Optical_Mouse-mouse -> ../mouse2
lrwxrwxrwx 1 root root 10 Dec 16 11:48 usb-PixArt_HP_USB_Optical_Mouse-event-mouse -> ../event16
drwxr-xr-x 2 root root 100 Dec 16 11:48 .

me@pc:/dev/char$
lrwxrwxrwx 1 root root 18 Dec 16 11:48 189:8 -> ../bus/usb/001/009
lrwxrwxrwx 1 root root 10 Dec 16 11:48 247:0 -> ../hidraw0
lrwxrwxrwx 1 root root 15 Dec 16 11:48 13:34 -> ../input/mouse2
lrwxrwxrwx 1 root root 16 Dec 16 11:48 13:80 -> ../input/event16

Hoping the listings above can be of help in solving this annoyance.
I agree "Importance" should be raised to major.

Forgot a detail: The first initial "fix" i experienced was when unplugging the mouse and trying another USB port. Middle buttin clicking then worked for a few merryt minutes before it died iff again. Changing ports yet again had no effect.

Some system information: Product Name: HP EliteBook 850 G3

$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ PS/2 Generic Mouse id=11 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=12 [slave pointer (2)]
⎜ ↳ PixArt HP USB Optical Mouse id=15 [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)]
    ↳ Sleep Button id=8 [slave keyboard (3)]
    ↳ HP HD Camera id=9 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
    ↳ HP Wireless hotkeys id=13 [slave keyboard (3)]
    ↳ HP WMI hotkeys id=14 [slave keyboard (3)]

Do you get mid click event in `evtest`?

Same as Kristin #85 :

Disconnecting the USB receiver in a port, and connecting it in the USB port just besides it, has been working for some time now. Middle click is now recognized in System Settings. Ubuntu 16.04, NVIDIA drivers.

xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Mouseemu virtual mouse id=13 [slave pointer (2)]
⎜ ↳ Logitech K330 id=8 [slave pointer (2)]
⎜ ↳ Logitech M215 2nd Gen id=11 [slave pointer (2)]

I am also affected by this bug, and have been for a couple of months. I have a Logitech M310 wireless mouse, which has been working fine for a long time until recently:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K520 id=9 [slave pointer (2)]
⎜ ↳ Logitech M310/M310t id=10 [slave pointer (2)]

There are now around 50 people registered as affected by this bug, and it has a bug heat nudging 250. It would be really great if some kind soul could investigate this.

After
xinput set-prop 10 "libinput Horizontal Scroll Enabled" 0
button #2 appeared in xev again.

I have two mices:

a Logitech M310 wireless mouse, than now does not work.
a Logitech M171 wireless mouse, that works and always has worked.

Using a Logitech M310 from a KM520 bundle kit.

When it stops working, I've been able to get it to work again by running xev and holding the mousewheel down and cycling through several events. Once it starts showing, it will fire many button presses. Once it starts to appear, there will be a noticeable delay from button press to event. This delay decreases, and eventually disappears. This sorts it out for a day or so.

I was convinced it was hardware failure (possibly bad soldering points on the middle mouse click), since it seems to respond to more pressure on the wheel, but the regularity of failure and the fact it works after following this protocol makes me doubt it.

As a data point for future googlers, I had what sounds like the same/similar problem today, my middle-button-click stopped working.

Except I found that it was working but I had to hold it down for a few hundred ms until it reliably clicked, sometimes quickly clicking in succession would report some clicks also, but holding it down for about half a second was reliable (but annoying).

Anyway, long story short I issued the following set-prop for "Evdev Middle Button Timeout (269)" and it corrected the issue, note that I also first tried changing the property to 10 first and that didn't make a difference, but now after having set it to zero I can increase that property to seemingly anything and it all works fine, so I don't know what exactly is going on there.

xinput --set-prop 11 269 0

(where 11 is the device id of my mouse (xinput without arguments will tell you), 269 is the property being set, and 0 is the value I am setting,

Here are the list-props when I was experiencing the problem

--------------------------------------------------------------------------------

Device 'MOSART Semi. 2.4G Keyboard Mouse':
        Device Enabled (131): 1
        Coordinate Transformation Matrix (133): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (258): 0
        Device Accel Constant Deceleration (259): 1.000000
        Device Accel Adaptive Deceleration (260): 1.000000
        Device Accel Velocity Scaling (261): 10.000000
        Device Product ID (248): 1578, 16641
        Device Node (249): "/dev/input/event5"
        Evdev Axis Inversion (262): 0, 0
        Evdev Axes Swap (264): 0
        Axis Labels (265): "Rel X" (141), "Rel Y" (142), "Rel Horiz Wheel" (255), "Rel Dial" (256), "Rel Vert Wheel" (257)
        Button Labels (266): "Button Left" (134), "Button Middle" (135), "Button Right" (136), "Button Wheel Up" (137), "Button Wheel Down" (138), "Button Horiz Wheel Left" (139), "Button Horiz Wheel Right" (140), "Button Side" (253), "Button Extra" (254), "Button Unknown" (251), "Button Unknown" (251), "Button Unknown" (251), "Button Unknown" (251)
        Evdev Scrolling Distance (267): 1, 1, 1
        Evdev Middle Button Emulation (268): 0
        Evdev Middle Button Timeout (269): 50
        Evdev Third Button Emulation (270): 0
        Evdev Third Button Emulation Timeout (271): 1000
        Evdev Third Button Emulation Button (272): 3
        Evdev Third Button Emulation Threshold (273): 20
        Evdev Wheel Emulation (274): 0
        Evdev Wheel Emulation Axes (275): 0, 0, 4, 5
        Evdev Wheel Emulation Inertia (276): 10
        Evdev Wheel Emulation Timeout (277): 200
        Evdev Wheel Emulation Button (278): 4
        Evdev Drag Lock Buttons (279): 0

--------------------------------------------------------------------------------

Here are the list-props after issuing the set-prop command above

--------------------------------------------------------------------------------
Device 'MOSART Semi. 2.4G Keyboard Mouse':
        Device Enabled (131): 1
        Coordinate ...

Ok, I guess this is embarrassing, but as I was trying James' workaround in #92 , I started thinking that somehow the signal was weak or intermittent. A few minutes later, Solaar (the GUI that displays status of Logitech wireless devices) tells me that the battery level in the mouse was down to 5%. I replaced the only battery it takes (I have the M215), and the middle button started working just fine.

It's been rock solid for a few days.Running Bionic now.

(as an aside, it seems like the battery reporting capabilities are not too good: new batteries show 90% charge, and this one "dropped" from 90% to 5% instantly. But the battery was very likely almost empty for quite some time)

Thanks very much James for the very useful info (comment #92)! It has helped me to finally solve this annoying problem on my machine.

I'm running Kubuntu 17.10 with a Logitech M310 mouse. For me, I had to do things slightly differently to you.

"xinput" revealed that my mouse was device id 10, and "xinput --list-props 10" did not reveal any "Evdev Middle Button Timeout" property. Instead, I have a "libinput Middle Emulation Enabled (289)" property, which was set to 0. So I enabled it using:

xinput --set-prop 10 289 1

It took a few moments for this to kick in, but it has now fixed the problem - my scroll-wheel clicking events are finally working again :-)

Using a Logitech M310 from a KM520 bundle kit like Steven Karas (steven-karas) and having exactly the same issue. His comment (comment #91) makes my middle button magically start working as well.

In Kubuntu 18.04 the middle mouse button of my Logitech M310 didn't work anymore.
After I tried the workaround as described in #91 and #95 it started working again.

In my case, same thing than above: Logitech M310 middle button not working on Ubuntu 18.04 => issued "xev | grep button" on a terminal, checked the left, then the right and finally the middle/wheel buttons:
# xev | grep button
    state 0x0, button 1, same_screen YES
    state 0x100, button 1, same_screen YES
    state 0x0, button 3, same_screen YES
    state 0x400, button 3, same_screen YES
    state 0x0, button 2, same_screen YES
    state 0x200, button 2, same_screen YES
    state 0x0, button 2, same_screen YES
    state 0x200, button 2, same_screen YES
Then, just after closing the xev window, noticed the "middle mouse button click/paste" suddenly started to work again. Weird...

Same behavior here. Middle Mouse Button (button2) not working, starting

xev | grep button

try it multiple times; button event occurs; stop xev and the button keeps working.\

Environment:
KDE Neon (based on Ubuntu 18.04) with mainline kernel verion 5.1.2-050102-generic
Hardware:
Logitech USB-PS/2 Optical Mouse connected to a Lenovo Yoga X380 via Thunderbolt 3 Dock

Comment #91 gives me some seconds of autonomy with the central click, but then it reverts back to being useless.

I am on Ubuntu 18.04, `uname -a`
```
Linux brenna 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
```

Embarrassing. Logitec M185. Therefore I put me as 'affects me'.