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):
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
Display still active, but no response to keyboard input or mouse button presses;
sometimes ctl-alt-bs will kill X.
Normal usage of XFCE
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).
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
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?
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.
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.
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
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.
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
Removed by "rpm --nodeps -e `rpm -qa|grep ^gtk2`" and installed older gtk2 from
Guys please inform xfce4 developers with this bug.
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?
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?
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).
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?
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.
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. ;)
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
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?
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.
Excellent. Thanks for testing. I will update upstream.
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.