Hi Johannes, æ åï2011-03-24 æ 09:35 +0100ïJohannes Berg æåï > > > > Hmm, that I don't understand. Why would that reproduce the issue? Ah, > > > ok, that's because __rfkill_switch_all() will set global_states, and it > > > happens during init. So it gets registered with the global state, which > > > is still blocked since you just unblocked this single thing. > > > > > > > I have no Bluetooth HW key on my machine, but OldÅich can reproduce this > > issue by HW key. > > Yeah but the hw key doesn't send key events? > It's a good question need to check with OldÅich for his machine. If talk about my Acer TravelMate 8572, NO! My machine only have wifi hotkey, but either BIOS/EC raw mode or wmi mode, the key does not emit any KEY_* keycode. But, yes, thank's your remind, as I remember, in some Acer consumer notebook, they also emit scancode when hotkey pressed, like you said, maybe they emit both wmi event and scancode. Not on my machine but need check OldÅich's machine. > > > So, it seems that the design here only works if > > > > The "the design" means call rfkill_init_sw_state before rfkill register? > > I mean the whole notion of persistent rfkill state. > > > > a) the bios stores the last state > > > > This issue happen when "Bluetooth's initial state is disabled before > > system boot.", maybe user choice disable bluetooth at last time reboot, > > then BIOS keep BT disable. > > > > > b) the driver only reports key inputs, no rfkill inputs > > > > > > > If only use bluetooth HW key to control the rfkill, then it should be > > > > fine. But, OldÅich report still have problem cann't enable bluetooth > > > > after he press HW key because hci0's bluetooth default set to soft > > > > blocked. > > > > > > Yeah that's because the BT hw key seems to generate the wrong event? > > > > > > > No, BT HW key doesn't emit KEY_BLUETOOTH, it emit wmi event, then > > acer-wmi driver transfer to KEY_BLUETOOTH. Then I think rfkill-input (if > > enabled) also receive KEY_BLUETOOTH. > > But is this WMI event really intended to be a key event? But ok, that > just means the reason is what you said: > Yes, the wmi event is must be a KEY_ event on linux platform, because it was emited by user press hotkey. > > I thought maybe it's a race condition the hci0 rfkill generated before > > rfkill-input key work for update the global state ? > > Yeah, most likely. > > > > Well I don't think we want to remove rfkill input, ever, because that > > > just leads to a mess where the user has to take action. I'd rather have > > > it work out of the box and be overridden by urfkill which should work > > > fine. > > > > So, we should remove the following statement in > > Documentation/feature-removal-schedule.txt ? > > > > What: CONFIG_RFKILL_INPUT > > When: 2.6.33 > > Why: Should be implemented in userspace, policy daemon. > > Who: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > > Ah, heh, no, although we've not been able to do this I think we still > want it. But until people do routinely use urfkill, I think we can't > remove it because otherwise things just won't work right. > I thought still need time to promote urfkill. > > > But due the the behaviour you outlined earlier, I think your patch makes > > > sense... the BIOS doesn't actually seem to _store_ the rfkill state > > > anyway, since it's always off when you cold boot. So why bother using > > > that state as the default anyway? > > > > > > > It's tricky to me for use rfkill_init_sw_state. > > > > When rfkill-input disabled, everything works fine, but if rfkill-input > > enabled, then I need very careful to know it will change the global > > state and causes the global state replicate to any new rfkill. > > > > Honest, I don't know the rfkill_init_sw_state have the above condition > > before I read rfkill source code. > > Right -- I've only come to understand the exact details during this > discussion myself. Alan probably modelled it o> > > That will work around the problem at hand by making the acer wmi enable > > > BT whenever it is loaded, but that doesn't seem so bad either. > > > > > > > Yes, it's not good idea, BIOS can save device states when system reboot, > > I don't want erase the state. > > So it _does_ store the state? I thought you earlier said it didn't store > it, and when you cold rebooted it was always disabled? > There have 2 different behavior on Acer BIOS: - cold boot (shutdown then power on): BIOS will reset to raw state (WLAN on, BT off, WWAN on) - warm boot (reboot): BIOS will keep last time's state > > I agreed your point or the urfkill daemon, does it possible we add > > urfkill daemon information to Kernel document? > > Yeah I guess we can do that, don't think it'll help much though :) > > johannes > I thought still have some engineer will look at kernel document, I will send patch for add urfkill daemon information to kernel document and add Cc. to you for review. Thank's a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
