On Tue, Oct 19, 2010 at 5:49 PM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Tue, Oct 19, 2010 at 03:28:43PM +0200, Corentin Chary wrote: >> On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@xxxxxxxxxx> wrote: >> > Hi Corentin, >> > >> > æ äï2010-10-19 æ 05:15 -0600ïJoey Lee æåï >> >> Hi Corentin, >> >> >> >> æ äï2010-10-19 æ 12:51 +0200ïCorentin Chary æåï >> >> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them >> >> > >> will be happy if they can configure the behavior of the key (cycle, only toggle >> >> > >> WLAN, etc...) >> >> > >> >> >> > > >> >> > > I thought just direct disable the default EC behavior then leave a >> >> > > userland daemon to control the behavior, it will grab the wifi key event >> >> > > then control rfkill state by follow user's customization rules. >> >> > >> >> > What I'm saying is: I don't really care what's the default behavior is, >> >> > but if the EC provide a somewhat reliable way to make the key work >> >> > without any userspace daemon involved, I think we should allow >> >> > the user to use this mode (even if it's with an obscure module >> >> > parameter or sysfs file). > > But we already have the in-kernel solution that provides this behavior. > It is called rfkill-input and it is the in-kernel bridge between input > devices that emit KEY_WLAN etc. and rfkill switches. There is no need to > have yet another mechanism (most likely fighting with default in-kernel > one) doing the same thing. So for boxes tat do support this launcher > mode we should simply enable it. _Always_. > > And once the userspace manager[s] become standard we can just rely on > their presence. Like right now you can't really live without udev, dbus, > etc. if you want to have reasonably behaving box (embedded setups out of > scope here). > >> >> > >> >> > But .. maybe if someone want this default "raw" behavior, >> >> > he should just not load this module. >> >> > >> >> >> >> Fully understood, now. >> >> >> >> Like you siad, we need define a policy for: >> >> >> >> Â- If user want the default "raw" behavior, what do they need to do? >> >> Â Â Â I thought if the wmi driver doesn't load by default, then user >> >> Â Â Â Âwill get a "raw" behavior. >> >> >> > But... >> > The wmi driver doesn't just provide the RF switch function, it's also >> > have other functions like transfer wmi event to key code. >> > >> > User doesn't load wmi driver will have "raw" RF switch behavior, but >> > lost other more functions. >> > >> >> Â- If any distro want provide userland solution, how can they disable >> >> Â Âthe default "raw" behavior? >> >> Â Â Â If anybody want to disable the "raw" behavior, just load the wmi >> >> Â Â Â Âdriver. >> > Maybe we still add kernel module parameter? >> > >> >> Indeed, I think it would be a good idea to let the user do that. >> > > And I do not think so for the reasons outlined. We have chosen the > direction already (dictated by the existence of keys not directly > connected withg RF switches) and we should follow through with it, so > all boxes and drivers behave as uniformly as possible. > Then, let's not add this parameter. Anyway the potential user base who may acer-wmi without this mode is probably very low. But I still think that having a parameter to enable this "raw" mode would be helpful in some case, for example, "the keycode changed and is not yet mapped to KEY_WLAN", or "wimax is not yet supported by acer-wmi and there is not (yet) a rfkill interface for it". This would be a quirk mode, only enabled for some very special cases, like acpi_osi="Linux" or acpi_backlight="vendor". -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
