please run http://people.freedesktop.org/~whot/grabtest.c and report the
output here.

Right now when keyboard is OK this application outputs:

Grabbing pointer ... success.
Grabbing keyboard ... success.

I'll report later when I face my issue again.

Grabbing pointer ... FAILED (1)
Grabbing keyboard ... success.

> --- Comment #3 from Artem S. Tashkinov <t.artem@mailcity.com>  2009-04-15 22:06:05 PST ---
> Grabbing pointer ... FAILED (1)
> Grabbing keyboard ... success.

right. so some app has the pointer grabbed and doesn't release it. At this
point, there's still a chance that the server screws up and doesn't release it
properly, but that's less likely than an app simply misbehaving.
Can you narrow down which application it might be?

Created attachment 24841 [details]
X.org log N2

If you read the X.org I provided you could have noticed that X.org itself lost the keyboard.

This problem occurs e.g. when I'm browsing a webpage or type something in KDE4's konsole - i.e. it doesn't happen when I start a new application, it sometimes it happens during _idle_ periods.

> If you read the X.org I provided you could have noticed that X.org itself lost
> the keyboard.
> 
> This problem occurs e.g. when I'm browsing a webpage or type something in
> KDE4's konsole - i.e. it doesn't happen when I start a new application, it
> sometimes it happens during _idle_ periods.

hmm. this log is weird. It looks similar to when the server suspends, but not
quite the same.

the usual question - does it happen with the nv driver too?

On Wed, Apr 15, 2009 at 10:40:45PM -0700, bugzilla-daemon@freedesktop.org wrote:
> If you read the X.org I provided you could have noticed that X.org itself lost
> the keyboard.

It shows all input devices being closed and subsequently being reopened
(i.e. working just as it should).  I assume this comes from a suspend to
RAM operation?

No, the last attached log file was generated for the last 12 hours and I _never_ shut down my PC (because it's half workstation, half LAN file server). I have no idea what generates those attach/de-attach X.org messages (however sometimes I switch to tty2 to do something there) - could it be that KonsoleKit does some nasty things? However I cannot blame KonsoleKit since keyboard gets lost in a middle of nowhere - e.g. when I do nothing.

Is there a way to write an application which will show what has grabbed a keyboard/pointer/whatever?

Or, BTW, I've just recollected one thing: the same problem occurs with the following X.org configuration:

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Module"
        Load  "dbe"
        Load  "extmod"
        Load  "dri"
        Load  "glx"
EndSection

Section "ServerFlags"
        Option "DontZoom"
        Option "AutoAddDevices" "false"
        Option "AllowEmptyInput" "false"
        Option "AutoEnableDevices" "false"
EndSection

Section "InputDevice"
        Identifier      "Keyboard0"
        Driver          "kbd"
        Option          "XkbModel"              "pc105"
        Option          "XkbLayout"             "us,ru"
        Option          "XkbOptions"            "grp:alt_shift_toggle,grp_led:scroll"
        Option          "Xleds"                 "1 2 3"
        Option          "XkbVariant"            ",winkeys"
EndSection

Section "InputDevice"
        Identifier      "Mouse0"
        Driver          "mouse"
        Option          "Protocol" "auto"
        Option          "Device"   "/dev/input/mice"
        Option          "ZAxisMapping"  "4 5"
EndSection

...

i.e. when my input devices are _not_ driven by HAL.

> --- Comment #8 from Artem S. Tashkinov <t.artem@mailcity.com>  2009-04-15 23:23:13 PST ---
> No, the last attached log file was generated for the last 12 hours and I
> _never_ shut down my PC (because it's half workstation, half LAN file server).
> I have no idea what generates those attach/de-attach X.org messages (however
> sometimes I switch to tty2 to do something there) 

oh, that explains it.
when you vt-switch, all input devices are disabled and then re-enabled when
you come back. This is what ends up in the log files. The server doesn't
actually lose the devices in that case (that was what confused me, when the
server loses a device the log looks differnt). 

> Is there a way to write an application which will show what has grabbed a
> keyboard/pointer/whatever?

no, only the server knows this information. ajax wrote a patch for this but
it's not upstream (yet). It might help you though.
http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch

(In reply to comment #9)
> 
> oh, that explains it.
> when you vt-switch, all input devices are disabled and then re-enabled when
> you come back. This is what ends up in the log files. The server doesn't
> actually lose the devices in that case (that was what confused me, when the
> server loses a device the log looks differnt). 

Or does it? Why should X.org release input devices when I switch to another terminal? Why does keyboard disappear *long after* I returned to a running X.org session? Why haldaemon restart have no effect on X.org input devices state and instead it says:
(WW) config/hal: device AT Translated Set 2 keyboard already added. Ignoring.

Besides like I've already said the same thing happens with static input devices declaration.

> 
> no, only the server knows this information. ajax wrote a patch for this but
> it's not upstream (yet). It might help you though.
> http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch
> 

What package should I recompile? :) How can I enable debugging or it's enabled by default?

> Or does it? Why should X.org release input devices when I switch to another
> terminal?

disabling simply means "close the fd, don't listen for events from this
device". which is needed, otherwise you'd still be moving your mouse around or
type into whatever app has the focus in the server that has been switched
away.

> Why does keyboard disappear *long after* I returned to a running
> X.org session?

this is what we need to find out. from the log file, I can't see the device
disappearing though and the fact that the grab fails indicates that there's
some app capturing it.
also, physical devices != the X keyboard. if you plug in a second keyboard,
you'd probably notice that the other one doesn't work either when this happens.

> Why haldaemon restart have no effect on X.org input devices
> state and instead it says:
> (WW) config/hal: device AT Translated Set 2 keyboard already added. Ignoring.

when you restart hal, it provides the list of devices to the server. since the
server has the list already, it doesn't add the devices again.

> Besides like I've already said the same thing happens with static input devices
> declaration.

yeah, static devices are disabled too when you vt switch. This part hasn't
been affected by the input hotplugging code.

> > 
> > no, only the server knows this information. ajax wrote a patch for this but
> > it's not upstream (yet). It might help you though.
> > http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch
> > 
> 
> What package should I recompile? :) How can I enable debugging or it's enabled
> by default?

best approach would be to get the source package of your respective
distribution, apply the patch, and compile that one up.

(In reply to comment #6)
> 
> the usual question - does it happen with the nv driver too?
> 

It happens with nv/nvidia and vesa drivers. :(

This patch doesn't work with X.org server 1.5.3 (it applies with warnings but I cannot compile X server):

xf86Events.c: In function ‘kvetch_about_client’:
xf86Events.c:673: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘Mask’
xf86Events.c: In function ‘xf86VTSwitch’:
xf86Events.c:816: error: ‘struct _DeviceIntRec’ has no member named ‘deviceGrab’
xf86Events.c:818: error: ‘struct _DeviceIntRec’ has no member named ‘deviceGrab’
make[5]: *** [xf86Events.lo] Error 1

Can you please rebase it against older (my) X.org (1.5.3)? Or I need to apply some other patches?

I'm compiling xorg-x11-server-1.5.3-15.fc10.src.rpm

Peter?

just replace occurances of 'dev->deviceGrab.grab' with 'dev->grab'. That
should do.

I'm encountering this too. I'm entirely nvidia-free, so it's not that.

I applied the patch, which made X segfault immediately upon startup. I changed the if statements to check that grabinfo isn't NULL, and do nothing if it is.

When the lockup occurs, doing a chvt yields this:

Resource mask 0x00a00000 device name "Virtual core keyboard" euid 1000 egid 1000 pid 21825"

What further information should I provide?

I hit this again, and this time:

Resource mask 0x01600000 device name "Virtual core pointer" euid 1000 egid 100 pid 7366

so I'm not sure that we're on the right track here.

in most cases I've seen when this happens it seems to be a stuck grab with metacity. killall metacity from the commandline releases the keyboard/pointer again.

We don't have a reproducible testcase though, making hard to debug.

I'm not sure that it's even a stuck keygrab. The past few times I've hit this, nothing's had a keygrab held at all.

Ciaran, I strongly suggest upgrading to Fedora 11 because since I did this the bug had disappeared.

I'm not sure if this is the same issue, but I have encountered a dead keyboard a few times recently.  I only have a radeon and an intel, so no nv here.  Also, I use KDE.

I think the only reason I could encounter this is because of the problems my machines have with the new drivers, drawing things (especially plasma style popups) with big delay and increased CPU use from X.

So, I'm used to alt-tabbing quickly, not looking at the box but going blindly.  I noticed several times that the keyboard would die if I released Alt just before the switch box popped up.  The key wasn't regarded as pressed down, however, as nothing that looks like Alt+something else would happen either.  The keyboard was just plain dead.

I have exact problem as comment#21, looks like <Alt><Tab> is related.

> I have exact problem as comment#21, looks like <Alt><Tab> is related.
Forgot to specify versions...

x11-base/xorg-server-1.7.1
x11-drivers/xf86-input-evdev-2.3.0
linux-2.6.31

Just wanted to post to say that I also am having this issue.
I mostly notice it when I am typing in firefox and the input stops.  Although, sometimes I notice it after I switch to a Konsole and input doesn't work.

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Slackware 13.0 Slackware Linux Project
Current Operating System: Linux bacon 2.6.29.6 #2 SMP Mon Aug 17 11:58:18 CDT 2009 x86_64
Build Date: 03 August 2009  07:39:15PM

Peter, where can I download grabtest.c?

Can you hack a version which shows which application has actually grabbed the keyboard?

I'm again having this problem with xorg-x11-server-Xorg-1.7.5 RC1 and Intel Graphics, it is very irritating and frustrating.

(In reply to comment #25)
> Peter, where can I download grabtest.c?
sorry, got wiped when $HOME was lost, on http://people.freedesktop.org/~whot/grabtest.c again

> Can you hack a version which shows which application has actually grabbed the
> keyboard?

not really, this is information that only the server has available and clients cannot have access to it. It would require some changes in the server. I think ajax had a patch at some point that displayed client IDs with an active grab on a VT switch. Not sure where that went though.

(In reply to comment #26)
> I think
> ajax had a patch at some point that displayed client IDs with an active grab on
> a VT switch. Not sure where that went though.
> 

Can you talk to him about this problem? I'd be glad to patch my X server to investigate this long-standing issue.

Anyone?

Still having this issue.

x11-base/xorg-server-1.7.6
x11-drivers/xf86-input-evdev-2.3.2
x11-drivers/xf86-video-intel-2.11.0
linux-2.6.33

(In reply to comment #28)
> Anyone?
> 
> Still having this issue.
> 
> x11-base/xorg-server-1.7.6
> x11-drivers/xf86-input-evdev-2.3.2
> x11-drivers/xf86-video-intel-2.11.0
> linux-2.6.33

Write to xorg mailing list, maybe your problem will get noticed.

Judging by other bug reports I've come across, freedesktop's bugzilla is mostly afunctional.

Created attachment 35314 [details] [review]
New version of xserver-grab-debugging.patch fixing 2 segmentation faults

xserver-grab-debugging.patch has two bugs: it crashs (segmentation fault) if grabinfo==NULL and if clients[i]==NULL. The new version of the patch doesn't crash anymore.

Using my timestamp patch (issue #26180), I get logs like that:
...
2010-04-27 13:47:53 (II) Power Button: Device reopened after 1 attempts.
2010-04-27 13:47:53 (II) Power Button: Device reopened after 1 attempts.
2010-04-27 13:47:53 (II) Logitech USB Receiver: Device reopened after 1 attempts.
2010-04-27 13:47:53 (II) Dell Dell USB Keyboard: Device reopened after 1 attempts.
2010-04-27 15:20:37 (II) AIGLX: Suspending AIGLX clients for VT switch
2010-04-27 15:20:37 Client holding device grab at VT switch:
2010-04-27 15:20:37 Resource mask 0x03c00000 device name "Virtual core pointer" euid 1000 egid 1000 pid 10381
2010-04-27 15:20:37
2010-04-27 15:20:37 Client holding device grab at VT switch:
2010-04-27 15:20:37 Resource mask 0x03c00000 device name "Virtual core keyboard" euid 1000 egid 1000 pid 10381
2010-04-27 15:20:37
...

Since summer 2009, I loose sometimes my keyboard. It occurs after a period between 5 hours and 3 weeks (it's usually a least 1 week) :-/ I don't know the reason. I read Xorg.0.log, syslog, messages and other log files, but there is no revelant information.

It's not an hardware problem because if I switch to text mode (CTRL+ALT+f1) the keyboard is still working, and if I read /dev/input/<my keyboard id> I see keystrokes.

Between summer 2009 and march 2010, I used Synergy and I suppose that some keyboard hung were caused by Synergy (which grabs the keyboad and the pointer): I got some "Mar 4 01:15:06 marge Synergy 1.3.1: WARNING: CServer.cpp,467: can't leave screen" errors in synergy server logs.

Now I'm suspecting Gajim, a Jabber client, but I don't see when/how it would grab the keyboard. Keyboard hung never occured while I was typing in Gajim: Gajim was already minimized in the systray. I tried Gajim in gdb and I saw that Gtk+ calls XGrabKeyboard and XGrabPointer when displaying a menu, and XUngrabKeyboard and XUngrapPointer when hiding the menu. I'm now running Gajim in verbose mode in gdb with breakpoints on XGrabKeyboard/XUngrabKeyboard displaying timestamp when the functions are called. If the bug is related to Gajim, it can be related the network lantency.

I patched Xorg to write logs with timestamps and to log the application grabing the keyboard/pointer (xserver-grab-debugging-2.patch). And I prepared the test program grabtest(.c).

Now I'm waiting a new hung, but the problem is that it occurs randomly :-/

--

Versions:
 - Debian Sid
 - Xorg server 1.7.6.901
 - evdev 2.3.2
 - xserver-xorg-video-intel 2.9.1
 - Linux kernel 2.6.32
 - Intel(R) Pentium(R) 4 CPU 3.00GHz (with hyperthreading: 2 virtual cores)

Tell me if you need more information.

--

When I tried to get more informations, Xorg does sometimes crash (when switch between text mode and Xorg) because of another bug: #27114 (related to Intel driver?). It makes debug worse :-/

The bug is really annoying, but as a developer I know that this "detail" is useless :-)

Got it! My keyboard is blocked. Switching to text mode wrote me the application grabbing the keyboard: kwin! I restarted KDE and ran kwin in gdb with breakpoints to XGrabKeyboard and XUngrabKeyboard.

As Henrik Pauli noticed (in comment 21), kwin grabs the keyboard when pressing ALT-tab and ungrabs when releasing ALT-tab.

I don't remember if was switching between the windows with ALT-Tab, but I see in gdb that ALT-Tab grabs/ungrabs the keyboard.

kwin grabs also the keyboard for other reasons:
 - ALT+left click (move a window): ungrab when releasing ALT or the click
 - ALT+right click (resize a window): ungrab when releasing ALT or the click
 - Right click on window title (contextual menu): ungrab when clicking outside the menu or when clicking on a menu item. (Re-grab the keyboard when entering a submenu)

Thank you Victor!

It is indeed kwin.
Had it, switch to console, killed kwin, returned to X and keyboard works.

The question is: what was changed in xorg-7.4, as it worked perfectly until and including xorg-7.3.

I guess it has nothing to do with evdev...

Opened correlated bug in kde:
https://bugs.kde.org/show_bug.cgi?id=235606

Anyone here has this issue and not use kde?

IMO Xorg's keyboard handling is completely broken if this issue happens at all - no other OS I've ever dealt with has this bug.

And yes, for me this bug only occurs in KDE environment, but I didn't have time to test anything else.

And the most mysterious issue is that [it] occurs [for me] in moments of complete idleness, i.e. when I am not pressing any keyboard buttons, e.g. when I am reading a web page in Firefox, then all of a sudden keyboard stops functioning, so I bet there's a bigger issue than just KWin not releasing keyboard due to yet unknown reasons - judging from the number of people subscribed to this bug report only few people in the world have this problem or maybe all others think it's a hardware problem and they just reboot their PCs ...

There's an interesting blog post here:

http://blogs.sun.com/alanc/entry/grabbing_information_from_the_x

"Grabbing information from the X server"

Probably it would be better to CC this developer but I don't know his e-mail on freedesktop.org (if he has any).

I'm adding Alan Coopersmith to the CC list :) I hope he doesn't mind.

(In reply to comment #38)
> There's an interesting blog post here:
> 
> http://blogs.sun.com/alanc/entry/grabbing_information_from_the_x
> 
> "Grabbing information from the X server"

That describes how to use a module for Solaris's mdb debugger to get
information similar to the grab-debugging patch discussed above.
To use it, you'd either need to reinstall your computers with 
OpenSolaris instead of Linux and see if you can still reproduce (which
may be harder since OpenSolaris only includes GNOME, not KDE), or port
to a Linux debugger like gdb - but then you'd be at the same point as
you were with the grab-debugging patch.

It won't help at all if the problem is not a grab but the device being
closed and failing to reopen, as was suggested in some of the early 
comments.

(In reply to comment #40)
> It won't help at all if the problem is not a grab but the device being
> closed and failing to reopen, as was suggested in some of the early 
> comments.

per comment#35, and the recommendation of KDE, I switched to kde-4.4.3 and so far (a week) did not experienced this. But still need to wait longer as sometimes it took more to reproduce.

I will update when I reach to a conclusion.

I was encountering it without KDE running at all, so I doubt it's that. But I've not seen it for ages, so I don't think I can be of any more help here.

This bug report hasn't had any activity for the past 10 months, does anyone still have this issue?

(In reply to comment #43)
> This bug report hasn't had any activity for the past 10 months, does anyone
> still have this issue?

Since upgrading KDE it was fixed, for me at least.

(In reply to comment #43)
> This bug report hasn't had any activity for the past 10 months, does anyone
> still have this issue?

Nope, same thing as comment #44 said.  KDE 4.4 fixed it, according to https://bugs.kde.org/show_bug.cgi?id=235606

That said, there's still the concern raised in comment #37, and I'd be curious if anything has been touched in this part of X11 since that time.

I'm experiencing this issue now, running:
x11-base/xorg-server-1.13.1
x11-drivers/xf86-input-mouse-1.8.1
x11-drivers/xf86-input-synaptics-1.6.2-r1
x11-drivers/xf86-input-keyboard-1.6.2
x11-drivers/xf86-input-evdev-2.7.3

KDE 4.10.1
Kernel 3.8.2
I couldn't solve the issue by killing and restarting kwin from a VT.
grabtest.c shows both results as failed (I added "sleep 5" before calling it to switch to X back first).

Any ideas what else to do?

(In reply to comment #46)
> I'm experiencing this issue now, […]

Should have probably added some information, when it is happening.
It looks like it never happened while I was actively using the computer, but only when leaving it for a while or after suspend/resume.

Should I find a better way to reproduce this issue, I'll definitely let you know.

(In reply to comment #46)
> 
> Any ideas what else to do?

In a few years this bug will dissolve and resolve itself when we switch to Wayland.

X.org input model allows this to happen and there's nothing you can really do.

It looks like this is another KDE bug which I filed here:
https://bugs.kde.org/show_bug.cgi?id=316797

As it seems, all occurences of this bug are caused by other components and never by X itself, we should close this bug as UPSTREAM - any objections?

based on comment #49 I'm closing this

(In reply to Peter Hutterer from comment #50)
> based on comment #49 I'm closing this

As much as I respect you, the X.org protocol allows this situation to happen in principle, so while I don't wanna argue about the bug state (open/closed/whatever) I wouldn't say "IT'S NOT OUR BUG" because clearly it is, and I guess nothing can be done about it.

I'm marking it as such if you don't mind.