Bug 243735 - XFCE stops responding to keypress/mouse button events
Summary: XFCE stops responding to keypress/mouse button events
Alias: None
Product: Fedora
Classification: Fedora
Component: xfwm4   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-11 15:43 UTC by Clark Williams
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-09 20:51:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Clark Williams 2007-06-11 15:43:58 UTC
Description of problem:
After running for some time, the graphics system stops processing key presses
and mouse button events. Mouse cursor still tracks; sometimes ctl-alt-bs will
kill X, sometimes not. 

Not really sure that this is a Window Manager problem

Running devel version of xfce on T60 laptop (Core2-Duo). 

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


How reproducible:
fairly reproducible, just random time until failure

Steps to Reproduce:
1. Boot into rawhide Fedora kernel
2. Login to XFCE
3. Wait for keyboard/mouse buttons to stop responding
Actual results:

Display still active, but no response to keyboard input or mouse button presses;
sometimes ctl-alt-bs will kill X.

Expected results:
Normal usage of XFCE

Additional info:

As I said, not sure that WM is actually the culprit. Switching to GNOME does not
seem to trigger this, so I do think it's an XFCE issue.

Next time it happens I'll try ssh'ing into the laptop to insure that the rest of
the system is running (pretty sure it is).

Comment 1 Kevin Fenzi 2007-06-11 17:11:52 UTC
Very odd. Sounds like something is grabbing your keyboard/mouse and not letting
go. Are you running xscreensaver?

I have been running here on a core2duo laptop for ages 24x7 and have never seen

Comment 2 Clark Williams 2007-06-11 18:19:13 UTC
It does sound like something has grabbed and not let go, since everything else
seems to work. I finally setup sshd so that I can login to the laptop through
the net, so I'll swap back to XFCE and try it again. 

I do have xscreensaver enabled, but this seems to happen while I'm active. I'll
be typing or doing mouse things and suddenly hitting mouse button in a window's
header doesn't swap focus. 

Is there anything I can do if I get logged in to see if something has grabbed
focus? Also, are you running 32-bit or 64-bit?


Comment 3 Kevin Fenzi 2007-06-11 18:29:40 UTC
Yeah, not sure how to determine what process has the keyboard grabbed from remote. 

Might be some clever way with devilspie or something... 
Or perhaps you could start a 'xev >& /tmp/foobar' and then examine that to see
what has grabbed?

I am running x86_64 here. 

Comment 4 Clark Williams 2007-06-12 03:56:26 UTC
Tried it again tonight, had a couple of terminals open, Thunderbird and pidgin
running. When I lost input, I went to a different laptop, ssh'ed in to the
"locked" box. Running 'top' didn't show me anything spinning out of control
(didn't really expect it). Things did seem to be a trifle..."jerky", kinda like
running over a slow communications channel. After a while, the ssh  session
stopped responding and further attempts to login failed with "no response". 

I may try the xev trick next.

Comment 5 Kevin Fenzi 2007-06-12 04:17:16 UTC
Still very puzzled on this one. I use pidgin here just fine. The only app I
don't use that you have mentioned is thunderbird. 

Is there nothing in your /var/log/messages, /var/log/Xorg.0.log, or
~/.xsession-errors files?

Comment 6 denis ivanov 2007-06-16 22:17:14 UTC
Got the same problem after updating 1-month-old rawhide to today's

Waste some hours to find the problem. Tries to turn back xfce4-panel, libwnck,
notification libs etc. No results.

How to reproduce? Very simple.

2 facts:

1) task switching via Alt-Tab works fine
2) task switching via panel's task manager works fine

But if you combine 1 and 2, xfwm hangs!!!

So to reproduce just run several tasks and try to switch by alt-tab, by task
manager with mouse and you will got 100% result...

After a hours of having sex with fedora, just found the problem is with gtk2
libs !!!

Removed by "rpm --nodeps -e `rpm -qa|grep ^gtk2`" and installed older gtk2 from
fedora7 base.





Guys please inform xfce4 developers with this bug.

Comment 7 Kevin Fenzi 2007-06-17 02:34:58 UTC
Ah ha. Excellent detective work. 

I wonder if it's just a rebuild of xfwm4 against the new gtk2 that would fix

Would you guys be willing and able to test a rebuilt xfwm4 package? 
I can easily make one, or you can rpmbuild --rebuild the src.rpm and try it?

Comment 8 Clark Williams 2007-06-17 04:13:16 UTC
Doesn't seem to. I grabbed the xfwm4-4.4.1-1 SRPM and rebuilt it on the current
rawhide (gtk2-2.11.3-1.fc8). Started up xfce and I went nuts swapping workspaces
(using scroll-wheel, pager and alt-tab. After about a minute, it hung again.

Just out of idle curiosity, how would I verify that xfwm4 is what hung on my box?

Comment 9 Clark Williams 2007-06-17 15:00:36 UTC
Just to confirm Denis' workaround, I downgraded my gtk2* as listed above and
have been running fine for over an hour (because I make heavy use of workspaces,
I usually lock up in a minute or two). 

Comment 10 Kevin Fenzi 2007-06-18 04:26:32 UTC
Filed upstream bug: http://bugzilla.xfce.org/show_bug.cgi?id=3346

For checking to make sure it's xfwm4 you could try doing a strace on it? 

Comment 11 denis ivanov 2007-06-18 21:26:58 UTC
This is bug of combination of xfwm4 + xfce4-panel + gtk2_from_rawhide.
Without panel all is ok.

Strace on xfwm4 hangs on poll()

Very strange bug.

Comment 12 denis ivanov 2007-06-18 21:52:15 UTC
glib2-2.13.4-1.fc8 is also buggy with xfce Terminal (Terminal-0.2.6-2.fc7)

The problem when you opening several tabs and finish some of it by Ctrl-C,
Terminal may fall to core dump...

Back to glib2-2.12.11-1.fc7 solved this issue!

Seems rawhide packages is tested not so enough. ;)

Comment 13 Clark Williams 2007-06-25 16:19:43 UTC
I had this happen on a rawhide i686 laptop this weekend, so it seems to
transcend architecture. did the downgrade of gtk2* to f7 versions and it worked

Comment 14 Kevin Fenzi 2007-06-25 18:04:42 UTC
Well, upstream has identified the problem and has a patch. 
They are talking about if this is important enough to push a 4.4.2 release now. 

Can all of you guys who are seeing this re-upgrade your gtk2 and try the rpms from: 


and report back if that fixes the issue or not?

Comment 15 Clark Williams 2007-06-28 19:30:07 UTC
I updated to xfwm4-4.4.1-2.fc8 from the above link and then updated to the
latest gtk2, gtk2-devel and gtk2-engines and that seems to have fixed my problem. 

At least I've been running for an hour, switching workspaces and generally just
working without the system losing mouse/keyboard events. 

Comment 16 Kevin Fenzi 2007-06-28 20:13:46 UTC
Excellent. Thanks for testing. I will update upstream. 

Comment 17 Kevin Fenzi 2007-07-09 20:51:17 UTC
ok, since it's looking like 4.4.2 is going to take somewhat longer to be
released than I had hoped, I went ahead and added this patch into xfwm4 in rawhide. 

Package: xfwm4-4.4.1-2.fc8 Tag: dist-f8 Status: complete Built by: kevin

Should be out in tomorrow's rawhide push. 
Feel free to re-open this or file a new bug if you spot any problems with this fix. 

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