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. > > > 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
