Reported key not released

Reported key not released

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1604 bytes --]

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?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Reported key not released

[Matthew Garrett]

On Sun, Nov 23, 2014 at 02:13:30PM +0100, Pali Rohár wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reported key not released

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 590 bytes --]

On Monday 24 November 2014 21:04:33 Matthew Garrett wrote:
> On Sun, Nov 23, 2014 at 02:13:30PM +0100, Pali Rohár wrote:
> > 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?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Reported key not released

[Matthew Garrett]

On Mon, Nov 24, 2014 at 09:58:32PM +0100, Pali Rohár wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Reported key not released

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 836 bytes --]

On Monday 24 November 2014 22:51:47 Matthew Garrett wrote:
> On Mon, Nov 24, 2014 at 09:58:32PM +0100, Pali Rohár wrote:
> > 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.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]