On Mon, Nov 26, 2018 at 02:31:35PM +0200, Juha Nikkanen wrote: > Ladies and gentlemen, > > I acquired a new keyboard and now this new kbd presents itself as a > multiple input device. In following evtest output, kbd devices are 2 > and 7 with difference that 7 offers some media keys as well (listing > #2 lists additional keys): > listing #1, available devices: > /dev/input/event0: Power Button > /dev/input/event1: Power Button > /dev/input/event2: ROCCAT ROCCAT Vulcan 120 AIMO > /dev/input/event3: ROCCAT ROCCAT Vulcan 120 AIMO Mouse > /dev/input/event4: ROCCAT ROCCAT Vulcan 120 AIMO Consumer Control > /dev/input/event5: ROCCAT ROCCAT Vulcan 120 AIMO System Control > /dev/input/event6: ROCCAT ROCCAT Vulcan 120 AIMO > /dev/input/event7: ROCCAT ROCCAT Vulcan 120 AIMO > /dev/input/event8: Kensington Kensington Slimblade Trackball > /dev/input/event9: Logitech K800 > /dev/input/event10: Logitech Performance MX > /dev/input/event11: HDA ATI HDMI HDMI/DP,pcm=3 > /dev/input/event12: HDA ATI HDMI HDMI/DP,pcm=7 > /dev/input/event13: HDA ATI HDMI HDMI/DP,pcm=8 > /dev/input/event14: HDA ATI HDMI HDMI/DP,pcm=9 > /dev/input/event15: HDA ATI HDMI HDMI/DP,pcm=10 > /dev/input/event16: HDA ATI HDMI HDMI/DP,pcm=11 > /dev/input/event17: HDA ATI SB Rear Mic > /dev/input/event18: HDA ATI SB Line > /dev/input/event19: HDA ATI SB Line Out Front > /dev/input/event20: HDA ATI SB Line Out Surround > /dev/input/event21: HDA ATI SB Line Out CLFE > /dev/input/event22: HDA ATI SB Line Out Side > > listing #2, additional event codes on event 7: > Event code 140 (KEY_CALC) > Event code 142 (KEY_SLEEP) > Event code 150 (KEY_WWW) > Event code 152 (KEY_SCREENLOCK) > Event code 158 (KEY_BACK) > Event code 159 (KEY_FORWARD) > Event code 161 (KEY_EJECTCD) > Event code 163 (KEY_NEXTSONG) > Event code 164 (KEY_PLAYPAUSE) > Event code 165 (KEY_PREVIOUSSONG) > Event code 166 (KEY_STOPCD) > Event code 173 (KEY_REFRESH) > Event code 176 (KEY_EDIT) > Event code 177 (KEY_SCROLLUP) > Event code 178 (KEY_SCROLLDOWN) > Event code 179 (KEY_KPLEFTPAREN) > Event code 180 (KEY_KPRIGHTPAREN) > > Now the problem is that when pressing a key like caps lock or num lock > that causes actual data to be sent from the system to the input device > driver like e.g. EV_LED, random key code starts repeat. Usually this > key scan code is 185 which seems to respond F_15 which is non > physically existent. Sometimes it is KEY_A and sometimes it comes > (repeated a's) through to cli making terminal useless. Repeat interval > seems match with about 330msec. I have tested this without X on multi > user non graphical runlevel and wmi modules black listed without any > effect. Problem persists. I have also tested with actual physical > secondary keyboard and have been able to trigger this anomaly also > from there. Have to mention that when problem triggers, USB bus is > calm, any such URBs that does not belong there or are erroneously > extra URBs, exist. > > listing #3, spurious repeat triggered: > ...snip... > Key repeat handling: > Repeat type 20 (EV_REP) > Repeat code 0 (REP_DELAY) > Value 250 > Repeat code 1 (REP_PERIOD) > Value 33 > Properties: > Testing ... (interrupt to exit) > Event: time 1543226097.734226, type 17 (EV_LED), code 0 (LED_NUML), value 0 > Event: time 1543226097.734226, -------------- SYN_REPORT ------------ > Event: time 1543226098.542620, type 17 (EV_LED), code 0 (LED_NUML), value 1 > Event: time 1543226098.542620, -------------- SYN_REPORT ------------ > Event: time 1543226099.012511, type 17 (EV_LED), code 0 (LED_NUML), value 0 > Event: time 1543226099.012511, -------------- SYN_REPORT ------------ > Event: time 1543226099.216121, type 17 (EV_LED), code 0 (LED_NUML), value 1 > Event: time 1543226099.216121, -------------- SYN_REPORT ------------ > Event: time 1543226099.708439, type 17 (EV_LED), code 0 (LED_NUML), value 0 > Event: time 1543226099.708439, -------------- SYN_REPORT ------------ > Event: time 1543226100.102594, type 17 (EV_LED), code 0 (LED_NUML), value 1 > Event: time 1543226100.102594, -------------- SYN_REPORT ------------ > Event: time 1543226100.105320, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700ff > Event: time 1543226100.105320, type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1 > Event: time 1543226100.105320, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70004 > Event: time 1543226100.105320, type 1 (EV_KEY), code 30 (KEY_A), value 1 > Event: time 1543226100.105320, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006a > Event: time 1543226100.105320, type 1 (EV_KEY), code 185 (KEY_F15), value 1 > Event: time 1543226100.105320, -------------- SYN_REPORT ------------ > Event: time 1543226100.356129, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.356129, -------------- SYN_REPORT ------------ > Event: time 1543226100.391126, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.391126, -------------- SYN_REPORT ------------ > Event: time 1543226100.425134, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.425134, -------------- SYN_REPORT ------------ > Event: time 1543226100.459069, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.459069, -------------- SYN_REPORT ------------ > Event: time 1543226100.493130, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.493130, -------------- SYN_REPORT ------------ > Event: time 1543226100.508410, type 17 (EV_LED), code 0 (LED_NUML), value 0 > Event: time 1543226100.508410, -------------- SYN_REPORT ------------ > Event: time 1543226100.527129, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.527129, -------------- SYN_REPORT ------------ > Event: time 1543226100.561136, type 1 (EV_KEY), code 185 (KEY_F15), value 2 > Event: time 1543226100.561136, -------------- SYN_REPORT ------------ > ...snip... this means the data itself is generated by the device, value 2 is the kernel's signal that a key is repeating and there doesn't seem to be a release event. so the userspace layer (xkb) is going to repeat too (independently on the kernel because we ignore value 2 events). if you're on F29 with libinput >= 1.12.3, you can work around this for now with this quirk: $> cat /etc/libinput/local-overrides.quirks [roccat autorepeat] MatchName=ROCCAT ROCCAT Vulcan 120 AIMO MatchUdevTag=keyboard AttrEventCodeDisable=KEY_F15 This will simply ignore that specific key, so at least you can use your machine until the root of the issue is found. Obviously that won't work well if you disable KEY_A or any other actually useful key... > How should I continue? Should I place an bug report but to upstream or > Fedora's own bugzilla? either will do, I CC'd benjamin in case he wants it somewhere specific. Make sure you do attach the hid-recorder output for that device. Cheers, Peter _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
