Hi Joey Lee, On Tuesday 15 March 2011 12:11:50 Joey Lee wrote: > Hi OldÅich, > > æ äï2011-03-11 æ 14:45 -0700ïJoey Lee æåï > > > Hi OldÅich, > > > > > > > > > > > 1. I have to enable the HW bluetooth switch to get the > > > > > > > > > bluetooth LED running (USB device appears in lsusb). The > > > > > > > > > acer-bluetooth SW rfkill is unblocked, the SW rfkill of > > > > > > > > > hci0 is blocked. > > > > > > > > > > > > > > > > Yes, this is also right behavior, because acer-wmi driver > > > > > > > > will maintain the killswitch status with BIOS. > > > > > > > > > > > > > > > > > 2. Next I have to unblock SW rfkill on hci0 by a call to > > > > > > > > > `rfkill unblock <number of hci0>`. > > > > > > > > > 3. Last I have to enable the HCI by the call to `hciconfig > > > > > > > > > hci0 up`. > > > > > > > > > > `rfkill list` shows the following > > > > > > > > > > 1) Before I enable the SW killswitch: > > > > > > > > > > 0: acer-wireless: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 1: acer-bluetooth: Bluetooth > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > > > 2: acer-threeg: Wireless WAN > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > > > 3: phy0: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 2) After I run `rfkill unblock 1`: > > > > > > > > > > 0: acer-wireless: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 1: acer-bluetooth: Bluetooth > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 2: acer-threeg: Wireless WAN > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > > > 3: phy0: Wireless LAN > > > > > > > > > > Soft blocked: no > > > > > Hard blocked: no > > > > > > > > > > 6: hci0: Bluetooth > > > > > > > > > > Soft blocked: yes > > > > > Hard blocked: no > > > > > > > > > > I've repeated it several times, so hci0 has number 6 now. > > > > > > > > > > Thanks for help, > > > > > OldÅich. > > > > > > > > Thank's for your test result. > > > > Want to double confirm with you... > > > > The above result is base on CONFIG_RFKILL_INPUT=N ? > > > > > > No, that was just a formatting problem of a "reply" to a mail. That > > > wasn't my reaction, it was just a word from the previous line. I'm > > > still using CONFIG_RFKILL_INPUT=Y. > > > > > > OldÅich. > > > > That's make sense now! > > > > Thank's for your bug report, I am tracing and try to find out solution. > > Joey Lee > > After trace rfkill-input stuff, I thought this is rfkill-input's normal > behavior but not a bug. > > Unfortunately, I didn't find any workaround way when a driver need to > call rfkill_init_sw_state, e.g. acer-wmi driver. > > The rfkill-input will sync the rfkill state to all killswitchs that have > the same type. For example, acer-wmi set the initial software switch to > _BLOCK_ when driver initial, then rfkill-input will also set any new > bluetooth killswitch state to _BLOCK_ . The rfkill_sync_work syncs with rfkill_global_states, which is set during intitialization or by rfkill_switch_all, if I read it correctly. This should be independent to acer-bluetooth state. The rfkill_global_states[BLUETOOTH] should be unblocked initially, I need to verify it. There is some magic in rfkill/input.c that plays with global states, but I don't know if or how that one is used in my case. > Acer's BIOS default setup bluetooth's state is disable when system cold > boot, and BIOS also can save the connection devices' state when system > reboot. Currently, acer-wmi driver have right behavior to sync the state > with BIOS. > > Face to your situation, my suggestion is: > > - Use userland application to correct killswitch state. > highly suggest You can try urfkill daemon: > http://www.freedesktop.org/wiki/Software/urfkill or > write a startup script to enable bluetooth when system boot. > > - Disable rfkill-input module if you didn't real use it. > The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but > doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you > enable bluetooth killswitch. I didn't have time to look at the problem more deeply to identify who is setting the global state to "blocked" or what really happens. Anyway, I did some testing with pressing the HW bluetooth switch and I saw the following immediately _after_ pressing the HW switch to enable bluetooth: oldium ~ # rfkill list 0: acer-wireless: Wireless LAN Soft blocked: no Hard blocked: no 1: acer-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: acer-threeg: Wireless WAN Soft blocked: yes Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no I had this output 3 times immediately after each other. I'm using keyboard "up" and "enter" to repeat the last shell command, so this is a relatively slow operation. So the state when the acer-bluetooth was unblocked stayed for relatively long time before hci0 appeared in rfkill. Afterwards I saw: oldium ~ # rfkill list 0: acer-wireless: Wireless LAN Soft blocked: no Hard blocked: no 1: acer-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 2: acer-threeg: Wireless WAN Soft blocked: yes Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 5: hci0: Bluetooth Soft blocked: yes Hard blocked: no So it looks like the hci0 went blocked even when the acer-bluetooth switch was unblocked. So it looks like the hci0 state is independent on the initial acer- bluetooth state. Hopefully I have some time this evening (CET timezone) to add some stack traces and logs to see what really happens on my system. Cheers, OldÅich. > > Thank's a lot! > Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
