Side effect of pressing special keys

Side effect of pressing special keys

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Hello,

pressing some keys on laptops could cause some side effects.

Example scenario 1:

Laptop has Fn key for enabling/disabling WIFI and when that key 
is pressed BIOS is doing two things:

1) Switch hard rfkill state of WIFI
2) Report that Fn key was pressed to kernel
   (either via i8042 bus or via ACPI/WMI)

Example scenario 2:

Another laptop has Fn key too, but BIOS does not change state of 
hard rfkill. So system (kernel or userspace) is responsible for 
interpreting what that Fn key means and call correct action (find 
rfkill device for WIFI and soft block it).

And my questions are:

1) What should userspace do if some input device report that 
KEY_WLAN or KEY_RFKILL was pressed?

2) Should kernel report to userspace that (on specific laptop) 
has pressed key some side effect?

3) How to deal with existing userspace application which 
interpret all pressed keys as described in example scenario 2 
also on laptops from scenario 1? KDE4, NetworkManager, ... are 
know to do that!

Note that this problem is not only about rfkill/wifi keys. Same 
apply for keyboard brightness Fn keys and also for key 
KEY_KBDILLUMTOGGLE (which toggle keyboard illumination level).

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

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

Re: Side effect of pressing special keys

[Pavel Machek]

On Sun 2014-11-23 14:41:17, Pali Rohár wrote:
> Hello,
> 
> pressing some keys on laptops could cause some side effects.
> 
> Example scenario 1:
> 
> Laptop has Fn key for enabling/disabling WIFI and when that key 
> is pressed BIOS is doing two things:
> 
> 1) Switch hard rfkill state of WIFI
> 2) Report that Fn key was pressed to kernel
>    (either via i8042 bus or via ACPI/WMI)

We should not really report that as a "key" to userspace. We might
want to report that rfkill state changed....
							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: Side effect of pressing special keys

[Pali Rohár]

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

On Wednesday 03 December 2014 13:40:42 Pavel Machek wrote:
> On Sun 2014-11-23 14:41:17, Pali Rohár wrote:
> > Hello,
> > 
> > pressing some keys on laptops could cause some side effects.
> > 
> > Example scenario 1:
> > 
> > Laptop has Fn key for enabling/disabling WIFI and when that
> > key is pressed BIOS is doing two things:
> > 
> > 1) Switch hard rfkill state of WIFI
> > 2) Report that Fn key was pressed to kernel
> > 
> >    (either via i8042 bus or via ACPI/WMI)
> 
> We should not really report that as a "key" to userspace. We
> might want to report that rfkill state changed....
> 							Pavel

Ok, and what about KEY_KBDILLUMTOGGLE when bios also handle 
keyboard backlight level? Should be this key filtered too?

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

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

Re: Side effect of pressing special keys

[Henrique de Moraes Holschuh]

On Wed, 03 Dec 2014, Pali Rohár wrote:
> Ok, and what about KEY_KBDILLUMTOGGLE when bios also handle 
> keyboard backlight level? Should be this key filtered too?

IME, heck yes.

If you ever make the mistake of sending to userspace something the
BIOS/kernel already reacted to, they will find a way to loop it back to you
and cause all sort of issues.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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: Side effect of pressing special keys

[Pali Rohár]

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

On Wednesday 03 December 2014 14:12:54 Henrique de Moraes 
Holschuh wrote:
> On Wed, 03 Dec 2014, Pali Rohár wrote:
> > Ok, and what about KEY_KBDILLUMTOGGLE when bios also handle
> > keyboard backlight level? Should be this key filtered too?
> 
> IME, heck yes.
> 
> If you ever make the mistake of sending to userspace something
> the BIOS/kernel already reacted to, they will find a way to
> loop it back to you and cause all sort of issues.

Ok, I think same. In KDE4 I see some loop/noop operation when new 
dell keyboard backlight driver is used. Key KEY_KBDILLUMTOGGLE 
cause that BIOS change brightness and also KDE4 see it and change 
it too...

Similar problem there is with KEY_WLAN and NetworkManager.

Gabriele, can you create patch which disable both KEY_WLAN and 
KEY_KBDILLUMTOGGLE in dell-wmi.c driver?

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

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

Re: Side effect of pressing special keys

[Gabriele Mazzotta]

On Wednesday 03 December 2014 14:24:11 Pali Rohár wrote:
> On Wednesday 03 December 2014 14:12:54 Henrique de Moraes
> 
> Holschuh wrote:
> > On Wed, 03 Dec 2014, Pali Rohár wrote:
> > > Ok, and what about KEY_KBDILLUMTOGGLE when bios also handle
> > > keyboard backlight level? Should be this key filtered too?
> > 
> > IME, heck yes.
> > 
> > If you ever make the mistake of sending to userspace something
> > the BIOS/kernel already reacted to, they will find a way to
> > loop it back to you and cause all sort of issues.
> 
> Ok, I think same. In KDE4 I see some loop/noop operation when new
> dell keyboard backlight driver is used. Key KEY_KBDILLUMTOGGLE
> cause that BIOS change brightness and also KDE4 see it and change
> it too...
> 
> Similar problem there is with KEY_WLAN and NetworkManager.
> 
> Gabriele, can you create patch which disable both KEY_WLAN and
> KEY_KBDILLUMTOGGLE in dell-wmi.c driver?

KEY_KBDILLUMTOGGLE is actually disabled already, but KEY_WLAN (which
I guess it should changed to KEY_RFKILL now that it exists) isn't, so
I will submit a patch. The comment above it in dell-wmi.c makes me think
that for all the systems the BIOS does everything and not only mine.

Gabriele
--
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: Side effect of pressing special keys

[Pali Rohár]

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

On Wednesday 03 December 2014 14:38:15 Gabriele Mazzotta wrote:
> On Wednesday 03 December 2014 14:24:11 Pali Rohár wrote:
> > On Wednesday 03 December 2014 14:12:54 Henrique de Moraes
> > 
> > Holschuh wrote:
> > > On Wed, 03 Dec 2014, Pali Rohár wrote:
> > > > Ok, and what about KEY_KBDILLUMTOGGLE when bios also
> > > > handle keyboard backlight level? Should be this key
> > > > filtered too?
> > > 
> > > IME, heck yes.
> > > 
> > > If you ever make the mistake of sending to userspace
> > > something the BIOS/kernel already reacted to, they will
> > > find a way to loop it back to you and cause all sort of
> > > issues.
> > 
> > Ok, I think same. In KDE4 I see some loop/noop operation
> > when new dell keyboard backlight driver is used. Key
> > KEY_KBDILLUMTOGGLE cause that BIOS change brightness and
> > also KDE4 see it and change it too...
> > 
> > Similar problem there is with KEY_WLAN and NetworkManager.
> > 
> > Gabriele, can you create patch which disable both KEY_WLAN
> > and KEY_KBDILLUMTOGGLE in dell-wmi.c driver?
> 
> KEY_KBDILLUMTOGGLE is actually disabled already, but KEY_WLAN
> (which I guess it should changed to KEY_RFKILL now that it
> exists) isn't, so I will submit a patch. The comment above it
> in dell-wmi.c makes me think that for all the systems the
> BIOS does everything and not only mine.
> 
> Gabriele

KEY_KBDILLUMTOGGLE is not disabled for sure. I see it in log from 
input-events program.

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

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