Mouse clicks register as drag-and-drop

Hardware Support
1

Today I will be reluctantly booting Windows to work with Blender.

Why, because mouse clicks in Zorin 18 randomly register as drag-and-drop - it's just going to be too much of a hassle to try to learn a complex new UI when the mouse is behaving erratically.

This has been a problem with practically every Linux distro I've ever tried, so it's definitely not specific to Zorin - various attempts with Ubuntu on different systems with different mice (different brands, wired and wireless) in the past all occasionally had this problem.

Frankly it's the only thing in Zorin 18 that doesn't feel to me like a mature OS, and you guys seem to care about desktop UX more than any other Linux distro, which is why I'm posting it here.

I know, there are ways to manually debug this by adjusting some obscure parameters or replacing something - I've tried in the past (both in Ubuntu and Zorin) and I could never figure out how to fix it.

The last time I looked into it, I found threads more than a decade old discussing these problems, so it's definitely "a thing".

In daily work with VS Code and Brave, I make do with pressing ESC when it randomly decides that I'm dragging rather than clicking - but I can't put up with this while trying to learn something as complex as Blender, so.

Booting Windows today.

Not happy about it.

I can't imagine what sort of mess must be inside the mouse driver code or whatever is responsible for this - I mean, it sounds ridiculous that this wouldn't just work with virtually any USB mouse ever created. I don't even know how it's possible to write code that registers "mouse button goes down" but somehow randomly misses "mouse button goes up"? It sounds bonkers.

Hopefully this post inspires somebody to look into this.

Zorin is so polished and professional, it's never once crashed or misbehaved in really any other way since I installed it in february.

You would think someone over there is smart enough to fix this apparently small but very frustrating daily annoyance. :relieved_face:

1 Like
2

So, You use an external Mouse, yes? No Mousepad.

3

what do you mean external? a mouse is an external device, yes?

and what does a mouse pad have to do with the mouse buttons? two devices with a mouse pad, one without, I guess.

I don't even know what you're asking.

4

Welcome to the Forum!

And yes, Zorin OS is also for me a very stable and well designed Linux OS!
So it's worth it to try to come over this mad mouse problem!

As a lot of Mouses showed the same problem, which mouse model(s) are you using now? Connected over cable, Bluetooth or dongle? (Even there are some clickable mouse pads / touch pads: apparently you don't use one.)

The problem you describe never happened with my Logitech Mouse MX KEYS under Zorin OS 18. There is a Open Software Solaar to adjust the mouse properties of it. May be a more customization mouse would help you? Did you ever try this Mouse Logitech MX KEYS with SOLAAR?

May be I had never problems with this Logitech mouse because I am not using Visual Studio Code and therefor use my mouse much simpler?

I am not familiar with special Driver debugs, but others experienced might help you.

1 Like
5

It is interesting you post this thread.
I began testing the 7.0 kernel update as of two days ago and since then... It really feels like my mouse is randomly clicking areas on the screen on its own.
And seeming to drag and drop out of nowhere. So far, I thought it was the mouse...
Because I happened to replace my mouse with a new one (Just needed a new one), three days before the new kernel.

1 Like
6

As wirelees mice, would these be classified as networked devices? Bearing in mind A.I. code was used for networking bits in the latest Linux kernel?

7

Mine is wired. I have traced one issue directly to the mouse. Not the OS or kernel.
Not sure yet on the other two.

Yes, a wireless mouse or keyboard is routed through Radio, whether it is using Wifi or Bluetooth.

8

Well radio was included in the A.I. code bit of the new kernel if memory serves.

9

I have used at least 4 different mice (3 wired, one wireless, all different brands) on 3 different systems (two laptops, one workstation) and different OS, starting with Ubuntu maybe 3-4 years back.

This is a very old issue that in my experience affects practically every mouse - I'm honestly surprised when someone tells me they've never had a mouse button "stuck" after clicking or dragging.

Last I looked into it, I found very old discussions about this issue - from the descriptions, it is caused by "jitter". Mouse buttons may make tiny little jumps when the switch physically connects inside the mouse. So drivers have to debounce the signal. Depending on how fast the driver polls the signal, it can get confused about the button state.

The answers I've found were always some obscure incantations to adjust some timing parameters for this debounce in the driver.

I've been able to make this work in the past, but for some reason this time I couldn't - very possibly due to a lack of patience. :sweat_smile:

But the bottom line:

Whatever these default debounce settings are, they are incorrect - for a lot of mice.

The same mice, on the same systems, always worked flawlessly in Windows - so the debounce parameters in Windows are likely set more conservatively.

That is the best explanation I can find.

As I recall, the issue begins with Debian, but I don't guess that means it couldn't be fixed in Ubuntu or Zorin, right?

1 Like
10

Here is Claude's response to the question, correcting a couple of my assumptions:

This matches something real, though the picture's a little more complicated than "Linux debounce settings are just wrong."

The phenomenon itself is well documented. Cheap-ish mechanical switches (Omron and similar) develop contact bounce as they wear, and on click or release the signal can flicker for a few milliseconds before settling. If the driver doesn't filter that out, you get phantom double-clicks, or a click that reads as "stuck down" because a release-bounce got misread as another press.

Why it looks like a Linux-specific problem when it's really a mismatch:

  • Windows mouse drivers (and increasingly, firmware inside the mice themselves, especially on gaming/wireless mice) apply debounce logic tuned per-device or per-vendor, often adjustable in vendor software (Logitech Options, Razer Synapse, etc). Some of that debouncing also happens at the firmware level in the mouse itself, so it "just works" regardless of OS.
  • Linux's evdev/libinput stack historically did no button debouncing at the input layer at all — it trusted the hardware. So any switch bounce passed straight through as real events. That's why you'd find those old forum threads with manual workarounds — people were compensating for something the kernel simply wasn't doing.
  • This changed relatively recently: libinput added a debounce workaround starting around 1.19 (2021) that watches for suspiciously fast press/release/press sequences and filters them, specifically to help with this class of aging-switch bounce. So depending on your distro's libinput version, you may or may not have that protection, and its default threshold may not match what your particular worn-out switches need.

So your instinct is right that Linux defaults have historically been less forgiving — but it's less "Windows chose better numbers" and more "Windows/firmware were doing debounce work that Linux's input layer only started doing fairly recently, and inconsistently across distros."

A few things worth checking if you want to take another pass at it:

  1. Check your libinput version: libinput --version. If it's below ~1.19–1.21, you won't have the built-in debounce quirk handling at all.
  2. libinput's debounce is on by default where supported — no config needed — but it's tuned generically, not per-mouse.
  3. If you want a manual, per-device fix, the actual lever is a udev hwdb quirk or an X11 driver option, not some obscure sysctl — the old advice you found was likely for evdev/synaptics driver options that are now mostly obsolete under libinput.

This sounds similar to what I've found in the past. Maybe it helps someone here come up with a more permanent fix?

11

Let's start with one actual mouse on one actual zorin system you have the problem reproducible right now:

  • please tell us the exact mouse model and how it is connected to your system (USB, Bluetooth, Dongle)
  • and info about the Zorin system: at the terminal type in

neofetch

and post the output here

12

I meant that You have plugged in a Mouse and not using a Mousepad like You have it on a Laptop. I didn't read if You use a Laptop or not. Because of that the Question.

13

This topic is of interest to me.
I occasionally suffer what I describe as "sticky pointer", where after pointing and clicking text, (e.g. "zabadabadoo") the cursor (the index finger one) grabs and drags it round the screen.
Right Click releases it, so more an occasional annoyance than a constant issue.
I did try playing mouse settings at one time, but not really solved.

2 Likes
14

Wonder if anything relevant here? It is an old thread:

15

Did some Drag and Drop and click testings on 4 different Zorin OS systems with several Mouses.

The 4 PCs are all running under Zorin 18.1 Pro, Kernel Linux 7.0.0-28-generic, GNOME 46.0, WM: Mutter (Wayland), but: Nemo instead of Nautilus.

Tested Mouses:

  • older Microsoft USB cabled Mouse
  • older Logitech Mouse connected via Dongle
  • Logitech MX Master 3S over Bluetooth

Result: Drag & Drop and any clicking on all 4 Zorin OS no problem at all.

So my hypothese/question is:
can the WM Wayland (or even X11 but not tested) together with File Manager Nemo be more stable with Mouses then with Nautilus?

1 Like
16

I searched for related issues and here's what I found:

All of these seem to match my description of the same problem.

It usually gets chalked up to a hardware issue, but as explained, I've always been dual booting to Windows on every system I've owned, and no mouse ever had this problem in Windows.

@JustZorin I'll get on my workstation later today and post my hardware details.

1 Like
17

Hi, the Ubuntu MATE post related to a touchpad, I have had experiences with touchpad issues, which aren't related to your issue, and one of the other links the reply was to get a wired mouse.

Personally, out of the four links you posted, I suspect the issue raised in the Fedora link may have some relevance as a lot of the Zorin software has a lot of extensions.

I think this could be an issue. A user would like to add something that is not present on their current Gnome Desktop, they install it, but then it causes other issues.

I think this is why Gnome brought out the Gnome Extension Manager. A lot of stuff that used to be able to be installed gets a red flag, warning the user it won't get installed because of conflicts.

Having said all that, @JustZorin has had no issues. We can therefore possibly link it to a hardware issue inside the mouse that doesn't want to talk to the Linux kernel.

On a separate and totally different issue, Keyboards. Having to sometimes use Qwerty input to produce Braille characters in a Braille document, newer cheap Chinese keyboards became incapable of the 6-key entry method (s,d,f,j,k,l) so were advised by our Duxbury Braille Translator for Windows reseller to always hold on to old keyboards.

18

As explained, I've had this issue with most of the mice I've used with Linux, so just writing this off as a "hardware issue" doesn't make sense - I should be able to use most mice with Linux, right? In my experience, most have this issue.

The mouse is a Sandberg Wired Vertical Mouse model no 630-14. It's a cheap $20 mouse, but this brand is nothing too exotic - it is a top selling brand and very common in Europe.

And as said, I've had other mice, including Microsoft and Logitech mice - I couldn't tell you which ones exactly did or did not work, but I can say that most of them had this problem, and all of them worked fine in Windows. (For all it's failures, I can't recall ever seeing a mouse that didn't work with Windows - they always immediately worked, before installing any of the bloatware they often come with, which I try to avoid in the first place.)

afaik, most cheap, wired mice don't have a dedicated driver for Windows? they just use the universal built-in USB mouse drivers, right? I doubt Sandberg or other discount brands have time to develop their own drivers. afaik most mice on the market follow the same universal standards by now, save for some fancy gaming mice or some brand name mice like Logitech that ship with oodles of unnecessary bloatware.

To my mind, if it works in Windows with a universal USB driver, it should work in Linux, right? There is no rational reason why it shouldn't, is there?

As mentioned, I have been able to fix this in the past by adjusting some obscure timing settings.

And I'd be extremely surprised if this is somehow caused by GNOME extensions - I have exactly one user-installed extension: EmojiCopy, which isn't mouse related and shouldn't have any reason to mess with mouse events.

The phenomenon is well documented and has a whole page with illustrations covering this issue in libinput's docs:

Apparently it has several modes and a whole catalog of "gotcha" notes - it honestly doesn't sound like a description of reliable software. It sounds like someone came up with an overly complex solution to a relatively simple problem. A bouncing switch is in the 1-20 msec range, and a human click or double-click is for sure much longer than that. I don't know why anything as complex as dynamically switching between modes would be needed to solve this for most mice? A debounce algo is trivially simple.

All that being said...

Is there any way this could be application specific?

I run Brave and VS Code and not much else - those two do have a lot in common, with VS Code using browser components for it's GUI, so... :thinking:

And thinking about it, I am honestly not certain that this happens in every app. Like, does it ever happen in the shell itself, or only in the two apps I happen to use? I honestly can't say with certainty.

I will try to pay really close attention in the coming weeks, and try to log when and where this actually happens.

Heck, maybe I should go ahead and try Blender on Zorin 18 to see if I have any problems there - Blender is definitely not based on any browser components, it is way too fast and responsive to be. :sweat_smile:

1 Like