Reported key not released
Subsystems (2)
Hello,
my laptop (Dell Latitude E6440) has HW switch which for disabling some radio devices (bluetooth, wifi, 3g; list of devices can be configured in BIOS).
When I enable or disable this switch it correctly enable or disable devices (and also hard rfkill status is set correctly).
But problem is that switch generate key press event on i8042 keyboard controller without release event. See output:
$ sudo input-events 4 /dev/input/event4 bustype : BUS_I8042 vendor : 0x1 product : 0x1 version : 43841 name : "AT Translated Set 2 keyboard" phys : "isa0060/serio0/input0" bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP
waiting for events
...
(here I enabled switch)
14:04:07.047897: EV_MSC MSC_SCAN 136
14:04:07.047897: EV_KEY KEY_UNKNOWN (0xf0) pressed
14:04:07.047897: EV_SYN code=0 value=0
(and after that my terminal emulator start writing dummy chars) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@1
(here I disabled switch)
14:04:08.730526: EV_MSC MSC_SCAN 136 14:04:08.730526: EV_KEY KEY_UNKNOWN (0xf0) pressed 14:04:08.730526: EV_SYN code=0 value=0
So I think that above chars were written because there was no release event.
I have two questions:
1) Should kernel for this special switch key emit also release event? And if yes, how to do that if keyboard controller do not do that?
2) It is possible to remap KEY_UNKNOWN to something meaningful? Or it should be KEY_UNKNOWN iff BIOS already handle hard rfkill state?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 2 lines · Pali Rohár
When I enable or disable this switch it correctly enable or disable devices (and also hard rfkill status is set correctly).
If the switch changes the rfkill state, you shouldn't be emitting any presses - the rfkill state change will notify userspace. Consume the event in the filter and don't pass it through.
Signature · 5 lines
Matthew Garrett | [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · On Monday 24 November 2014 21:04:33 Matthew Garrett wrote:
Quoted 3 lines · Pali Rohár
When I enable or disable this switch it correctly enable or disable devices (and also hard rfkill status is set correctly).
If the switch changes the rfkill state, you shouldn't be emitting any presses - the rfkill state change will notify userspace. Consume the event in the filter and don't pass it through.
So kernel should filter i8042 atk key press events which represent HW switch?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 2 lines · Pali Rohár
So kernel should filter i8042 atk key press events which represent HW switch?
Yeah - the firmware is sending an "Update rfkill state" message, not a real keypress. If you're already listening for those events through a filter then you should just drop them once you've done the state update.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · On Monday 24 November 2014 22:51:47 Matthew Garrett wrote:
Quoted 2 lines · Pali Rohár
So kernel should filter i8042 atk key press events which represent HW switch?
Yeah - the firmware is sending an "Update rfkill state" message, not a real keypress. If you're already listening for those events through a filter then you should just drop them once you've done the state update.
Now I wanted to do not use i8042 hook function in dell-laptop.c which was used only for receiving key event (hw switch) and propagating it to dell-laptop rfkill device. See my patch:
dell-laptop: Use dell-rbtn instead i8042 filter when possible
But if we really should drop these atk key press, then another patch for it will be needed.
Signature · 2 lines
Pali Rohár [email protected]