On Sun, Oct 17, 2010 at 08:32:22PM -0600, Joey Lee wrote: > Hi Carios, > > æ äï2010-10-15 æ 18:11 +0100ïCarlos Corbacho æåï > > On Friday 15 October 2010 09:02:01 Joey Lee wrote: > > > > Why would user chose one setup over another? I.e do we really need a > > > > module option or maybe we should pick up behavior and stick to it? > > > > > > When Acer notebook ship with Windows, they will preload a userland > > > application, the name is Launch Manager, it provide a GUI for end user > > > to change WLAN/BT/3G on/off state. > > > > [...] > > > > > Because the Launch Manager is userland application, so wmi driver only > > > can provide the function for it to call and don't have any way can > > > detect it from kernel module. > > > > Dmitry's point is still valid - why do we want to provide the userspace > > behaviour? Why not just handle it all in kernel using rfkill? > > Apparently networkign people is not quite happy with rfkill-input behavior and would like to move policy from the kernel into userspace. To tell the truth rfkill-input was never supposed to be the main mechanism but rather something that is usable at bootup and then the control would be handed off to userspace (if more complex policy is needed). > > Did you mean put the wifi hotkey behavior to acer-wmi driver or any x86 > laptop driver and implement by using rfkill? > > The wifi hotkey behavior is highly customization and different OEM have > different behavior. I am not sure put the wifi hotkey rule in kernel is > a good idea. OEMs have nothing to do with this, user is the entity that should be in control. > > In the future, there need have a userland rfkill policy daemon to > replace the rfkill-input module in kernel: > > Documentation/rfkill.txt > The rfkill-input will be: > * the deprecated rfkill-input module (an input layer handler, being > replaced by userspace policy code) and > > And here have a statement in feature-removal-schedule.txt > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c64fb01627e24725d1f9d535e4426475a4415753#patch1 > > +What: CONFIG_RFKILL_INPUT > +When: 2.6.33 > +Why: Should be implemented in userspace, policy daemon. > +Who: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > > So, we choice remove rfkill-input then put the logic in x86/platform > driver? > A simple question: > Userland policy daemon or kernel module, which one we want to put the > wifi hotkey behavior implementation? > > > We don't have Launch Manager for Linux, and quite frankly, I hope we never see > > it - relying on random, vendor specific applications to drive this kind of > > functionality is just asking for trouble. > > > > Acer BIOS team provide the function to OS for disable the EC hehavior, > it's available on window, why we hide it on Linux? > Either userland daemon or kernel module who want to implement the wifi > hotkey behavior, it need enable the launch-manager mode to disable the > default EC behavior on wifi hotkey. > > If don't want provide the launch-manager mode parameter to userland, can > we just direct enable it? > I believe that we simply need to tell EC to keep its hands off RF switch. As long as key is properly reported through input layer rfkill should be able to control the RF equipment, either via rfkill-input in-kernel shortcut or userspace daemon (when it is ready). Thanks. -- Dmitry -- 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
