On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <[email protected]> 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 platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
