Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi OldÅich,

æ äï2011-03-11 æ 22:34 +0100ïOldÅich JedliÄka æåï
> 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.
> 

That's make sense now!

Thank's for your bug report, I am tracing and try to find out solution.
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


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux