Hi Joey, > Yes, per Alan's patch, there have another issue need to workaround by > set the block state to global, and those code might need removed in the > future: > > commit b3fa1329eaf2a7b97124dacf5b663fd51346ac19 > Author: Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx> > Date: Mon Jun 8 13:27:27 2009 +0100 > > .... > > Drivers with persistent state will affect the global state only if > rfkill-input is enabled. This is required, otherwise booting with > wireless soft-blocked and pressing the wireless-toggle key once would > have no apparent effect. This special case will be removed in future > along with rfkill-input, in favour of a more flexible userspace daemon > (see Documentation/feature-removal-schedule.txt). Well, right, that's just hinting that rfkill-input will be removed at some point, hopefully! > But, > the above code replicate acer-wmi's initial state to global, then set to hci0's > BT initial state. Right. > > 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? > > 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: > 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. > > 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 on Wifi where the disconnect issue doesn't typically appear. > > 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? > 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 -- 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
