Version: (using KDE 4.2.0) OS: Linux Installed from: SuSE RPMs Keyboard input soley for konsole goes away (it is actually buffered and goes to whichever konsole terminal actually owns the keyboard and will show up when you select that terminal and type something). All konsole windows will not accept keyboard input until the terminal owning the keyboard is found and typed into (doesn't update graphically until keypress). -mouse works fine -pasting from mouse also works fine (xinput and paste from right-click menu) -short cuts stop working Behavior gets undefined if you close the owning konsole window although there are no hard-crashes. Steps to reproduce: open a new terminal (timing and maybe system load has some impact= suggest this is a race condition) and I use keybindings to create the new tabs/windows) quickly quite often and start typing immediately. Note that this bug will not happen every time but it happens to me many times daily... high probability of happening when you open new terminals *fast* and you keep typing.
I have the same problem with two differences: - I haven't noticed the input being buffered, it's just lost - I usually encounter this problem when switching tabs using shift+arrow. The easiest way to reproduce is to quickly switch tabs holding shift and tapping arrow. Konsole often will just stop at one tab and refuse any input. Previous tab in sequence needs to be selected (using mouse) to get input to work again. Not sure if this is relevant, but I never noticed this when switching tabs using mouse. Also, high system load seems to increase probability that this problem will occur.
*** Bug 186094 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
This might or might not be relevant but I actually have been having the same problems with firefox windows (I usually have 2-3 opened). I know this isn't a place for firefox bugs but the behavior is EXACTLY the same as konsole (no other application I have on system seems to do this but otoh, konsole and firefox are about the only things I have opened that have multiple windows w/ text-entry), thus I think it deserves mention in that maybe this is an Xorg/xlib problem or something? Steps to reproduce are the same with the exception that new-tab doesn't seem to trigger e.x. alt-tab a bunch of times. Input is still buffered until you find the keyboard owner, if you close the owning window, you're screwed, the keystrokes only go to the owning window, shortcuts die, and finally xinput/paste work fine as does other mousely functions. Also, since reporting this bug I have upgraded to a newer and significantly faster machine. I rarely encounter the bug within konsole if at all anymore (1 every month?) within in konsole. I'm also currently, and have been, at kde HEAD from opensuse kde unstable repos with the mozilla:beta repo's firefox 3.1b3.
Created attachment 32713 [details] this is my konsole deps in Gentoo I have this problem every day.
another bug of konsole. sometime the response of konsole is slow. and after you enter a few characters, konsole auto enter a key; yesterday the key is backspace, and today it is 'j'.
There is a small possibility that it relates to the window manager. Are you using KWin? If not, try using KWin as your window manager using: kwin --replace If you are already using KWin, I suggest trying a different window manager and let me know if you still experience the problem, eg: metacity --replace
I use kwin.. I'll try metacity sometime but also I can't test on konsole really since I haven't been getting the problem from it since i moved computers. Anyone else?
i use kwin too. when i get the problem, `metacity --replace` does not work.
Actually this has now happened to me again on konsole when doing some intensive IO copying and also in konqueror under normal system load. svn 949727. It looks like it is kwin? Either that or something in the keyboard/xlib stack.
Still happens when using metacity 2.26 (via metacity --replace) while in a kde session. Good way to trigger it with firefox (for me): click search bar in one window and test text entry via typing, then control+n a new window up and click it's search bar and start typing. If the text is entered, close the window (control+w) and repeat at the first step. It usually only takes me about 5 tries. This happens with konqueror too but I haven't gotten down the process to trigger it as exactly as with firefox. So I've ruled out kwin and konsole's fault directly mayhaps. Which leads to the question of what is causing the bug?
it always happens on kdesvn. dev-util/kdesvn-1.3.0
I believe I found the culprit: scim. I think switching to scim-bridged fixes it too. Else purging it from the system. Haven't had the problem since. Qing Lei, can you confirm?
I use iBus(http://code.google.com/p/ibus/).
I too have exactly the same problems with konsole. I added the details of my problems to a similar bug report: https://bugs.kde.org/show_bug.cgi?id=179448, which may in fact be a duplicate of this. I'm also an ibus user, but rarely switch input methods in konsole. So, I don't think this is a scim (only) problem. I have no problems with firefox. I'm running: Fedora Core 11 (rawhide) kernel.i586 0:2.6.29.3-140.fc11 kdebase.i586 6:4.2.2-2.fc11 kdelibs.i586 6:4.2.2-12.fc11 qt.i586 1:4.5.0-14.fc11 ibus.i586 1.1.0.20090423-1.fc11 ibus-anthy.i586 1.1.0.20090402-1.fc11 ibus-gtk.i586 1.1.0.20090423-1.fc11 ibus-libs.i586 1.1.0.20090423-1.fc11 firefox.i586 3.5-0.20.beta4.fc11
Just an update to let you know that I haven't yet experienced this problem in FC12 rawhide. There are other keyboard problems, but this one *seems* to have been resolved.
Sorry, should have also mentioned the versions of other software: kernel.i586 2.6.31 kdebase.i586 4.2.95 kdelibs.i586 4.2.95 qt.i586 4.5.2 ibus.i586 1.2.0 ibus-anthy.i586 1.2.0.20090617 ibus-gtk.i586 1.2.0.20090617 ibus-libs.i586 1.2.0.20090617
Created attachment 39944 [details] log I'm observing a very similar issue on OpenSolaris. The konsole tab often stops responding to any keyboard input when Ctrl+C is pressed. Often in case something is being typed and Ctrl+C is hit very fast. But it also happens while a a build log is being printed and Ctrl+C is hit. I can 100 % reproduce it this way: 1. press ctrl+G, do not release the keys 2. press the 'c' key this works with other keys ('d', 'l', 'w'), does not with 'u','a','z' and others. I cannot reproduce it this way on Linux. see the attached log of 'truss -dfF -rall -wall -o log /opt/kde4/bin/konsole' at 12.0534 the 'ctrl-g' is recorded at 12.0745 - 12.5563 there is a DBus communication with knotify regarding the bell (I think) several other 'ctrl-g' are recorded at 12.5645 Ctrl-C is detected at 12.6764 konsole is already parsing the configs to get the prompt at 12.8158 konsole tries to output the new line with shell prompt, which never happens
also it seems only the printing is affected, because when I blindly type [Enter]exit the 'frozen' tab closes
Is this still a issue in recent version? The last coment is more than 1 year old :)
Can't reproduce it with KDE-4.7.0. Feel free to reopen if this still happens in recent version.
I see that this is an ancient issue, but I'm seeing this behavior now, years later! Konsole v. 2.11.3 KDE v. 4.11.3 PC, 64 bit. Ubuntu 13.10 kernel 3.8.0-33 Everything seems to start out fine, I have maybe 5 or so tabs open; 2 local, 3 or more in ssh remote sessions. I come to a point where typed characters start to be missed. This gets progressively worse and worse. Then what you type in, devolves into the character j, which gets entered maybe once every 10 or 20 keypresses!... until the entire window has to be abandoned. This is growing so frequent I will soon be forced to abandon using Konsole! Help! Any ideas?