Bug 741553

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.

Created attachment 525173 [details]
xorg.conf.d/00-system-setup-keyboard.conf

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}

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.

Created attachment 525204 [details]
Xorg.0.log from the archive

Created attachment 525205 [details]
Xorg.0.log.old from the archive

Created attachment 525206 [details]
Xorg.1.log from the archive

Created attachment 525207 [details]
Xorg.1.log.old from the archive

(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.

I'll update as soon as it happens again.

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.

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.

This problem is also not KDE specific - I just got it on GNOME shell as well.

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.

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.

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.

I have the same issues described above on my F16 laptop. Makes the system almost unusable. Any news on this?

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.

I removed my tree style tabbed browsing and the trouble almost totally cleared.

(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.

(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.)

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.

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.

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

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...

I'm not running Wine!

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.

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

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.

Did a fresh install of Fedora 17.  Problem does not seem to occur on Fedora 17.

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

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.