On Friday 11 March 2011 22:34:42 OldÅich JedliÄka wrote: > Hi Joey Lee, > > On Friday 11 March 2011 22:25:37 Joey Lee wrote: > > Hi OldÅich, > > > > æ äï2011-03-11 æ 21:54 +0100ïOldÅich JedliÄka æåï > > > > > Hi again, > > > > > > On Friday 11 March 2011 21:34:24 Joey Lee wrote: > > > > æ äï2011-03-11 æ 21:21 +0100ïOldÅich JedliÄka æåï > > > > > > > > > Hi Joey Lee, > > > > > > > > > > On Thursday 10 March 2011 23:02:27 Joey Lee wrote: > > > > > > æ åï2011-03-10 æ 19:37 +0100ïOldÅich JedliÄka æåï > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > This is about Acer WMI driver and bluetooth support. I hope I'm > > > > > > > at the right place with my question :-) > > > > > > > > > > > > > > I tried to use bluetooth again on my Acer TravelMate 5730G and > > > > > > > discovered a usability problem. I've checked 2.6.38-rc7: > > > > > > > > > > > > > > 0. On startup, the bluetooth LED is off, acer-bluetooth SW > > > > > > > rfkill is blocked. > > > > > > > > > > > > Yes, this is right behavior. > > > > > > > > > > > > Because have a acer-wmi patch in 2.6.38 to sync the connection > > > > > > devices (wlan, bluetooth, 3G) status with BIOS. > > > > > > Acer BIOS fills-in the device initial states in SMBIOS when > > > > > > system boot, then acer-wmi dirver sync this states with > > > > > > killswitch. By default, Acer BIOS set the bluetooth to off. > > > > > > > > > > > > > 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`. > > > > > > > > > > > > About 2. - 3. > > > > > > I thought the above behavior causes by rfkill-input reverse the > > > > > > hci0's killswitch when you pressed HW bluetooth, the HW bluetooth > > > > > > send out a KEY_BLUETHOOTH keycode then rfkill-input capture it to > > > > > > do hci0's status reverse. > > > > > > I suggest leave userland application to do killswitch, don't use > > > > > > rfkill-input. > > > > > > > > > > > > You can do: > > > > > > - Use rfkill unblock acer-bluetooth SW killswitch, don't use HW > > > > > > bluetooth > > > > > > > > > > > > switch. - If you still want to use HW bluetooth switch, then I > > > > > > suggest > > > > > > > > > > > > disable your rfkill-input. Have 2 way: > > > > > > + Use urfkill daemon: > > > > > http://www.freedesktop.org/wiki/Software/urfkill > > > > > > > > > > > This is a userland daemon can lock the rfkill-input to > > > > > > disable it > > > > Did you mean you direct set CONFIG_RFKILL_INPUT=N in kernel and rebuild > > kernel? or you used userland app like urfkill to send out ioctl to > > disable rfkill-input? > > > > > > > > temporarily. + Direct set CONFIG_RFKILL_INPUT=N in kernel, but > > > > > > you will need to rebuild kernel. After set rfkill-input disable, > > > > > > you need control killswitch from userland. You can control it by > > > > > > rfkill tool or also try urfkill daemon. > > > > > > > > > > Actually this doesn't work. When I unblock the SW switch by > > > > > calling `rfkill unblock <number of acer-bluetooth>`, it unblocks > > > > > the SW killswitch, the bluetooth LED goes up, the hci0 shows-up > > > > > (USB device and killswitch), but initial state of hci0's > > > > > killswitch is "blocked". So I still need to unblock it manually. I > > > > > would preffer to don't be forced to do step 2, also for the HW > > > > > switch (which should do the same job I think). > > > > > > > > > > Cheers, > > > > > OldÅich. > > > > > > > > That's weird! > > > > Because acer-wmi driver only maintain the killswitch on by itself and > > > > will not touch hci driver's killswitch. I don't know why hci's > > > > killswitch initial state is 0, need to check hci driver and rfkill > > > > staff. > > > > > > > > Could you please share your bluetooth device to us? > > > > Please send out "lsusb" result when bluetooth device available. > > > > > > Bus 008 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller > > > > > > dmesg shows the following: > > > > > > [ 2422.322067] usb 8-2: new full speed USB device using uhci_hcd and > > > address 3 [ 2422.528212] usb 8-2: New USB device found, idVendor=0a5c, > > > idProduct=2101 [ 2422.528223] usb 8-2: New USB device strings: Mfr=1, > > > Product=2, SerialNumber=0 > > > [ 2422.528231] usb 8-2: Product: Acer Module > > > [ 2422.528238] usb 8-2: Manufacturer: Broadcom Corp > > > > > > `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. > > > I just simply check the rfkill stuff, > > I found when CONFIG_RFKILL_INPUT set to enable and there have any driver > > call rfkill_init_sw_state before register rfkill object, then rfkill > > will sync this state to all killswitch that have the same type and also > > will set the same initial state to new killswitch have the same type. > > > > Looks like rfkill will sync the state for the same type killswitch if > > used rfkill_init_sw_state, I will do more detail debug and trace for > > rfkill stuff, then find out solution. I've added dump_trace() into hci_rfkill_set_block and the result is this: [ 85.180724] hci_rfkill_set_block: f36bb800 name hci0 blocked 1 [ 85.180734] Pid: 8, comm: kworker/1:0 Not tainted 2.6.38-drm+ #106 [ 85.180740] Call Trace: [ 85.180758] [<c080ae7b>] ? hci_rfkill_set_block+0x3b/0x60 [ 85.180769] [<c08a9b58>] ? rfkill_set_block+0x68/0xe0 [ 85.180778] [<c08a9e36>] ? rfkill_sync_work+0x26/0x40 [ 85.180791] [<c027e851>] ? process_one_work+0x121/0x370 [ 85.180802] [<c0263a0b>] ? get_parent_ip+0xb/0x40 [ 85.180810] [<c08a9e10>] ? rfkill_sync_work+0x0/0x40 [ 85.180820] [<c027ee3c>] ? worker_thread+0x11c/0x3b0 [ 85.180831] [<c027ed20>] ? worker_thread+0x0/0x3b0 [ 85.180840] [<c0282144>] ? kthread+0x74/0x80 [ 85.180849] [<c02820d0>] ? kthread+0x0/0x80 [ 85.180859] [<c022f1f6>] ? kernel_thread_helper+0x6/0x10 It goes from rfkill_sync_work. That is all I can do now, I guess you will be faster than me in finding the solution :-) 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 -- 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
