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
[email protected]
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
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
[email protected]
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
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
[email protected]
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
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
[email protected]