Side effect of pressing special keys
Subsystems (2)
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).
Signature · 2 lines
Pali Rohár [email protected]
Quoted 4 lines · Pali Rohár
Hello,
pressing some keys on laptops could cause some side effects.
Quoted 8 lines
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
Signature · 6 lines
(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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · On Wednesday 03 December 2014 13:40:42 Pavel Machek wrote:
Quoted 9 lines · Pali Rohár
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:
Quoted 8 lines
Quoted 4 lines
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?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 2 lines · Pali Rohár
Ok, and what about
KEY_KBDILLUMTOGGLEwhen 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.
Signature · 8 lines
"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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · On Wednesday 03 December 2014 14:12:54 Henrique de Moraes Holschuh wrote:
Quoted 2 lines · Pali Rohár
Ok, and what about
KEY_KBDILLUMTOGGLEwhen 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?
Signature · 2 lines
Pali Rohár [email protected]
Quoted 18 lines · On Wednesday 03 December 2014 14:24:11 Pali Rohár wrote:
On Wednesday 03 December 2014 14:12:54 Henrique de Moraes
Quoted 9 lines · Holschuh
Quoted 2 lines · Pali Rohár
Ok, and what about
KEY_KBDILLUMTOGGLEwhen 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_KBDILLUMTOGGLEcause that BIOS change brightness and also KDE4 see it and change it too...
Quoted 4 lines
Similar problem there is with
KEY_WLANand NetworkManager.Gabriele, can you create patch which disable both
KEY_WLANandKEY_KBDILLUMTOGGLEindell-wmi.cdriver?
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 26 lines · On Wednesday 03 December 2014 14:38:15 Gabriele Mazzotta wrote:
Quoted 20 lines · On Wednesday 03 December 2014 14:24:11 Pali Rohár wrote:
On Wednesday 03 December 2014 14:12:54 Henrique de Moraes
Quoted 11 lines · Holschuh
Quoted 3 lines · Pali Rohár
Ok, and what about
KEY_KBDILLUMTOGGLEwhen 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_KBDILLUMTOGGLEcause that BIOS change brightness and also KDE4 see it and change it too...Quoted 4 lines
Similar problem there is with
KEY_WLANand NetworkManager.Gabriele, can you create patch which disable both
KEY_WLANandKEY_KBDILLUMTOGGLEindell-wmi.cdriver?
Quoted 7 lines
KEY_KBDILLUMTOGGLEis actually disabled already, butKEY_WLAN(which I guess it should changed toKEY_RFKILLnow that it exists) isn't, so I will submit a patch. The comment above it indell-wmi.cmakes 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.
Signature · 2 lines
Pali Rohár [email protected]