* Handling special keys in platform drivers @ 2012-01-09 6:24 Corentin Chary 2012-01-09 7:09 ` joeyli 2012-01-13 22:42 ` Matthew Garrett 0 siblings, 2 replies; 5+ messages in thread From: Corentin Chary @ 2012-01-09 6:24 UTC (permalink / raw) To: platform-driver-x86; +Cc: LKML, Matthew Garrett, linux-input Hi, Some of the platform drivers in platform/x86/ (and probably other) are relaying keys to userspace and are also controlling the device associated to these key. A simple example is screen brightness, keyboard backlight or rfkill. In this case the driver send a key to userspace, userspace has to handle this key and control the right device. Most of the time, this job is done by: - ACPI scripts (legacy) - DE (gnome-power-manager, kde's solid) The real problem is that for keyboard backlight to work, it needs DE cooperation, and only gnome as implemented that right now, and other (except KDE) will probably neither have the resources to handle all the possible keys correctly. And of course, who should handle the keys when there is no DE running at all ? So I was wondering if we could introduce an "auto" mode for this drivers. For example, with this mode enabled, asus-wmi would filter the keys and control keyboard backlight directly (and rfkill/screen brightness ?). What do you think about it ? Thanks, -- Corentin Chary http://xf.iksaif.net ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Handling special keys in platform drivers 2012-01-09 6:24 Handling special keys in platform drivers Corentin Chary @ 2012-01-09 7:09 ` joeyli 2012-01-09 7:34 ` Corentin Chary 2012-01-13 22:42 ` Matthew Garrett 1 sibling, 1 reply; 5+ messages in thread From: joeyli @ 2012-01-09 7:09 UTC (permalink / raw) To: Corentin Chary Cc: platform-driver-x86, LKML, Matthew Garrett, linux-input, GLin Hi Corentin, 於 一，2012-01-09 於 07:24 +0100，Corentin Chary 提到： > Hi, > > Some of the platform drivers in platform/x86/ (and probably other) are > relaying keys to userspace and are also controlling the device > associated to these key. A simple example is screen brightness, > keyboard backlight or rfkill. > > In this case the driver send a key to userspace, userspace has to > handle this key and control the right device. > > Most of the time, this job is done by: > - ACPI scripts (legacy) > - DE (gnome-power-manager, kde's solid) > > The real problem is that for keyboard backlight to work, it needs DE > cooperation, and only gnome as implemented that right now, and other > (except KDE) will probably neither have the resources to handle all > the possible keys correctly. And of course, who should handle the keys > when there is no DE running at all ? > > So I was wondering if we could introduce an "auto" mode for this > drivers. For example, with this mode enabled, asus-wmi would filter > the keys and control keyboard backlight directly (and rfkill/screen > brightness ?). > > What do you think about it ? > > Thanks, > For backlight, I think control backlight in platform driver is generally no problem, but need careful don't keep/change brightness level if BIOS also keep a variable reflect to brightness level. Another question is when the "auto" mode disable? Does it possible disable it from user space? Currently, like rfkill-input can disabled by ioctl from user space, e.g. urfkill daemon will disable rfkill-input by ioctl when it launched. For rfkill, I am not prefer allow platform driver direct control rfkill. that might more complex because already have the follow components involve to it when function key pressed: BIOS/EC (ODM backup behavior) rfkill-input wireless/bluetooth drivers user space daemon/applications (e.g. NetworkManager, urfkill...) Then, will platform driver also involve to rfkill control? We already have rfkill-input in kernel to control rfkill state, if need more flexible policy control on rfkill key, put policy logic in user space will be better. e.g. User can setup rfkill policy by account. Thanks a lot! Joey Lee ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Handling special keys in platform drivers 2012-01-09 7:09 ` joeyli @ 2012-01-09 7:34 ` Corentin Chary 0 siblings, 0 replies; 5+ messages in thread From: Corentin Chary @ 2012-01-09 7:34 UTC (permalink / raw) To: joeyli; +Cc: platform-driver-x86, LKML, Matthew Garrett, linux-input, GLin On Mon, Jan 9, 2012 at 8:09 AM, joeyli <jlee@suse.com> wrote: > Hi Corentin, > > 於 一，2012-01-09 於 07:24 +0100，Corentin Chary 提到： >> Hi, >> >> Some of the platform drivers in platform/x86/ (and probably other) are >> relaying keys to userspace and are also controlling the device >> associated to these key. A simple example is screen brightness, >> keyboard backlight or rfkill. >> >> In this case the driver send a key to userspace, userspace has to >> handle this key and control the right device. >> >> Most of the time, this job is done by: >> - ACPI scripts (legacy) >> - DE (gnome-power-manager, kde's solid) >> >> The real problem is that for keyboard backlight to work, it needs DE >> cooperation, and only gnome as implemented that right now, and other >> (except KDE) will probably neither have the resources to handle all >> the possible keys correctly. And of course, who should handle the keys >> when there is no DE running at all ? >> >> So I was wondering if we could introduce an "auto" mode for this >> drivers. For example, with this mode enabled, asus-wmi would filter >> the keys and control keyboard backlight directly (and rfkill/screen >> brightness ?). >> >> What do you think about it ? >> >> Thanks, >> > > For backlight, > I think control backlight in platform driver is generally no problem, > but need careful don't keep/change brightness level if BIOS also keep a > variable reflect to brightness level. Hum, for screen brightness, try to start without any desktop environment on a laptop where the keys don't control the BIOS and only send input events, and you won't be able to change the screen brightness. This is actually worse for keyboard backlight since only gnome support it. > Another question is when the "auto" mode disable? Does it possible > disable it from user space? Probably only a module parameter. And disabled by default. > Currently, like rfkill-input can disabled by ioctl from user space, e.g. > urfkill daemon will disable rfkill-input by ioctl when it launched. > > > For rfkill, > I am not prefer allow platform driver direct control rfkill. Yeah rfkill was just an example, of such interaction, but your right rfkill support is currently pretty good. > that might more complex because already have the follow components > involve to it when function key pressed: > BIOS/EC (ODM backup behavior) > rfkill-input > wireless/bluetooth drivers > user space daemon/applications (e.g. NetworkManager, urfkill...) > > Then, will platform driver also involve to rfkill control? > > We already have rfkill-input in kernel to control rfkill state, if need > more flexible policy control on rfkill key, put policy logic in user > space will be better. > e.g. User can setup rfkill policy by account. -- Corentin Chary http://xf.iksaif.net ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Handling special keys in platform drivers 2012-01-09 6:24 Handling special keys in platform drivers Corentin Chary 2012-01-09 7:09 ` joeyli @ 2012-01-13 22:42 ` Matthew Garrett 2012-01-14 8:58 ` Corentin Chary 1 sibling, 1 reply; 5+ messages in thread From: Matthew Garrett @ 2012-01-13 22:42 UTC (permalink / raw) To: Corentin Chary; +Cc: platform-driver-x86, LKML, linux-input On Mon, Jan 09, 2012 at 07:24:14AM +0100, Corentin Chary wrote: > The real problem is that for keyboard backlight to work, it needs DE > cooperation, and only gnome as implemented that right now, and other > (except KDE) will probably neither have the resources to handle all > the possible keys correctly. And of course, who should handle the keys > when there is no DE running at all ? The problem with handling this in kernel is that there isn't an obviously correct policy. ACPI will typically only expose 16 or so backlight levels so the behaviour is easy enough, but (depending on how the hardware is wired up) i915 may expose around 20,000. Further, one machine may expose different backlight controls for different displays, and in that situation you need to know which one the input event is expected to correspond to. Doing backlight control properly involves a lot of policy work, and I'm reluctant to argue that that ought to be in the kernel. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Handling special keys in platform drivers 2012-01-13 22:42 ` Matthew Garrett @ 2012-01-14 8:58 ` Corentin Chary 0 siblings, 0 replies; 5+ messages in thread From: Corentin Chary @ 2012-01-14 8:58 UTC (permalink / raw) To: Matthew Garrett; +Cc: platform-driver-x86, LKML, linux-input On Fri, Jan 13, 2012 at 11:42 PM, Matthew Garrett <mjg@redhat.com> wrote: > On Mon, Jan 09, 2012 at 07:24:14AM +0100, Corentin Chary wrote: > >> The real problem is that for keyboard backlight to work, it needs DE >> cooperation, and only gnome as implemented that right now, and other >> (except KDE) will probably neither have the resources to handle all >> the possible keys correctly. And of course, who should handle the keys >> when there is no DE running at all ? > > The problem with handling this in kernel is that there isn't an > obviously correct policy. ACPI will typically only expose 16 or so > backlight levels so the behaviour is easy enough, but (depending on how > the hardware is wired up) i915 may expose around 20,000. Further, one > machine may expose different backlight controls for different displays, > and in that situation you need to know which one the input event is > expected to correspond to. > > Doing backlight control properly involves a lot of policy work, and I'm > reluctant to argue that that ought to be in the kernel. But in the case of asus-wmi, that handle both the keys and the keyboard_backlight, could such handling be done in the kernel ? -- Corentin Chary http://xf.iksaif.net ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-14 8:59 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-09 6:24 Handling special keys in platform drivers Corentin Chary 2012-01-09 7:09 ` joeyli 2012-01-09 7:34 ` Corentin Chary 2012-01-13 22:42 ` Matthew Garrett 2012-01-14 8:58 ` Corentin Chary
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).