Bug 21141 - X.org constantly loses keyboard (input)
Summary: X.org constantly loses keyboard (input)
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 7.4 (2008.09)
Hardware: x86 (IA32) Linux (All)
: highest blocker
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-12 18:14 UTC by Artem S. Tashkinov
Modified: 2017-02-22 08:17 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments
X.org log (6.44 KB, application/octet-stream)
2009-04-12 18:14 UTC, Artem S. Tashkinov
no flags Details
X.org log N2 (16.11 KB, text/plain)
2009-04-15 22:40 UTC, Artem S. Tashkinov
no flags Details
New version of xserver-grab-debugging.patch fixing 2 segmentation faults (3.01 KB, patch)
2010-04-27 13:18 UTC, Victor Stinner
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Artem S. Tashkinov 2009-04-12 18:14:23 UTC
Created attachment 24738 [details]
X.org log

With any video driver (nvidia, nv, vesa) and any kernel version X.org constantly loses keyboard input (it may happen three times a day). However if I manage to switch to a text console (vt1-6) or start a new X session (X :1) then keyboard is working. If I restart X server in this session then keyboard returns to life.

If I run xev in this "keyboard hung" session then xev shows zero events coming from keyboard. Alt+F1/Ctrl-Backspace/any other combination of symbols also doesn't work.

Relevant packages information:

xorg-x11-server-Xorg-1.5.3-15.fc10.i386
xorg-x11-drv-keyboard-1.3.2-1.fc10.i386
xorg-x11-drv-evdev-2.1.3-1.fc10.i386
libX11-1.1.5-3.fc10.i386

I can post any hardware information you need, I can debug whatever you need.
Comment 1 Peter Hutterer 2009-04-12 18:40:35 UTC
please run http://people.freedesktop.org/~whot/grabtest.c and report the
output here.
Comment 2 Artem S. Tashkinov 2009-04-13 02:40:45 UTC
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.
Comment 3 Artem S. Tashkinov 2009-04-15 22:06:05 UTC
Grabbing pointer ... FAILED (1)
Grabbing keyboard ... success.
Comment 4 Peter Hutterer 2009-04-15 22:13:25 UTC
> --- 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?
Comment 5 Artem S. Tashkinov 2009-04-15 22:40:43 UTC
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.
Comment 6 Peter Hutterer 2009-04-15 23:07:50 UTC
> 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?
Comment 7 Daniel Stone 2009-04-15 23:11:02 UTC
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?
Comment 8 Artem S. Tashkinov 2009-04-15 23:23:13 UTC
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 9 Peter Hutterer 2009-04-15 23:31:26 UTC
> --- 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
Comment 10 Artem S. Tashkinov 2009-04-15 23:43:12 UTC
(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?
Comment 11 Peter Hutterer 2009-04-15 23:57:38 UTC
> 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.
Comment 12 Artem S. Tashkinov 2009-04-16 00:31:39 UTC
(In reply to comment #6)
> 
> the usual question - does it happen with the nv driver too?
> 

It happens with nv/nvidia and vesa drivers. :(
Comment 13 Artem S. Tashkinov 2009-04-16 00:35:24 UTC
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
Comment 14 Artem S. Tashkinov 2009-04-23 09:50:39 UTC
Peter?
Comment 15 Peter Hutterer 2009-04-23 15:01:38 UTC
just replace occurances of 'dev->deviceGrab.grab' with 'dev->grab'. That
should do.
Comment 16 Ciaran McCreesh 2009-08-13 11:09:36 UTC
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?
Comment 17 Ciaran McCreesh 2009-08-16 11:49:13 UTC
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.
Comment 18 Peter Hutterer 2009-08-17 20:11:53 UTC
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.
Comment 19 Ciaran McCreesh 2009-08-24 12:23:34 UTC
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.
Comment 20 Artem S. Tashkinov 2009-08-24 21:49:26 UTC
Ciaran, I strongly suggest upgrading to Fedora 11 because since I did this the bug had disappeared.
Comment 21 Henrik Pauli 2009-10-26 10:21:18 UTC
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.
Comment 22 Alon Bar-Lev 2009-11-11 02:29:52 UTC
I have exact problem as comment#21, looks like <Alt><Tab> is related.
Comment 23 Alon Bar-Lev 2009-11-11 03:11:55 UTC
> 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
Comment 24 Chris Lawrence 2010-01-19 17:53:01 UTC
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
Comment 25 Artem S. Tashkinov 2010-03-12 03:05:16 UTC
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.
Comment 26 Peter Hutterer 2010-03-18 19:45:57 UTC
(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.
Comment 27 Artem S. Tashkinov 2010-03-18 23:24:32 UTC
(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.
Comment 28 Alon Bar-Lev 2010-04-25 04:33:32 UTC
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
Comment 29 Artem S. Tashkinov 2010-04-25 06:52:09 UTC
(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.
Comment 30 Victor Stinner 2010-04-27 13:18:11 UTC
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
...
Comment 31 Victor Stinner 2010-04-27 13:36:55 UTC
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 :-)
Comment 32 Victor Stinner 2010-04-27 15:19:04 UTC
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.
Comment 33 Victor Stinner 2010-04-27 15:49:25 UTC
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)
Comment 34 Alon Bar-Lev 2010-04-28 01:17:59 UTC
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...
Comment 35 Alon Bar-Lev 2010-04-28 01:40:18 UTC
Opened correlated bug in kde:
https://bugs.kde.org/show_bug.cgi?id=235606
Comment 36 Alon Bar-Lev 2010-04-28 01:40:35 UTC
Anyone here has this issue and not use kde?
Comment 37 Artem S. Tashkinov 2010-04-28 02:07:12 UTC
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 ...
Comment 38 Artem S. Tashkinov 2010-06-01 14:06:08 UTC
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).
Comment 39 Artem S. Tashkinov 2010-06-01 14:07:54 UTC
I'm adding Alan Coopersmith to the CC list :) I hope he doesn't mind.
Comment 40 Alan Coopersmith 2010-06-02 07:28:25 UTC
(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.
Comment 41 Alon Bar-Lev 2010-06-02 07:33:31 UTC
(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.
Comment 42 Ciaran McCreesh 2010-06-02 08:41:00 UTC
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.
Comment 43 Artem S. Tashkinov 2011-04-01 14:16:26 UTC
This bug report hasn't had any activity for the past 10 months, does anyone still have this issue?
Comment 44 Alon Bar-Lev 2011-04-01 15:02:39 UTC
(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.
Comment 45 Henrik Pauli 2011-04-01 15:06:30 UTC
(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.
Comment 46 Elias Probst 2013-03-15 08:22:02 UTC
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?
Comment 47 Elias Probst 2013-03-15 08:56:07 UTC
(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.
Comment 48 Artem S. Tashkinov 2013-03-15 13:43:36 UTC
(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.
Comment 49 Elias Probst 2013-03-15 20:26:46 UTC
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?
Comment 50 Peter Hutterer 2017-02-22 03:03:56 UTC
based on comment #49 I'm closing this
Comment 51 Artem S. Tashkinov 2017-02-22 08:17:03 UTC
(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.


bug/show.html.tmpl processed on Feb 28, 2017 at 05:27:05.
(provided by the Example extension).