Really Weird Mouse Problem

English Hardware
1

Sorry, I know that’s a vague-as-heck title, but I don’t know how to explain this one in just a few words for a thread title. Anyhoo…

System:
Mobo: ASRock X870 Steel Legend WiFi
CPU: AMD Ryzen™ 7 9700X
Mouse: Logitech MX Master 2, connected w/ Logitech USB adapter
OS: openSUSE Tumbleweed, current release w/ updates

Issue: My mouse behaves in different strange ways in different contexts. I’ll describe this based on what I’ve seen thus far.
Scenario 1: When I’m in Scribus and I’m doing a mouse-related task, such as sizing or re-sizing a box (text, graphic, etc.) and I’m moving the mouse on a down-and-to-the-right angle, unless I move it very slowly, it lets go of the object. This is also true if I take an object and am simply moving it. I can go in any direction other than on a downward-to-the-right angle, and it’s fine. Go in that direction with any speed at all and it drops the object. Basically, it acts like I have a mouse button issue.
Scenario 2: In Gparted, in the upper right corner of the window, there’s a drop-down menu which is a list of all currently connected drives. When I click on it, the menu starts to render then goes away, and it’s so fast as to be utterly unusable.

I don’t know if there are any other screwball issues like this because thus far those are the only ones I’ve encountered.

These issues are “new” as of, let’s say, the last 3 or 4 days max.

Troubleshooting Steps Tried: Restarted the programs involved. Restarted my computer. Removed the USB adapter for the mouse and reconnected it. Turned the mouse off and back on. Booted into a previous snapshot (there’s only two available).

I created a bootable Live Image flash drive of Pop_OS! 24.04 and booted from that, installed Scribus, also tried out Gparted, and everything works normally. So that rules out a hardware problem.

Also, I don’t know if this is related or not, but the input on my keyboard isn’t quite right. I have an English (Macintosh) layout chosen, and it also no longer works quite exactly correctly, not letting me type certain accented characters through the means it’s set up to use.

2

Which desktop environment? Wayland or X11 session? If you create a new user and log in as that user, does the same problem exist?

To investigate a possible libinput issue, run:

sudo libinput debug-events

Move your mouse in that “down-and-right” direction. See if any “button release” events show up spontaneously. That would confirm a software interpretation issue. A bug report would then need to be submitted.

Regarding the keyboard, please show the output of

localectl
3

Hey @deano_ferrari…

DE = Gnome 49 / Wayland

So, I tried to run libinput but it’s not installed and when I tried to install it, zypper found nothing.

OTOH, localectl returned the following:

System Locale: LANG=en_US.UTF-8
    VC Keymap: us
   X11 Layout: us
    X11 Model: pc105+inet
  X11 Options: terminate:ctrl_alt_bksp

Also, just to rule out any external cause, I ran memtest86 just to be sure, for example, drivers or some other components weren’t getting corrupted. Came through perfect, no errors.

4

Install the libinput-tools package.

5

I’m not a Gnome user, so this may take one of the gurus to drop by. If I understood your opening post, you’re using a Macintosh keybaord? Check the current settings with
gsettings get org.gnome.desktop.input-sources sources

and if necessary change it to US MAC variant using
gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us+mac')]"

Does that help at all?

6

Ok, so after a couple very careful goes at this, here’s what I am seeing at the moment my mouse loses grasp of whatever it’s doing (dragging an object, resizing an object):

event4 POINTER_BUTTON +11.790s BTN_LEFT (272) released, seat count: 0

The count in seconds will be different, but that event is what shows up. So, it’s making it seem like it’s a mouse button issue, and I’m confident in this particular case it is not. I mean, if I push in any other direction, this doesn’t happen, so it can’t be a button issue. Moreover (as previously said) when I’m running a different OS install, it doesn’t happen at all.

7

No, I’m using a regular standard keyboard (a Logitech Illuminated Keyboard). I just have the Macintosh layout chosen because I prefer the way it gives access to special characters.

8

Ok, thanks for clarifying. Can you show the current settings?
gsettings get org.gnome.desktop.input-sources sources

9

—> Bug report needed.

10

Sure: [('xkb', 'us+mac'), ('xkb', 'us+altgr-intl')]

11

Ok, so two active layouts. What happens if you just keep the first?
gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us+mac')]"
Log out and back in, and test the Option key accents behaviour again.

If you need both layouts, try having one under a different language setting eg English or Canadian English perhaps…
gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us+mac'), ('xkb', 'gb')]"

Does that avoid any GNOME handling issue?

12

Ok, filed as: Bug 1252708

13

Another thing to try with respect to the mouse. Does the same issue present itself with Gnome X11. That might help with understanding where this regression lies.

The other thought I had is whether there is a .quirks file for your mouse device. Show the results from
sudo libinput list-devices | grep -E 'Device|Kernel'

This will show if a *.quirks exists…
grep -R "$(sudo libinput list-devices | grep -m1 'Device' | cut -d: -f2 | xargs)" /usr/share/libinput-1.28.1/libinput/*.quirks

14

Huh… According to this, there is only one keyboard layout:

KeyboardLayout
KeyboardLayout1498×992 143 KB

[And yes, I’m hearing the “There can be only one!” quote from Highlander in my head.] :laughing:

15

Ok, use the gsettings command to set one explicitly as already described, and test again.

16 
Device:                  Power Button
Kernel:                  /dev/input/event6
Device:                  Video Bus
Kernel:                  /dev/input/event0
Device:                  Power Button
Kernel:                  /dev/input/event5
Device:                  Logitech Logitech Illuminated Keyboard
Kernel:                  /dev/input/event2
Device:                  Logitech Logitech Illuminated Keyboard Consumer Control
Kernel:                  /dev/input/event3
Device:                  Logitech MX Master 3
Kernel:                  /dev/input/event4
17

Sorry, I had forgot that I’d removed it before you posted to try as an experiment. I did have both the Macintosh and the AltGr Dead Keys layouts installed previously.

Nope, no change. What I’m used to is, for example, if I press AltGR + U and then type either a u or a U, I should get a ü or a Ü.

Except that just now, that actually worked here in Firefox in this forum, but when I tried it elsewhere (Text Editor, terminal) it didn’t. What in the world…

18

You could try the following (no promises). Create a custom /etc/libinput/local-overrides.quirks file with

[MX Master 3 Button Fix]
MatchName=Logitech MX Master 3
AttrPointerButtonDebounce=1

Save then log out and back in. Hopefully, This setting will help suppress any brief, unintended button-release signals that this device might be generating ie eliminate any spurious “release” events. See how that goes.

19

Test a bit more…maybe only some applications are impacted?

20

And you know what’s weird? (I mean, let’s be honest, this whole thread is weird) I just tested (before implementing your suggestion) taking a regular window in Gnome and dragging it, and none of what I described happened. So, it looks like it’s contained to within a window.