Problems with clicks in fedora 36?

Hello friends, I have a somewhat strange problem in Fedora 36, what happens is that when I click, the click remains as if I pressed it for a long time (although I did not press it for more than an instant), what I mean is that if I click on the terminal icon, for example, instead of opening the terminal the icon stays pressed as if I were going to move it, or when I click on a page the text is selected, or if I want to change tab in the browser, if I click on the window the same thing happens and it gets “stuck” and moves or a new window is made. Sometimes the click does not work well, or is highlighted or does not work at all
I’m sorry it’s hard to explain because it’s very rare.
Previously I had a Fedora 28 and this never happened to me, I also use Windows 10 and this does not happen there, I wanted to know if it is a problem with Fedora 36 and how to solve it

Thanks in advance

In order to get some more info, can you open a terminal and run sudo libinput debug-events and then click your mouse and paste here what the output is? If the mouse is working correctly, you should see something like this:

 event11  POINTER_BUTTON          +0.944s	BTN_LEFT (272) pressed, seat count: 1
 event11  POINTER_BUTTON          +1.088s	BTN_LEFT (272) released, seat count: 0

You should see “pressed”, followed by “released” when you let go of the click button. If you don’t see the second message, it means that it’s a problem with the mouse input sticking on click.

1 Like

Hello, thank you very much for your answer. I get the following:

[jorgemartinez@2806-104e-000b-15ee-2bd6-0241-effc-12e6 ~]$ sudo libinput debug-events
[sudo] password for jorgemartinez: 
-event2   DEVICE_ADDED            Power Button                      seat0 default group1  cap:k
-event5   DEVICE_ADDED            Video Bus                         seat0 default group2  cap:k
-event1   DEVICE_ADDED            Power Button                      seat0 default group3  cap:k
-event0   DEVICE_ADDED            Lid Switch                        seat0 default group4  cap:S
-event9   DEVICE_ADDED            HP Truevision HD: HP Truevision   seat0 default group5  cap:k
-event3   DEVICE_ADDED            AT Translated Set 2 keyboard      seat0 default group6  cap:k
-event4   DEVICE_ADDED            ETPS/2 Elantech Touchpad          seat0 default group7  cap:pg  size 89x38mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on dwtp-on
-event6   DEVICE_ADDED            Wireless hotkeys                  seat0 default group8  cap:k
-event8   DEVICE_ADDED            HP WMI hotkeys                    seat0 default group9  cap:k
-event4   POINTER_MOTION          +0.017s	  4.82/ -3.12 (+17.00/-11.00)
 event4   POINTER_MOTION          +0.026s	  7.34/ -2.87 (+23.00/ -9.00)
 event4   POINTER_MOTION          +0.035s	  8.29/ -1.28 (+26.00/ -4.00)

It’s weird because, today for example I haven’t had that problem, it only happens sometimes that the click stays “stuck”

When you say the mouse works as expected with Windows, is that the same mouse on the same computer (dual boot, Fedora and Windows)? If not I’d suggest checking a different mouse on your Fedora system, as the mechanical actions of mouse clicking are often affected by dust and grit getting into the mouse microswitch area.
But if the mouse never shows a problem in Windows and does more frequently with Fedora, then you’ll have to continue to work to reproduce the problem as Scott suggests.

I don’t see any click events here. Please try sudo libinput debug-events | grep POINTER_BUTTON and then click the mouse a few times to see if you can replicate it then share the output back here.

this time i got the following

^[^C[jorgemartinez@2806-104e-000b-15ee-2bd6-0241-effc-12e6 ~]$ sudo libinput debug-events | grep POINTER_BUTTON
 event4   POINTER_BUTTON          +24.959s	BTN_LEFT (272) pressed, seat count: 1
 event4   POINTER_BUTTON          +25.078s	BTN_LEFT (272) released, seat count: 0
 event4   POINTER_BUTTON          +27.960s	BTN_LEFT (272) pressed, seat count: 1
 event4   POINTER_BUTTON          +28.089s	BTN_LEFT (272) released, seat count: 0

1 Like

That looks normal. Did the mouse hang this time? It looks like the unclick was correctly received in these two events.