æ äï2011-03-21 æ 21:44 +0100ïOldÅich JedliÄka æåï > Hi Joey Lee, > > On Monday 21 March 2011 18:52:58 Joey Lee wrote: > > Hi OldÅich, > > > > æ äï2011-03-21 æ 05:26 -0600ïJoey Lee æåï > > > > > Add Cc. to experts: Johannes Berg, David S. Miller, Marcel Holtmann and > > > Gary Lin > > > > > > Hi OldÅich, > > > > > > æ æï2011-03-20 æ 21:09 +0100ïOldÅich JedliÄka æåï > > > > > > > Hi Joey Lee, > > > > > > > > Finally I've got little time to expriment. > > > > > > Thank's for you also reserve time to trace it. And, I also add comment > > > on bugzilla: > > > https://bugzilla.kernel.org/show_bug.cgi?id=31002 > > > > > > > On Wednesday 16 March 2011 09:59:16 Joey Lee wrote: > > > > > Hi OldÅich, > > > > > > > > > > æ äï2011-03-16 æ 07:32 +0100ïOldÅich JedliÄka æåï > > > > > > > > > > > > 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. > > > > > > > > > > Yes! > > > > > Ideally, killswitch state should be independent to different driver, > > > > > even the killswitch type is the same. > > > > > > > > > > But, > > > > > If you enabled CONFIG_RFKILL_INPUT, then rfkill_register will > > > > > replicate state for each killswitch that have the same type: > > > > > > > > > > vi net/rfkill/core.c > > > > > > > > > > int __must_check rfkill_register(struct rfkill *rfkill) > > > > > { > > > > > ... > > > > > > > > > > if (!rfkill->persistent || rfkill_epo_lock_active) { > > > > > > > > > > schedule_work(&rfkill->sync_work); > > > > > > > > > > } else { /* if rfkill->persistent then set the state > to all > > > > > > > > the > > > > > > > > > same type */ #ifdef CONFIG_RFKILL_INPUT /* when CONFIG_RFKILL_INPUT = > > > > > Y */ > > > > > > > > > > bool soft_blocked = !!(rfkill->state & > > > > > RFKILL_BLOCK_SW); > > > > > > > > > > if (!atomic_read(&rfkill_input_disabled)) > > > > > > > > > > __rfkill_switch_all(rfkill->type, > > > > > soft_blocked); /* > > > > > > > > > > here call switch all to sync state */ #endif > > > > > > > > > > } > > > > > > > > > > When any driver call rfkill_init_sw_state for set the initial state > > > > > to killswitch, this rfkill->persistent will set to true: > > > > > > > > > > void rfkill_init_sw_state(struct rfkill *rfkill, bool blocked) /* > > > > > acer- > > > > > > > > wmi > > > > > > > > > driver used it to set inital killswitch state */ { > > > > > .... > > > > > > > > > > spin_lock_irqsave(&rfkill->lock, flags); > > > > > __rfkill_set_sw_state(rfkill, blocked); > > > > > rfkill->persistent = true /* persistent set to > true */ > > > > > > > > > > That's why acer-wmi bluetooth killswitch's state was been replicate > > > > > to hci_core's killswitch state. > > > > > > > > > > When CONFIG_RFKILL_INPUT set to Y, and any driver call > > > > > rfkill_init_sw_state before register rfkill, then rfkill_register > > > > > will try to sync state to the same killswitch type like the above. > > > > > > > > > > It's make sense, > > > > > because rfkill-input only can block/unblock the same killswitch type > > > > > at the same time, before rfkill-input active, it want all the same > > > > > type's state is full the same. > > > > > > > > > > And, > > > > > rfkill-input also suppose user only can use keycode (maybe Fn key) to > > > > > control killswitch state, so, direct use rkill tool or echo state to > > > > > killswitch for change the state will cause killswitchs' state lost > > > > > link. It like we do. > > > > > > > > > > > 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. > > > > > > > > > > Suggest you can disable CONFIG_RFKILL_INPUT or markup the following > > > > > code. You will see the new bluetooth killswitch will be unblock when > > > > > it created. > > > > > > > > > > diff --git a/net/rfkill/core.c b/net/rfkill/core.c > > > > > index 0198191..0dec078 100644 > > > > > --- a/net/rfkill/core.c > > > > > +++ b/net/rfkill/core.c > > > > > @@ -950,14 +950,14 @@ int __must_check rfkill_register(struct rfkill > > > > > *rfkill) > > > > > > > > > > if (!rfkill->persistent || rfkill_epo_lock_active) { > > > > > > > > > > schedule_work(&rfkill->sync_work); > > > > > > > > > > - } else { > > > > > -#ifdef CONFIG_RFKILL_INPUT > > > > > - bool soft_blocked = !!(rfkill->state & > > > > > RFKILL_BLOCK_SW); - > > > > > - if (!atomic_read(&rfkill_input_disabled)) > > > > > - __rfkill_switch_all(rfkill->type, > > > > > soft_blocked); -#endif > > > > > - } > > > > > + } //else { > > > > > +//#ifdef CONFIG_RFKILL_INPUT > > > > > +// bool soft_blocked = !!(rfkill->state & > > > > > RFKILL_BLOCK_SW); +// > > > > > +// if (!atomic_read(&rfkill_input_disabled)) > > > > > +// __rfkill_switch_all(rfkill->type, > > > > > soft_blocked); +//#endif > > > > > +// } > > > > > > > > > > rfkill_send_events(rfkill, RFKILL_OP_ADD); > > > > > > > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've > > > > tried to enable CONFIG_RFKILL_INPUT, but remove the mentioned block of > > > > code. The result is working bluetooth HW switch. > > > > > > Yes, that because the following patch introduce > > > driver with persistent state will affect the global state only if > > > rfkill-input is enabled: > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit > > > ;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19 > > > > > > It maybe workaround another rfkill-input issue, but causes it replicate > > > acer-wmi's bluetooth killswitch initial state (or any driver that used > > > rfkill_init_sw_state) to any new bluetooth killswitch. > > > > > > It's not make sense. > > > > > > > > > > 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 enab> > > > > > 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 unbloc> > > > > > > > > > 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> > > > > > > > > > > > > > > 5: hci0: Bluetooth > > > > > > > > > > > > Soft blocked: yes > > > > > > Hard blocked: no > > > > > > > > > > My Acer machine have no HW bluetooth key but only have one HW WLAN > > > > > key that emit KEY_WLAN. > > > > > Please use lshal to monitor your HW bluetooth key and make sure it > > > > > emit KEY_BLUETOOTH. > > > > > > > > `lshal -m` outputs this: > > > > > > > > <bluetooth key pressed> > > > > 20:45:53.694: platform_i8042_i8042_KBD_port_logicaldev_input condition > > > > ButtonPressed = bluetooth > > > > 20:45:54.666: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth > > > > property killswitch.state = 1 (0x1) > > > > 20:45:54.678: usb_device_a5c_2101_noserial added > > > > ... > > > > <bluetooth key pressed again> > > > > 20:46:02.435: platform_i8042_i8042_KBD_port_logicaldev_input condition > > > > ButtonPressed = brightness-up > > > > 20:46:02.668: platform_acer_wmi_rfkill_acer_bluetooth_bluetooth > > > > property killswitch.state = 0 (0x0) > > > > 20:46:02.919: usb_device_a5c_2101_noserial_if1 removed > > > > ... > > > > > > > > Strange is "brightness-up" key, somebody is wrong here. > > > > > > Yes, brightness-up key is another story, maybe you can enable acpi debug > > > to look at montior which acpi method or _Q event method used: > > > > > > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer > > > echo 0xF >/sys/module/acpi/parameters/debug_level > > > > > > But, this is not related to our current killswitch issue, let us skip > > > it. > > > > > > > > > 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. > > > > > > > > > > Still suggest you can disable CONFIG_RFKILL_INPUT then use rfkill > > > > > tool to set acer-wmi bluetooth killswitch for test, must have > > > > > different result. > > > > > > > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at > > > > Kconfig in net/rfkill and there is a line "default y if !EXPERT" which > > > > means (I think) that it would be enabled by default for anybody not > > > > troubles as I have. > > > > > > I agreed your point, and I don't think rfkill-input need enable for all > > > non-Expert user because it sometimes have conflict with EC or userland > > > behavior. > > > > > > I still suggest you can disable rfkill-input then please try Gary Lin's > > > urfkill daemon, it can do what does rfkill-input do and more > > > flexibility. > > > > > > > I've tried `rfkill unblock <acer-bluetooth number>` with my second test > > > > (enabled CONFIG_RFKILL_INPUT plus patched core.c) - it works perfectly. > > > > > > > > Anyway, it looks like using CONFIG_RFKILL_INPUT is broken to some > > > > degree, because enabling the config switch changes bluetooth HW/SW > > > > switch from working to not-fully-working. > > > > > > > > Cheers, > > > > OldÅich. > > > > > > The root cause is what I said in the above, it's hard to fix in kernel > > > module because user only can choice enable/disable rfkill-input in > > > Kconfig and even cann't choice it when system boot. > > > > > > I thought we need: > > > - set rfkill-input to EXPERT, remove !EXPERT > > > - add a kernel option to rfkill for user can choice enable it or not > > > > > > when system boot. > > > > > > - Add comment in Documentation/rfkill.txt for remind user can use > > > > > > urfkill daemon (or any other userland daemon) to replace rfkill-input. > > > > > > Of course need rfkill experts' more professional comments for this > > > topic. > > > I will try to gener> Thank's a lot! > > > Joey Lee > > > > Finally, I removed rfkill_init_sw_state and maintain a rfkill_inited > > flag to workaround issue, please kindly help to test the following > > acer-wmi patch, it works fine to me on my acer travelmate 8572 machine. > > > > Maybe it will be our backup solution after you tested: > I attached this workaround patch to bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31002#c8 > The patch works more than well - the bluetooth starts-up automatically during > boot. I don't know who does it, because it looks like the last action done > before any service gets started. > > ... > [ 4.434293] acer-wmi: Acer Laptop ACPI-WMI Extras > ... > [ 4.559937] acer-wmi: Brightness must be controlled by generic video driver > ... > [ 6.024186] usb 8-2: new full speed USB device using uhci_hcd and address 2 > [ 6.183561] usb 8-2: New USB device found, idVendor=0a5c, idProduct=2101 > ... > [ 9.763265] udev[1947]: starting version 164 > > It looks like the sync work synchronizes the state to "unblocked". I don't > have more time to investigate the difference today, so maybe in following days > - if it is important. > > Regards, > OldÅich. > That's good but odd, good is the patch fixed your issue, odd is the behavior is not what I want and not match with my TravelMate 8572. Please then me clear up it. On my TravelMate 8572, the BIOS have 2 different behavior for cold boot (shutdown then press HW power button), and warm boot (reboot). BIOS is: - Cold boot: back to default config is WLAN on, BT off, WWAN on - Warm boot: keep the devices state before last time reboot. So, you can see the above, on my machine when cold boot, the BT state is off, the rfkill list like following: linux-7y1r:~ # rfkill list 0: acer-wireless: Wireless LAN Soft blocked: no Hard blocked: no 1: acer-bluetooth: Bluetooth Soft blocked: yes # BIOS default value is disable when cold boot Hard blocked: no 2: acer-threeg: Wireless WAN Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no Then I did rfkill unblock acer-bluetooth (sorry my machine have no BT HW key): linux-7y1r:~ # rfkill unblock 1 linux-7y1r:~ # 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: no Hard blocked: no 3: phy0: Wireless4: hci0: Bluetooth Soft blocked: no #fixed by my patch, hci0's rkfill state default is unblock Hard blocked: no I am not sure your TravelMate 5730G's behavior is fully the same with mine. Could you please find a bit time to look at rfkill state when system cold boot ? Of course, please enable rfkill-input and remove any other patch but only keep my workaround patch: 0001-acer-wmi-remove-rfkill_init_sw_state-to-workaround.patch 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
