Hi Dmitry, æ æï2010-10-17 æ 21:07 -0700ïDmitry Torokhov æåï > 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). > Yes, currently, we use ioctl to disable the rfkill-input when our userland rfkill daemon enabled. http://www.mail-archive.com/devkit-devel@xxxxxxxxxxxxxxxxxxxxx/msg00858.html > > > > 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). > I agree EC don't need touch the RF switch by default, I will contact with them to discuss. But, Currently, the Acer BIOS already shipped to world wide, and BIOS guys give me tThat's why I contribute launch-manager mode patch to here. Thank's a lot! Joey Lee -- 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
