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