Bug 741553 - [NV98] Mouse freezes - moves but won't click
Summary: [NV98] Mouse freezes - moves but won't click
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: [cat:dead_input]
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-27 09:23 UTC by Oded Arbel
Modified: 2018-04-11 12:10 UTC (History)
12 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-02-13 21:01:51 UTC


Attachments (Terms of Use)
xorg.conf.d/00-system-setup-keyboard.conf (321 bytes, text/plain)
2011-09-27 17:03 UTC, Oded Arbel
no flags Details
Xorg log files (25.42 KB, application/x-zip-compressed)
2011-09-27 17:08 UTC, Oded Arbel
no flags Details
Xorg.0.log from the archive (40.37 KB, text/plain)
2011-09-27 20:32 UTC, Matěj Cepl
no flags Details
Xorg.0.log.old from the archive (6.74 KB, text/plain)
2011-09-27 20:32 UTC, Matěj Cepl
no flags Details
Xorg.1.log from the archive (58.92 KB, text/plain)
2011-09-27 20:33 UTC, Matěj Cepl
no flags Details
Xorg.1.log.old from the archive (59.62 KB, text/plain)
2011-09-27 20:33 UTC, Matěj Cepl
no flags Details

Description Oded Arbel 2011-09-27 09:23:40 UTC
Description of problem:
Every now and then, the display will stop accepting clicks from the mouse - it moves fine but clicking doesn't do anything or behaves very weird.

Version-Release number of selected component (if applicable):
1.11.0-2

How reproducible:
Seldom

Steps to Reproduce:
It just happen in normal work flows and I can't pin down when it happens and when it doesn't.

The problem is that I move the mouse around and the cursor moves fine - not delays or anything (the machine is hardly loaded), but when I try to click or scroll the wheel, nothing on the screen will react to it - desktop icons and panels, application buttons, text selection - nothing behaves as if it is being clicked. Also hover effects do not work - for example in the KDE plasma panel. I've noticed that when the problematic behavior just starts, if I'm using VirtualBox while it happens then it starts to manifest by left clicks triggering RMB in the virtualized desktop, but after a while it stops as well and no more clicking works on VirtualBox. Other things that sometime work is selecting text in the konsole, but not all the text - just what's on the top of the screen - selecting from the bottom of the screen never works. Also when the problem occurs I can always click on the KDE application menu button (though not on any other panel widget) but I can't navigate the application menu - not even with the hover actions on the main sections - just click to open and click to close.

Additional info:
I saw this old bug #4494999, which seems somewhat applicable to what I'm seeing but its not 100% the same behavior and unlike what the commenters on that bug see, this behavior has not stopped in recent Fedora versions. I've seen this on my system in Fedora 14 and 15, and now when I upgraded to 16 beta it still happens. I've the grabtest utility provided in bug #4494999 and when the system behaves correctly I always get "success" for both pointer and keyboard, while when the system doesn't behave I always get "failed" for pointer but not for keyboard.

This may or may not be related to the fact that I am using the Fedora machine in question as a Synergy client (with the keyboard and mouse on another machine running a different Linux OS), but when the problematic behavior happens, if I plug a real mouse into the computer - it still behaves the same as what I'm seeing using Synergy.

I currently workaround the problem by logging off and on again - this resets the behavior back to normal.

Comment 1 Matěj Cepl 2011-09-27 14:59:51 UTC
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log*; check with grep Backtrace /var/log/Xorg* which logs might be the most interesting ones, send us at least Xorg.0.log)
* evtest against the device file (/dev/input/event<exact number by Xorg.0.log>),
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 2 Oded Arbel 2011-09-27 17:03:15 UTC
Created attachment 525173 [details]
xorg.conf.d/00-system-setup-keyboard.conf

Comment 3 Oded Arbel 2011-09-27 17:08:17 UTC
Created attachment 525177 [details]
Xorg log files

The current session is behaving fine (at the moment), and I'm not sure which log file is for the previous session - so I attached Xorg.{0,1}.log{,.old}

Comment 4 Oded Arbel 2011-09-27 17:19:25 UTC
Regarding evtest - normally I control the mouse on the system using Synergy, and I doubt I can run evtest on that. That being said, I installed it and next time the problem happens (probably tomorrow) I'll connect the hardware mouse and run evtest on that. 

Regarding /var/log/messages: I've looked in messages, and I don't see anything that looks to be pertaining to the problem, but the next time it happens I'll capture some output and attach it here.

Comment 5 Matěj Cepl 2011-09-27 20:32:45 UTC
Created attachment 525204 [details]
Xorg.0.log from the archive

Comment 6 Matěj Cepl 2011-09-27 20:32:53 UTC
Created attachment 525205 [details]
Xorg.0.log.old from the archive

Comment 7 Matěj Cepl 2011-09-27 20:33:01 UTC
Created attachment 525206 [details]
Xorg.1.log from the archive

Comment 8 Matěj Cepl 2011-09-27 20:33:18 UTC
Created attachment 525207 [details]
Xorg.1.log.old from the archive

Comment 9 Peter Hutterer 2011-09-28 00:35:39 UTC
(In reply to comment #0)
> my system in Fedora 14 and 15, and now when I upgraded to 16 beta it still
> happens. I've the grabtest utility provided in bug #4494999 and when the system
> behaves correctly I always get "success" for both pointer and keyboard, while
> when the system doesn't behave I always get "failed" for pointer but not for
> keyboard.

this suggests a stuck grab by some client application. We need to find out which application and how this stuck grab is triggered. It could be a bug in the server bug or in the application.

 > This may or may not be related to the fact that I am using the Fedora machine
> in question as a Synergy client (with the keyboard and mouse on another machine
> running a different Linux OS), but when the problematic behavior happens, if I
> plug a real mouse into the computer - it still behaves the same as what I'm
> seeing using Synergy.

The way devices are abstracted in X, if a client has a grab on "the pointer" (basically the system cursor) it has a grab on any device that moves that cursor. Adding or removing devices doesn't help here. A better test would be to kill synergy when this happens so we can rule out synergy causing this issue.

Comment 10 Oded Arbel 2011-09-28 06:36:10 UTC
I'll update as soon as it happens again.

Comment 11 Oded Arbel 2011-10-04 10:46:47 UTC
It just happened again. I have the mouse grabbed and it can't be used to interact with most of the screen. Killing synergy client doesn't solve the problem.

The weird part is that I can still use it to click on the KDE panel applets, interact with menus that pop up from these applets and event interact with the panel's "Add widgets" and "Configure panel" UI. I can't click on the Kicker menu though - I can only open and close it using the Fedora start icon.

I then (by mistake) invoked the "inspect element" feature in the Firebug installed in Firefox, and it managed to grab the mouse. Now the mouse only interacts with the Firefox window. 
..
Other funny behaviors I get are:
- I can invoke KWin's window operations menu (ALT-F3) by default, but I can't interact with it using the mouse, nor using the keyboard: the keyboard focus stays in active application's window content. Other KWin keyboard shortcuts work fine.
- I can basically "drag and drop" the context of "application the mouse can interact with": if I drag something (selected text, tab) from the firefox window over to the KDE panel, I can then interact with the KDE panel. I can then drag something from the panel (for example, the tasks in the "smooth tasks" applet are draggable) over to another window - that window now gains the ability to interact with the mouse.

Comment 12 Oded Arbel 2011-10-04 11:08:23 UTC
After killing any process that could be killed (without losing the session), including kwin, I still could only interact with one application with the mouse (which can still be changed by closing the application, at which point the mouse focus reverts to kwin if its running, or another random application otherwise).

Eventually I had to kill the KDE session which closed X. I think this is an X problem - it may be caused by a rogue application (which I'm not sure yet), but when the mouse gets stuck on one application, it is definitely only X that maintains that behavior.

Comment 13 Oded Arbel 2011-10-04 13:57:38 UTC
This problem is also not KDE specific - I just got it on GNOME shell as well.

Comment 14 Oded Arbel 2011-11-24 08:32:51 UTC
I've installed a new Fedora 16 release (not the beta) and running just GNOME shell and I get the problematic behavior at least once a day. Running grabtest behaves as reported before - failed to grab the pointer.

Also I experience this weird behavior in gnome-terminal when the problem occurs: gnome-terminal's cursor changes when gnome-terminal loses focus, and when the problem occurs - and I change to gnome-terminal using keyboard shortcuts, then you can see that every minute or so the gnome-terminal loses focus - the gnome-terminal cursor becomes an empty rectangle and typing does nothing - and after a few seconds the focus goes back to gnome-terminal. killing some immediate suspects (such as synergy) doesn't solve the problem.

Comment 15 Kiss 2012-01-11 00:50:07 UTC
Hi, I have recently installed Fedora 16 (two days ago) and I have found the same issues listed here. I have noticed a few things I thought might be worth mentioning including how to fix the behavior temporarily. Please excuse my terminology, for my experience with this is very limited. 

If the mouse fails to click/drag when changing from one window to another, I can go back to the previous window, click on its drop-down menu area (file, edit, etc.) or the bar across the top to make sure that area of the window is highlighted (when clicking on another window, even if nothing happens, the top bar on the previous window grays out as if the switch to another window was successful). At this point the functionality of my mouse returns until the next incident.

Comment 16 Kiss 2012-01-11 00:52:32 UTC
Hi, I have recently installed Fedora 16 (two days ago) and I have found the same issues listed here. I have noticed a few things I thought might be worth mentioning including how to fix the behavior temporarily. Please excuse my terminology, for my experience with this is very limited. 

If the mouse fails to click/drag when changing from one window to another, I can go back to the previous window, click on its drop-down menu area (file, edit, etc.) or the bar across the top to make sure that area of the window is highlighted (when clicking on another window, even if nothing happens, the top bar on the previous window grays out as if the switch to another window was successful). At this point the functionality of my mouse returns until the next incident.

Comment 17 mrmag 2012-02-04 09:26:49 UTC
I have the same issues described above on my F16 laptop. Makes the system almost unusable. Any news on this?

Comment 18 Kdrei 2012-06-19 18:30:39 UTC
I'm having the same problem. The problem started yesterday and has grown increasingly worse throught out the day today.

The only thing that I've changed in the past 2 days is that I've added tree style tabbed browsing.

My mouse cursor only gets "frozen" with firefox. It turns into the select tool (the hand) and then can no longer release or select. The only way I've been able to fix it is by rebooting my machine.

I'm using F16 on a lenovo T61.

I'm going to remove my tree style tabbed browsing and see if that fixes it.

Comment 19 Kevin Dreimiller 2012-06-27 20:20:36 UTC
I removed my tree style tabbed browsing and the trouble almost totally cleared.

Comment 20 Kevin Dreimiller 2012-07-13 15:08:58 UTC
(In reply to comment #19)
> I removed my tree style tabbed browsing and the trouble almost totally
> cleared.

I still occassionally have the trouble but in lieu of rebooting I drop into a terminal and kill firefox. It's not the best solution, but it beats a reboot.

Comment 21 Reid Rivenburgh 2012-07-13 15:26:03 UTC
(In reply to comment #20)
> I still occassionally have the trouble but in lieu of rebooting I drop into
> a terminal and kill firefox. It's not the best solution, but it beats a
> reboot.

I see it fairly frequently here with firefox.  It seems to happen anytime I initiate a drag 'n' drop of an image (and maybe other things?).  Like you, I go to a different terminal with alt+ctrl+F2 and kill firefox, which fixes it, but it's a hassle.  I had never seen this behavior until about 2 months ago.  (I'm still on F16; I think it started with firefox 13.)

Comment 22 Lopas Johnson 2012-08-11 17:12:16 UTC
Also have this bug for some time on F16. Temporarily solved only by terminating Firefox (terminating the plugin container doesn't solve the issue).
Xorg logs say nothing usefull.
Usually, it happens when a new, somewhat heavy page is loaded.

Comment 23 Reid Rivenburgh 2012-08-11 22:29:34 UTC
This no longer happens for me.  It seems related to updating to Firefox 14.0.1 (as a non-rpm install), but I'm not sure.

Comment 24 m-redhat 2012-08-14 16:23:40 UTC
I'm glad I finally found this bug report! I'm running F16 and this problem is SO annoying -- it's happening for me every one or two days, sometimes even several times per day. At first I thought it must be a problem with the new GNOME Shell, but now it even started after having switched to Xfce/XMonad.

I did NOT have firefox running (I did have Chrome running). Other applications running were: a few urxvt instancen, two instances of evince, ssh, xcompmgr and a few desktop services.

I would be so happy if this bug was found/fixed.

Thank you,
mel

Comment 25 mrmag 2012-08-14 17:18:46 UTC
Uninstalling wine and a couple of wine applications seem to have made the problem disappear on my laptop. Not sure if wine or the windows applications was actually the problem, but my laptop is usable again. At least for now...

Comment 26 m-redhat 2012-08-14 17:41:49 UTC
I'm not running Wine!

Comment 27 Kiss 2012-08-14 21:34:08 UTC
I have this issue a lot.  Switching windows at all is a hassle and I'm not sure F16 is the source of the issue because I tried installing Ubuntu and it has exactly the same issue.  

When I'm on a window, if I want to switch to another and still use the mouse, I have to click the bar at the top and drag the window.  At which point I am able to swap windows and use the mouse just fine.

The issue you guys seem to be having looks related to mine, although I'm not 100% confident it actually is.  I'm new to Linux in general and would appreciate any ideas thrown my way.

Comment 28 Greta Watson 2012-09-11 19:23:11 UTC
The pointer freeze has happened twice so far today, both times when I minimized all my windows, leaving a blank screen.  The mouse and <alt><tab> became unresponsive; non-pointer keyboard functions seem to continue working.  To get the mouse working again, I had to kill the X server and log in again.

I'm running Fedora 16:  3.4.9-2.fc16.x86_64.

Components:
xorg-x11-server-utils-7.5-7.fc16.x86_64
xorg-x11-server-common-1.11.4-3.fc16.x86_64
xorg-x11-server-Xorg-1.11.4-3.fc16.x86_64
xorg-x11-server-Xephyr-1.11.4-3.fc16.x86_64

Comment 29 Greta Watson 2012-09-17 15:12:12 UTC
This freeze is now happening multiple times a day.  The severity is such that I may have to go to another operating system.

I use KDE.  My panel has the menu icon; Konsole, Firefox, and Thunderbird icons.  In the taskbar area, I have two konsoles, firefox, and thunderbird, unsorted and not grouped.  Notification area has sound volume and connectivity status always showing.  Digital clock includes seconds and long date.  There are no widgets on my single desktop.

When I have more than one of the four tasks open, I'm usually safe.  When I minimize the last of the four windows, using the minimize button on the window, the freeze often occurs.  However, if I click on the icon/description in the taskbar on the panel to minimize the window, the freeze does not seem to occur.

Comment 30 Greta Watson 2012-09-22 03:56:27 UTC
Did a fresh install of Fedora 17.  Problem does not seem to occur on Fedora 17.

Comment 31 Fedora End Of Life 2013-01-16 16:53:58 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 32 Fedora End Of Life 2013-02-13 21:01:56 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.