æ äï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 > > 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. Thank's a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
