Hi there.

Quite often (2 times today so far), my keyboard completely stops working in KDE. This happens on two different PCs.

It seems to happen most often when I have Konqueror open, and am hitting "alt tab". After alt-tabbing over to Konqueror, then the keyboard completely dies in KDE. I have to close down all the apps with the mouse.

And then I use Ctrl+Alt+F1, to change over to a text terminal and then run '/etc/init.d/kdm restart', to get another login, where the keyboard works again in KDE.

In some cases, the keyboard seems to start working again spontaneously, after closing down a few apps. But this might be coincidental (it was going to work anyway after a short period of time).

For reference, here are the last few lines of my Xorg.0.log file:

(II) Mar 29 18:05:57 NVIDIA(0): Setting mode "nvidia-auto-select"
(II) "Power Button": Device reopened after 1 attempts.
(II) "Sleep Button": Device reopened after 1 attempts.
(II) "HID 04d9:1203": Device reopened after 1 attempts.
(II) "HID 04d9:1203": Device reopened after 1 attempts.
(II) "PIXART USB OPTICAL MOUSE": Device reopened after 1 attempts.

It kind of looks like something hardware-wise is resetting in my PC, but X or KDE isn't able to pick up the keyboard, although the mouse works fine. While in reality, the keyboard is actually working fine, since I can always use "Ctrl+Alt" to switch out of X into a text terminal, to reset KDM.

Also, my mouse and keyboard are both USB.

Is this a known problem? Any known fixes? Should I report this as a bug against X/KDE/Konqueror?

Does physically disconnecting and reconnecting your keyboard cure the issue? ( just checking to see if it is a X issue with hardware rapidly appearing and disappearing )

Thanks for the reply. I was waiting for it to come up again before replying.

Happened again today on my work PC, where the keyboard & mouse are on a KVM switch, with PS2 connectors (my home PC is the one with USB input devices, which has the same, or a very similar problem, which I reported in my previous post).

No output in the X log. Disconnecting the mouse & keyboard on the box didn't make any difference, and neither did switching with the KVM.

But after closing down a few apps with the mouse, the keyboard started working again. I think that the last-closed app was Konqueror. I have this idea that somehow Konqueror (or some other KDE app/component) is disabling/stealing the keyboard from all the other apps, due to some bug.

The only related thing I've changed in my system (for task-switching/alt-tab), is disabling the 3d effect for switching between apps - I prefer the list of app names.

I'll post more in this thread as I find more info, in case it gives people an idea for what I should check next, or report a bug for. Next time I'll see if I can find more information in the syslog and xsession-errors.

Let me know if there are other places I can check, or should try increasing the logging verbosity for.

Happened again, this time on my home PC (the one with USB devices). However, after closing a few windows with the mouse, the keyboard seems to work again. Again, I think it is Konqueror that I closed, which re-enabled the keyboard.

I got some more information from the logs now.

Syslog:

Code: Select all

Mar 30 20:48:39 localhost acpid: client 3354[0:0] has disconnected
Mar 30 20:48:40 localhost acpid: client 3354[0:0] has disconnected
Mar 30 20:49:39 localhost kernel: [10931.016039] usb 8-2: USB disconnect, address 2
Mar 30 20:49:41 localhost kernel: [10932.528012] usb 8-2: new low speed USB device using uhci_hcd and address 3
Mar 30 20:49:41 localhost kernel: [10932.702095] usb 8-2: New USB device found, idVendor=093a, idProduct=2510
Mar 30 20:49:41 localhost kernel: [10932.702098] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 30 20:49:41 localhost kernel: [10932.702100] usb 8-2: Product: USB OPTICAL MOUSE
Mar 30 20:49:41 localhost kernel: [10932.702102] usb 8-2: Manufacturer: PIXART
Mar 30 20:49:41 localhost kernel: [10932.702191] usb 8-2: configuration #1 chosen from 1 choice
Mar 30 20:49:41 localhost kernel: [10932.729270] input: PIXART USB OPTICAL MOUSE as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/input/input7
Mar 30 20:49:41 localhost kernel: [10932.729330] generic-usb 0003:093A:2510.0004: input,hidraw2: USB HID v1.11 Mouse [PIXART USB OPTICAL MOUSE] on usb-0000:00:1d.2-2/input0
Mar 30 20:49:51 localhost acpid: client connected from 3354[0:0]
Mar 30 20:49:51 localhost acpid: 1 client rule loaded
Mar 30 20:49:51 localhost acpid: client connected from 3354[0:0]
Mar 30 20:49:51 localhost acpid: 1 client rule loaded


Xorg.0.log

Code: Select all

(II) Mar 30 20:49:51 NVIDIA(0): Setting mode "nvidia-auto-select"
(II) "Power Button": Device reopened after 1 attempts.
(II) "Sleep Button": Device reopened after 1 attempts.
(II) "HID 04d9:1203": Device reopened after 1 attempts.
(II) "HID 04d9:1203": Device reopened after 1 attempts.


.xsession-errors

Firstly, getting a huge number of these, but I assume it's normal:

Code: Select all

virtual bool Solid::Backends::Hal::HalDevice::queryDeviceInterface(const Solid::DeviceInterface::Type&) const  error:  "org.freedesktop.DBus.Error.Disconnected


And, I don't seem to see anything special in the X log just before the keyboard stopped working in X, but I do see this when it started working again:

Code: Select all

QClipboard::setData: Cannot set X11 selection owner for CLIPBOARD
QClipboard::setData: Cannot set X11 selection owner for PRIMARY


Which might be coincidental.

Basically, from the syslog, it looks like the USB subsystem (in the kernel/on my motherboard) are glitching/resetting a bit, and this is confusing X keyboard handling in some way, but not adversely affecting the keyboard handling for the rest of the system?

Although it's pretty weird how this seems to be connected to konqueror. Maybe I have slightly faulty hardware, and konqueror is exposing the problem in some way

Well, these are the logs from my home machine, which uses a USB mouse and keyboard. I'll need to check what the logs on my work PC say when it happens there.

But for this problem on my home PC, does this look like something I should forward to X.Org?

If you can link the problem with one specific application, then further investigation can be done to find the issue. With Konqueror, are you visiting any site in particular when it locks up?

Had it again now, at work, but the symptoms are a bit different:

1. In my syslog:

Code: Select all

Apr  1 14:43:12 david kernel: [172050.382672] CPU0 attaching NULL sched-domain.
Apr  1 14:43:12 david kernel: [172050.382676] CPU1 attaching NULL sched-domain.
Apr  1 14:43:12 david kernel: [172050.408057] CPU0 attaching sched-domain:
Apr  1 14:43:12 david kernel: [172050.408061]  domain 0: span 0-1 level MC
Apr  1 14:43:12 david kernel: [172050.408064]   groups: 0 1
Apr  1 14:43:12 david kernel: [172050.408068] CPU1 attaching sched-domain:
Apr  1 14:43:12 david kernel: [172050.408070]  domain 0: span 0-1 level MC
Apr  1 14:43:12 david kernel: [172050.408073]   groups: 1 0
Apr  1 14:43:42 david kernel: [172079.618893] CPU0 attaching NULL sched-domain.
Apr  1 14:43:42 david kernel: [172079.618899] CPU1 attaching NULL sched-domain.
Apr  1 14:43:42 david kernel: [172079.648551] CPU0 attaching sched-domain:
Apr  1 14:43:42 david kernel: [172079.648554]  domain 0: span 0-1 level MC
Apr  1 14:43:42 david kernel: [172079.648557]   groups: 0 1
Apr  1 14:43:42 david kernel: [172079.648561] CPU1 attaching sched-domain:
Apr  1 14:43:42 david kernel: [172079.648563]  domain 0: span 0-1 level MC
Apr  1 14:43:42 david kernel: [172079.648565]   groups: 1 0


2. This is at the bottom of my xsession-errors:

Code: Select all

madplug: lost synchronization.
madplug: lost synchronization.
QThreadStorage: Thread 0x9b552f8 exited after QThreadStorage 2147483638 destroyed
QThreadStorage: Thread 0x9b552f8 exited after QThreadStorage 2147483638 destroyed
Undecodable sequence: \001b(hex)[?1034h
Undecodable sequence: \001b(hex)[?1034h
Undecodable sequence: \001b(hex)[?1034h
madplug: lost synchronization.
madplug: lost synchronization.
madplug: lost synchronization.
kdeinit4: preparing to launch /usr/lib/libkdeinit4_konsole.so
madplug: lost synchronization.
madplug: lost synchronization.
madplug: lost synchronization.


3. This is at the bottom of my xorg log file:

Code: Select all

(II) "Power Button": Device reopened after 1 attempts.
(II) "Sleep Button": Device reopened after 1 attempts.
(II) "AT Translated Set 2 keyboard": Device reopened after 1 attempts.
(II) "ImPS/2 Generic Wheel Mouse": Device reopened after 1 attempts.
(II) Apr 01 14:43:12 NVIDIA(0): Setting mode "nvidia-auto-select"
(II) Apr 01 14:43:12 NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
(II) Apr 01 14:43:12 NVIDIA(0):     may not be running or the "AcpidSocketPath" X
(II) Apr 01 14:43:12 NVIDIA(0):     configuration option may not be set correctly.  When the
(II) Apr 01 14:43:12 NVIDIA(0):     ACPI event daemon is available, the NVIDIA X driver will
(II) Apr 01 14:43:12 NVIDIA(0):     try to use it to receive ACPI event notifications.  For
(II) Apr 01 14:43:12 NVIDIA(0):     details, please see the "ConnectToAcpid" and
(II) Apr 01 14:43:12 NVIDIA(0):     "AcpidSocketPath" X configuration options in Appendix B: X
(II) Apr 01 14:43:12 NVIDIA(0):     Config Options in the README.
(II) "Power Button": Device reopened after 1 attempts.
(II) "Sleep Button": Device reopened after 1 attempts.
(II) "AT Translated Set 2 keyboard": Device reopened after 1 attempts.
(II) "ImPS/2 Generic Wheel Mouse": Device reopened after 1 attempts.


... This sounds like I am getting some weird ACPI warning. I don't know how ACPI works in Linux... any advice based on the above message?

4. It definitely seems to be konqueror-related in some way.

I checked the keyboard (in a konsole session) as I closed down Konqueror tabs (the first app I tried closing), and immediately after Konqueror closed (after the last tab was closed), the keyboard started working fine again. The timing is too close to be a coincidence (and I have observed the same thing many times before).

bcooksley wrote:If you can link the problem with one specific application, then further investigation can be done to find the issue. With Konqueror, are you visiting any site in particular when it locks up?

No site in particular. 99% of the time I use Konqueror as a filesystem browser, because I prefer it to Dolphin (and I use Iceweasel on Debian for web browsing 99% of the time). Today I was coincidentally using Konqueror to browse to an SSL (and htpass)-protected bugzilla installation as for something work-related, but I don't think that's related.

Also, the keyboard freezing in this case happened (I think) when I was switching between 2 other apps - Konqueror was just running in the background, I think just with a few open tabs to various directories on my harddrive.

Note: The above was on my work PC (ie, the one with the KVM switch and PS2 input devices, not the one at home with the USB input devices).

The main things in common between my work and home PC that I can think of:

1. I use Konqueror a lot for filesystem browsing, management, in KDE 4.

2. I have the proprietary nvidia graphics card driver installed.

3. I've disabled the KDE's fancy task-switching animation (prefer the list of window titles).

4. I have slightly non-standard input devices (USB at home, and KVM+PS2 at work).

This means that Konqueror ( or more likely, one of its loaded plugins, probably Flash ) is capturing all keyboard output.

Thanks for that confirmation.
I don't think it is 100% Konqueror, but it definitely seems to be involved in some way.
I'll report a bug against Konqueror on the Debian bug tracking system

I'm experiencing a similar problem, except it's the mouseclicks that stop working, and I don't use Konqueror. Cursor movement continues to work fine. I've experienced the problem mainly, if not exclusively, when browser windows are open (Firefox/Chromium), but I'm not completely sure that's the cause. Suspending compositing doesn't change anything, but the problem does not appear in Fluxbox. As with wizzardxyz, closing some/all windows resolves the problem for a couple minutes, and restarting X resolves it for a while, but not indefinitely.