Bug 483232

ad.a) ... in the older session, in the newly created keyboard works. It happened to me that it died three times in a row.

Looks like a sound driver issue to me.

Small correction, sorry, I _updated_ kernel but _installed_ this alsa driver (it wasn't installed through those two months at all).

You can check the influence of alsa-driver-kmp simply by uninstalling the package.  Check whether the problem still persists.

It is not that easy, because I would need information what to downgrade in order to get sound just like after installation. As you know with the latest updates to get sound this package is required -- and the problem with keys happen but not that often that I could have no sound in the system.

I hope you understand my concern.

I understand, but the sound isn't basically unnecessary to reproduce the keyboard problem, right?  Just use without sound for a while to check whether the keyboard problem appears...

Or, you can try the latest kernel from
    ftp://ftp.suse.com/pub/people/tiwai/sled11-post-gmc/
This includes many pending sound fixes, and should work with your machine without alsa-driver-kmp.  Give it a try.

> Just use without sound for a while 

The issue is -- a while :-). Positive test can take a second, but negative has no limit (by definition). And I need sound for notifications. I give it a try to Wednesday, I hope it is sufficient for you?

Ok, I don't have alsa driver now installed and I encountered this problem again.

I think this issue with keyboards are two problem, because what I wrote in #8 it was autorepeating -- and it happened with alsa drive not installed.

BUT -- the dead keyboard occurred _only_ with alsa driver. For example, I was testing system without this driver for 2 days, nothing happened, I installed it, and after restart in 10 minutes keyboard died twice. I doubt it is just coincidence. Very similar thing happend after I tried alsa driver for the same time, 3 times in a row just after installation. 

Should I open another report, or would it be better to fix the dead keyboard and see then if autorepeating will occur?

I am using this new kernel for a few days, thank you Takashi, no problem with dead keyboard but autorepeating still occurs.

Update: with kernel from #6, the disabling keyboard also happens.

linux-kernel-headers-2.6.27-2.28
kernel-default-extra-2.6.27.21-0.1.2
kernel-source-2.6.27.21-0.1.1
kernel-default-base-2.6.27.21-0.1.2
kernel-default-2.6.27.21-0.1.2

still happens.

Hmm, weird.

Jiri, could you take a look?  I suspect it's rather the problem of input stuff...

Is this USB or PS/2 connected keyboard?

Could you please

- post a dmidecode output from the machine
- capture both evtest and xev output on the keyboard device from the situation when the key is stuck, to see if it is X or kernel who loses the release event

It is internal laptop keyboard.

> - capture both evtest and xev output on the keyboard device from
> the situation when the key is stuck, to see if it is X or kernel
> who loses the release event

I don't think we understand each other. First of all what does "when" means here?

Second -- by "stuck" I guess you mean autorepeating case. Such case looks like this, I press a, b, c keys. I get

abbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbc

And for next several hours everything can be fine. So in practice I can do only tests _after_ autorepeating occurs. And after additional keys pressed -- because I cannot predict when it happens, and since I am fast typist I type faster than I track the output.

(In reply to comment #15)
> It is internal laptop keyboard.

So probably conntected through PS/2, right? (you can find out from dmesg or hwinfo --keyboard, for example).

> > - capture both evtest and xev output on the keyboard device from
> > the situation when the key is stuck, to see if it is X or kernel
> > who loses the release event
> 
> I don't think we understand each other. First of all what does "when" means
> here?
> 
> Second -- by "stuck" I guess you mean autorepeating case. Such case looks like
> this, I press a, b, c keys. I get
> 
> abbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbc
> 
> And for next several hours everything can be fine. So in practice I can do only
> tests _after_ autorepeating occurs. And after additional keys pressed --
> because I cannot predict when it happens, and since I am fast typist I type
> faster than I track the output.

Would id be possible to keep capturing evtest traffic all the time, and when you experience this loss of release event (i.e. wrong autorepeat of the key), extract the relevant part from the saved evtest output and attach it to this bug? Thanks.

Created attachment 287139 [details]
dmidecode

> So probably conntected through PS/2, right? (you can find out from
> dmesg or hwinfo --keyboard, for example).

I see a lot of "usb" occurrences so it is rather USB.

> Would id be possible to keep capturing evtest traffic all the time,
> and when you experience this loss of release event (i.e. wrong
> autorepeat of the key), extract the relevant part from the saved
> evtest output and attach it to this bug? Thanks.

No problem, but this program does not output anything dynamic.

evtest /dev/input/by-id/usb-413c_8157-event-kbd

And I get just a list of recognized events.

(In reply to comment #18)
> > Would id be possible to keep capturing evtest traffic all the time,
> > and when you experience this loss of release event (i.e. wrong
> > autorepeat of the key), extract the relevant part from the saved
> > evtest output and attach it to this bug? Thanks.
> No problem, but this program does not output anything dynamic.
> evtest /dev/input/by-id/usb-413c_8157-event-kbd
> And I get just a list of recognized events.

Could you please attach output of

cat /proc/bus/input/devices
ls -l /dev/input/by-id/
ls -l /dev/input/by-path

ls -l /dev/input/by-id/
total 0
lrwxrwxrwx 1 root root 9 2009-04-19 18:07 usb-413c_8157-event-kbd -> ../event3


ls -l /dev/input/by-path
total 0
lrwxrwxrwx 1 root root  9 2009-04-19 18:07 pci-0000:00:1a.0-usb-0:1.1:1.0-event-kbd -> ../event3
lrwxrwxrwx 1 root root 10 2009-04-19 18:07 pci-0000:00:1a.7-usb-0:6:1.0-event- -> ../event11
lrwxrwxrwx 1 root root 10 2009-04-19 18:07 pci-0000:00:1b.0-event- -> ../event12
lrwxrwxrwx 1 root root  9 2009-04-19 18:07 platform-i8042-serio-0-event-kbd -> ../event0
lrwxrwxrwx 1 root root  9 2009-04-19 18:07 platform-i8042-serio-1-event-mouse -> ../event1
lrwxrwxrwx 1 root root  9 2009-04-19 18:07 platform-i8042-serio-1-mouse -> ../mouse1
lrwxrwxrwx 1 root root  9 2009-04-19 18:07 platform-pcspkr-event-spkr -> ../event9

Created attachment 287173 [details]
devices

You have some USB HID device under event3, but it is probably not the integrated keyboard. When you run evtest on /dev/input/event0, do you see they keypress/key release events?

Yes I see them, ok so I will try to run it all the time.

Thanks. Then please provide only the relevant part with the key that got autorepeated incorrectly, plus a few surrounding keys, not the whole dump (it will be too big, and I would also be able to see everything you have typed).

Ok, I got one nice -- one keystroke, several characters "typed". But I need a little help -- I pressed those keys:
p
d
f
<space>
<ctrl+c> <--- ending logging

How do I read them from the log so I could cut out only the important stuff and delete the rest?

(In reply to comment #25)
> Ok, I got one nice -- one keystroke, several characters "typed". But I need a
> little help -- I pressed those keys:
> p
> d
> f
> <space>
> <ctrl+c> <--- ending logging
> 
> How do I read them from the log so I could cut out only the important stuff and
> delete the rest?

They should be at the very end of the log. Sequence "pdf<space>" should look similarly to

type 4 (Misc), code 4 (ScanCode), value 70013
type 1 (Key), code 25 (P), value 1
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70013
type 1 (Key), code 25 (P), value 0
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70007
type 1 (Key), code 32 (D), value 1
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70007
type 1 (Key), code 32 (D), value 0
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70009
type 1 (Key), code 33 (F), value 1
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70009
type 1 (Key), code 33 (F), value 0
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 7002c
type 1 (Key), code 57 (Space), value 1
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 7002c
type 1 (Key), code 57 (Space), value 0
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 700e0
type 1 (Key), code 29 (LeftControl), value 1
-------------- Report Sync ------------
type 4 (Misc), code 4 (ScanCode), value 70006
type 1 (Key), code 46 (C), value 1
-------------- Report Sync ------------

Ah, I see now where the problem is. Look, I turned on logging, right, so every key I press is logged in. The problem is that the whole sequence was

forall<space>pdf<space><ctrl+c>

but in log I only see this:

foral

even the second "l" is missing. So how to perform logging, that saving keys would be instant, without caching anything. Or, another approach -- that on ctrl+c buffer will be flushed.

Might be autorepeat triggering in. Please attach the log.

Created attachment 290391 [details]
log.txt

Adding some info about dead keyboard -- if keyboard dies, it is possible to log out, and log in again, for some time the keyboard is functional (and then dies again). I noticed that no matter how many times you log out and log in it is impossible to "escape" from dying keyboard. It looks like entire start of the system is somehow flawed, so the only way to be able to do the work, is to shutdown the entire system, start it again and hope this time keyboard won't be dying.

Does the problem also appear or console, or does it happen solely inside X session?

I cannot tell because I don't use console at all.

I don't want to point in the wrong direction but I think there is correlation between win+tab which I use for app switch and dead keyboard. Usually I found out the keyboard died when trying to switch app.

Do you have the possibility to ssh into that machine when the keyboard in X dies? If so, are you able to run evtest to /dev/input/event? to see whether kernel is providing the keyboard data, only X loses them? Thanks.

Could you please check the steps:

1) open another X session
2) run ssh server (in new X keyboard works)
3) switch back to the X session with dead keyboard
4) login via ssh
5) run evtest via ssh 
6) get back to my machine, and press keys
7) check the output on remote machine

Is this correct?

Hi!

I have the same problems, also with openSuse 11.1 on 64 bit hardware. Patches are up to date, I am using KDE 3.5.

Concerning comment 32: I also think that the dead keyboard is related to app switching. I was just able to reproduce it by massive app switching (~50 times, I use ALT+TAB, though).

I am pretty sure that the kernel is not at fault here, but it must be some GUI problem because when the keyboard is dead
- I cannot set a cursor into any text box (e.g. the browser's address bar), I also cannot select text with the mouse.
- I can switch to console with CTRL+ALT+F1.
- Most weird: If I try to close Firefox it asks me if I am sure, because I have many open tabs. After that, keyboard works again!!!

Particularly the last point is very interesting IMHO. I will attach the output of "evtest /dev/input/even0" as requested in comment 33. This was started in a console shell after I reproduced the problem. I switched back to X and pressed the "x" key multiple times, then back to console to terminate evtest.

Created attachment 297186 [details]
evtest with dead keyboard: Pressed "x" multiple times in the GUI

Stefan, I will try to reproduce the effects you see, but one observation from my computer. I run amule which uses wxGTK toolkit. I noticed correlation with dead keyboard and RMB in amule. 

When the keyboard is dead RMB does not work in amule. When keyboard is not dead, and RMB does not work in amule, it means keyboard will die soon. Odd...

I'm having these same symptoms. The keyboard dying seems to be tied to the Alt key. If I hold down the Alt key and mash on the left side of the keyboard for a while, the problem fixes itself.

@Stefan, I tried the trick with FF, it does not work for me.

@Brian, alt in sense of task-switch? If yes, it is not alt in general, I use win+tab, and alt only rarely. I'll try the fix anyway. What DE do you use? Me -- KDE3.5.10 + some KDE4 applications.

@Maciej, I'm using KDE 4.2, and yes, the keyboard issue is usually in conjunction with alt+tab.

@Brian, I cannot unlock the keyboard using your method.

@Brain and @Stefan -- when keyboard dies, at this moment, do you have any Gtk based application running? (note, that wxGtk uses Gtk as its "native" toolkit, so count such apps too). Me -- yes.

And for autorepeating -- I noticed that when doing have CPU computation and copying large amount of data, this happens all the time. So maybe this autorepeating has something to do with some I/O glitch inside kernel?

X.org implement the auto-repeat themselves and do not rely on kernel autorepeat mechanism. If they are not scheduled frequently enough, their autorepeat mechanism gets mad.

I am really suspecting that this is some X/KDE/Gnome bug rather than kernel bug. 
The log from comment #29 clearly shows that kernel properly emits all press and release events. Also the keyboard works properly in other newly started sessions, and restart of X server fixes the problem.

Reassigning to X folks.

According to rpm, MozillaFirefox requires mozilla-xulrunner190, which in turn requires gtk2. So everyone running Firefox has a GTK app running, right? In this case: Yes, I do have a GTK app running.
If so, even TWM + Firefox should show this behaviour. I will try the I/O stress test (after work).

Talking about load: I must say that either the kernel or the sound system are not doing a good job under load. Sound tends to get choppy when I put a little stress on the system (which should not happen with 4GB RAM, 2.5Ghz dual core). Maybe some component of X was written under the (implicit) assumption that it gets scheduled very regularly, and gets messed up because of poor kernel scheduling.

Sounds like Bug #506494, for which fixed packages are available for testing. If it isn't fixed feel free to reopen this bug, not Bug #506494!

*** This bug has been marked as a duplicate of bug 506494 ***

* dead keyboard occurred
* under I/O stress autorepeating occurred in modest ratio (instead of 1:20, it was 1:3 -- meaning, one keystroke translated into N characters)

Reopening then.

Btw. I didn't test it before, when the keyboard was dead (now), the caps lock led was still switchable using keyboard.

Sure you did install the fixed packages for Bug #506494?

I added the mentioned repo (sle, in the other report) and now I have:
xorg-x11-server-7.4-41.3

It was the newest one available when I was installing it, shortly after your #44 post.

So what's the output of 'rpm --changelog -q xorg-x11-server | head -n 10' ?

* Fri Jun 05 2009 sndirsch@suse.de
- keyrelease-1.5.2.diff
  * xkb: Don't press+release keys on key events. Fixes submission
    of F7 to apps on switch from console for drivers that switch
    fast enough (bnc #141443).

* Tue Jun 02 2009 sndirsch@suse.de
- Frederico's patches to support reprobing of connected displays
  on EnterVT and fixes to set event timestamps properly.
  (bnc #507190)
  * Re-probe RANDR outputs on laptop unsuspend.
  * Make RANDR 'set' timestamps follow client specified time.
  * Add missing fields to SRR*NotifyEvent().

* Fri May 22 2009 sndirsch@suse.de
- commit-525aa17-xkb.diff
  * Bug #6428, #16458, #21464: Fix crash due to uninitialized
    VModMap fields. In ProcXkbGetKbdByName, mrep.firstVModMapKey,
    .nVModMapKeys and .totalVModMapKeys were not initialized,
    contained random values and caused accesses to unallocated and
    later modified memory, causing XkbSizeVirtualModMap and
    XkbWriteVirtualModMap to see different number of nonzero
    values, resulting in writes past the end of an array in
    XkbSendMap. This patch initializes those values sensibly
    and reverts commits 5c0a2088 and 6dd4fc46, which have been
    plain non-sense.
- obsoletes commit-ddb8d89-xkb.diff

More lines, to get the bottom entry.

Today just after starting computer keyboard died again. This time I was running Firefox -- it is hard for me to test if keyboard will die _not_ using any Gtk app because I need them for work.

Can you ssh to the machine, then run 'chvt 1' to switch to Linux console. Does the keyboard work in that Linux console. Does the keyboard work with a new Xsession after killing the X process?

(In reply to comment #49)
> * Fri May 22 2009 sndirsch@suse.de
> - commit-525aa17-xkb.diff
>   * Bug #6428, #16458, #21464: Fix crash due to uninitialized
>     VModMap fields. In ProcXkbGetKbdByName, mrep.firstVModMapKey,
>     .nVModMapKeys and .totalVModMapKeys were not initialized,
>     contained random values and caused accesses to unallocated and
>     later modified memory, causing XkbSizeVirtualModMap and
>     XkbWriteVirtualModMap to see different number of nonzero
>     values, resulting in writes past the end of an array in
>     XkbSendMap. This patch initializes those values sensibly
>     and reverts commits 5c0a2088 and 6dd4fc46, which have been
>     plain non-sense.
> - obsoletes commit-ddb8d89-xkb.diff

Ok. So the fix is in.

Stefan,

a) ssh -- is there a way I can exec command which will switch me to console without using ssh? I tried "chvt 1" from KDE level, it says:
Couldnt get a file descriptor referring to the console

It would be much simpler for me. 


b) X -- what do you mean? I can log out (from KDE) --> KDM --> log in (new session, KDE), keyboard will work. Or I can start new session --> KDM --> log in (KDE), and keyboard will work. IOW: dead keyboard is per X session issue.

(In reply to comment #52)
> a) ssh -- is there a way I can exec command which will switch me to console
> without using ssh? I tried "chvt 1" from KDE level, it says:
> Couldnt get a file descriptor referring to the console
> 
> It would be much simpler for me. 

Didn't you tell me your keyboard is dead. How do you want to type "chvt 1" then?
Confused. BTW, you need to be root to run chvt.

> b) X -- what do you mean? I can log out (from KDE) --> KDM --> log in (new
> session, KDE), keyboard will work. Or I can start new session --> KDM --> log
> in (KDE), and keyboard will work. IOW: dead keyboard is per X session issue.

Just kill the 'X' process in process table. The displaymanager will start a new Xserver.

> Didn't you tell me your keyboard is dead. How do you want to type "chvt 1"
> then?

Why "then"? Bash script, saved now and executed then (using mouse) :-) 

I send info as soon as keyboard will die.

So the issue still didn't occur after a week?

Yes, but I would not expect otherwise -- I started my computer ~4 times, and it didn't happen before as often as once in 4 tries.

Don't get me wrong, but issues you even cannot reproduce yourself easily either, really make no sense for us trying to investigate. Thus closing as WORKSFORME.

Stefan, actually it is hard to not get you wrong :-).

This is difficult case, because it is not obvious for me how to trigger it -- quite contrary with buggy udf mounting or buggy camera mounting, which happens every time. But on the other hand what would you except -- release of opensuse which disables keyboard on every boot? Such bug is actually a theoretical, because (I hope) such "release" would never be released.

This bug appears once per boot -- my computer works long hours and I don't have time (*) to restart it every 15 minutes to trigger the bug, and see if it is this or that driver, this or that app, this or that gtk version. Nowadays systems are complex beasts and it is hard to nail the problem (why bluetooth works on 2 computers, and on the third does not -- go figure, magic).

(*) because I am doing long computations, and I can't stop them randomly to restart computer

So, I am willing to help, but I don't sacrifice my job just for booting all day long. Also hiding bugs under the carpet does not help at all -- even without it OS has problems with quality, but if you add "when I don't look there is no bug" solution, things will get worse.

This bug exists, you know it, and I know it. The fact I can spot if from time to time does not mean it is rare, but it means I boot up computer not too often (i.e. 3 days uptime is a standard now for me).

Enough of late-evening rant :-) I hope you don't read it as offensive or something like that.

Once I noticed in amule I cannot get context menu (RMB does not work) I knew in a second keyboard will be dead. And it was.

I cannot still figure out if amule (wxGTK) is the cause of keyboard dying or the side effect (another input device is not working).

Anyway, after switching to console keyboard works (in console), after restarting X keyboard works. So keyboard dying (as previously said) is per X session issue. You could have (theoretically) sessions
1, 2, 3, 4, 5

with keyboard still working for 1 and 2, and dead for sessions 3-5.

Now I work on X session which was auto-restarted after killing previous one. "Normally" when I just logoff, login (new session) keyboard was dead in 15 minutes again. I will see if this is an issue with total X restart.

I died again, as "usual". Another observation -- amule does not quit cleanly when this bug occurs (I started it again after keyboard died, to see if RMB worked -- it didn't).

amule appears to be a packman package, you compiled it yourself or you found a package on a different source. SUSE/Novell doesn't ship such a package nor could I find it on our buildservice.

==> MINOR/P4

Stefan, is my English really that bad? Comment above I stated I _didn't_ run amule while waiting for keyboard to die -- and keyboard died. So amule is not the cause for sure, it is affected, but it not the cause.

Please, don't try to diminish the importance or relevance of this report. It is not good nor polite behaviour -- you wanted the details, I am giving all the details I can find, but to _solve_ this issue.

I am able to reproduce this bug (not for long) what should I do now?

The way you stated above I needed to misunderstand you:

> Once I noticed in amule I cannot get context menu (RMB does not work) I knew in
> a second keyboard will be dead. And it was.

Run amule --> try to use context menu ==> keyboard dead!

Since we can't reproduce the issue, and you obviously never accept WORKSFORME
for such situations, this issue will remain open until it gets fixed upstream (by accident).

> The way you stated above I needed to misunderstand you:
> > Once I noticed in amule I cannot get context menu (RMB does not
> > work) I knew in a second keyboard will be dead. And it was.
>
> Run amule --> try to use context menu ==> keyboard dead!

No, you got _this_ right. 

After this comment, I added another one.

keyboard is dead --> check if RMB in amule is dead too -> yes it is dead.


> Since we can't reproduce the issue, and you obviously never accept
> WORKSFORME

Bug (by definition) is not guaranteed to show for everybody. I would like to know how to trigger it for myself, but with no help I cannot do this, because I don't have kernel/X knowledge.

Closing this report does not help at all, I hope you agree with me.

> for such situations, this issue will remain open until 
> it gets fixed upstream (by accident).

Upstream = X or kernel here?

Btw. today keyboard died 4 times already, so it is repeating, and I could investigate it further, I can deliver any information that would be helpful, but I need to know where to look.

Upstream can be everything: application, toolkit, desktop, X. We don't know. Probably it's not the kernel. If I would have a clue how to investigate that issue, I would have told you earlier.

The dead keyboard occurs for me recently more often -- ~every second day. Today I got the proof for 110% amule is not the cause. I started the fresh system (so it was not even new X session, but first boot of computer), I executed my program in C#, Konsole, Kmail, Konq., Knode and at this point keyboard died.

Now I will try to figure out, what keys could be the cause, but from what I see recently it looks like the more nervous I launch/switch apps the more often the keyboard dies. And launch/switch is all about win key.
Switch - win+tab
konsole win+h
kmail win+m
konq win+b
knode win+u

So when I launched today those, it was something like this
win h m b u tab

Another wild guess is, the autoreaping (the bug, not the feature) is killing the keyboard. It could be like this, I hold win pressed, but at some point the buggy autorepeating is triggered on, and millions of they key event is sent, which breaks the receiving part.

More questions than answers ;-)

Almost a month without this bug and I started to believe the latest kernel fixed this by accident. Unfortunately not -- and it is odd, that when it starts happening it happens in a series -- I am writing it after 4 occurrence in 2 days.

I've noticed the same thing- I can go weeks without seeing this problem, then suddenly it will occur several times a day. 

Note that this isn't a kernel problem, but an X problem, as evidenced by the fact that restarting X will reactivate the keyboard.

Another possible culprit: Accessibility (especially SlowKeys).

Please run http://www.suse.de/~mhopf/accessx_state (needs some time to sync) on your system and post the output.

XkbGetControls: ret 0:
  enabled_ctrls:    0x00001121:
    XkbAccessXKeysMask:     Enable turning on AccessX by key sequences:  off
    XkbAccessXTimeoutMask:  Change to default values on timeout:         off
    XkbAccessXFeedbackMask: Audible feedback (see ax_options):           on
    XkbSlowKeysMask:        Delay keypress acceptance:                   off
    XkbBounceKeysMask:      Ignore keypress bounces after release:       off
    XkbStickyKeysMask:      Let modifiers stick to state:                off
  slow_keys_delay:  500
  debounce_delay:   500
  ax_options:       0x00000ce3
    XkbAX_TwoKeysMask
    XkbAX_LatchToLockMask
    XkbAX_SKPressFBMask
    XkbAX_SKAcceptFBMask
    XkbAX_BKRejectFBMask
    XkbAX_StickyKeysFBMask
  axt_opts_mask:    0x00000010
  axt_opts_values:  0x00000000
  axt_ctrls_mask:   0x0000001e
  axt_ctrls_values: 0x00000000

Is this the output when the issue occurs?

I considered that the issue was due to accessibility functions and previously tested this theory by navigating to the Accessibility panel to see if any were enabled (they were not), and by holding down keys to see if they would work (as would be the case with SlowKeys). I also held down Shift, the normal shortcut for activating/deactivating SlowKeys. None of these actions produced any results.

(In reply to comment #71)
> XkbGetControls: ret 0:
>   enabled_ctrls:    0x00001121:
>     XkbAccessXKeysMask:     Enable turning on AccessX by key sequences:  off
>     XkbSlowKeysMask:        Delay keypress acceptance:                   off

So Accessibility (especially slowkeys) appears not to be culprit here.

Please run it once again, when you stumble over this issue once more. This is really tricky, I'm not sure at all whether this is related to accessibility, but for now it's my best guess.

As long as we cannot reproduce this issue over here, we're stuck with guessing.

Output with disabled keyboard.

XkbGetControls: ret 0:
  enabled_ctrls:    0x00001121:
    XkbAccessXKeysMask:     Enable turning on AccessX by key sequences:  off
    XkbAccessXTimeoutMask:  Change to default values on timeout:         off
    XkbAccessXFeedbackMask: Audible feedback (see ax_options):           on
    XkbSlowKeysMask:        Delay keypress acceptance:                   off
    XkbBounceKeysMask:      Ignore keypress bounces after release:       off
    XkbStickyKeysMask:      Let modifiers stick to state:                off
  slow_keys_delay:  500
  debounce_delay:   500
  ax_options:       0x00000ce3
    XkbAX_TwoKeysMask
    XkbAX_LatchToLockMask
    XkbAX_SKPressFBMask
    XkbAX_SKAcceptFBMask
    XkbAX_BKRejectFBMask
    XkbAX_StickyKeysFBMask
  axt_opts_mask:    0x00000010
  axt_opts_values:  0x00000000
  axt_ctrls_mask:   0x0000001e
  axt_ctrls_values: 0x00000000

Same output, so it isn't related to Accessibility.

So this just happened to me again (Dell Latitude D630C notebook, 11.1).
It was possible to switch to console using C+A+Fx (*).

I ran xev, it did not reveal a single event from the keyboard.

Then I attached a USB keyboard and it did not change at all -- no events
in xev and it was still possible to switch to console and back.

Is there anything I can try to debug this further?
It's fairly annoying (try to quit vi without keyboard ;-).

(*) Sometimes this happens with shift locked - then it's even not possible
to close windows, switch tabs in konsole, etc.

In a hurry I forgot to check Ctrl+Alt+Fx switch to console, sorry for that.

New fact from today -- "normally" keyboard is disabled max. after 2 hours. Till today I was sure, that after such period I have solid system and I can work without any problem. But today, keyboard died after 13 hours of work! Just after pressing win+tab without any doubt (i.e. last win+tab didn't work).

I attach list of processes working at the moment of this accident, maybe it will bring some light -- maybe some process died? I removed some entries like privoxy or kwallet, for clarity of the list.

Ctrl-Alt-Fx works while they bug is manifest. So does Ctrl-Alt-Bksp.

Created attachment 323316 [details]
ps -ax

I confirm ctrl+alt+Fx is working while keyboard is disabled. And it was another win+XX related, this time I pressed win+esc (close window), the event was sent, after that keyboard died.

So it happened to me twice today, on fully updated 11.2.
Is there _anything_ we can do debug this further? It's quite annoying.

One datapoint from my side -- it happened to me twice in the past several weeks, and I have found out that the keyboard is in fact not really dead, but just reeeeeally slow to handle the keypress (i.e. when keeping key pressed for several seconds, it reacted). i.e. SlowKeys feature has been activated somehow automagically.

I have installed xkbset (from some repository in buildservice) and
when I manually turned "slowkeys" on, the keyboard started to behave
like when this bug manifested itself.  However, it has not happened to
me spontaneously so far and so I could not try to "fix" this problem
with xkbset.  Nevertheless, I am quite confident it will help.

I did a bit of googling and came across this Redhat bug which might be
about the same issue (I have not read all the comments thoroughly,
though):

https://bugzilla.redhat.com/show_bug.cgi?id=445898

However, they fixed the problem in gnome-settings-daemon and I don't
think that is ever run on my system... but I do have it installed for
some weird reason.

Two more possibly related links:

http://www.linuxhomenetworking.com/forums/showthread.php/17516-keyboard-not-working-in-KDE?p=139226

http://ubuntuforums.org/showthread.php?t=458036

I didn't have those options turned on, but I reinforced that settings
now, let's see if it helps or not.

I believe we have seperate issues here. One is that slowkeys gets enabled not by (users's) intention, possibly already by gdm or later by some GNOME application. Not easy to reproduce. The other one is some weird bug deep in X, even more difficult to reproduce - not investigated yet. :-(

Note about autorepeating -- I wanted to type:
.się

the space was autorepeated so I get the effect of
....................................się

I typed "się" just after ".", so I already finished hitting keys when I saw several first ".".

It is different when you do the repeating "." by hand, press and hold ".", and then type "się". The moment you hit "s" the effect of still pressed "." is canceled and you get "s". In other words, if the autorepeating was done at hardware level I would get
.się

as I intended. It has to be at software level then.

(In reply to comment #85)
> I have installed xkbset (from some repository in buildservice) and
> when I manually turned "slowkeys" on, the keyboard started to behave
> like when this bug manifested itself.  However, it has not happened to
> me spontaneously so far and so I could not try to "fix" this problem
> with xkbset.  Nevertheless, I am quite confident it will help.

OK.  Now it happened spontaneously and running "xkbset -sl" did help
to get keyboard back to normal.  So this is still an annoyance but
rather less extreme now.

Where did you get xkbset? It is not in any official 11.1 repo, so I would like to use the same version as you.

(In reply to comment #90)
> Where did you get xkbset? It is not in any official 11.1 repo, so I would like
> to use the same version as you.

I searched for it in buildservice.  When I do the search now I get
only one result (below) so I suppose it must be the repository I use:

http://download.opensuse.org/repositories/home:/tiwai/openSUSE_11.1/

The package version certainly matches.

Just happened again, 11.2 incl. latest patches. The above advice
with xkbset -sl unfortunately didn't work.

There are no plans to fix this still for opnSUSE 11.1, but please feel free to
reopen if you see the issue still/again with openSUSE 11.3.