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 .. 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. -- 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
