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 Joey Lee,

On Tuesday 15 March 2011 12:11:50 Joey Lee wrote:
> Hi OldÅich,
> 
> æ äï2011-03-11 æ 14:45 -0700ïJoey Lee æåï
> 
> > Hi OldÅich,
> > 
> > > > > > > > > 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`.
> > > > > 
> > > > > `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
> 
> After trace rfkill-input stuff, I thought this is rfkill-input's normal
> behavior but not a bug.
> 
> Unfortunately, I didn't find any workaround way when a driver need to
> call rfkill_init_sw_state, e.g. acer-wmi driver.
> 
> The rfkill-input will sync the rfkill state to all killswitchs that have
> the same type. For example, acer-wmi set the initial software switch to
> _BLOCK_ when driver initial, then rfkill-input will also set any new
> bluetooth killswitch state to _BLOCK_ .

The rfkill_sync_work syncs with rfkill_global_states, which is set during 
intitialization or by rfkill_switch_all, if I read it correctly. This should 
be independent to acer-bluetooth state. The rfkill_global_states[BLUETOOTH] 
should be unblocked initially, I need to verify it.

There is some magic in rfkill/input.c that plays with global states, but I 
don't know if or how that one is used in my case.

> Acer's BIOS default setup bluetooth's state is disable when system cold
> boot, and BIOS also can save the connection devices' state when system
> reboot. Currently, acer-wmi driver have right behavior to sync the state
> with BIOS.
>
> Face to your situation, my suggestion is:
> 
> - Use userland application to correct killswitch state.
>   highly suggest You can try urfkill daemon:
> http://www.freedesktop.org/wiki/Software/urfkill or
>   write a startup script to enable bluetooth when system boot.
> 
> - Disable rfkill-input module if you didn't real use it.
>   The TravelMate 5730G have wifi hotkey that only emit KEY_WLAN, but
>   doesn't emit KEY_BLUETOOTH, that means rfkill-input cann't help you
>   enable bluetooth killswitch.

I didn't have time to look at the problem more deeply to identify who is 
setting the global state to "blocked" or what really happens. Anyway, I did 
some testing with pressing the HW bluetooth switch and I saw the following 
immediately _after_ pressing the HW switch to enable bluetooth:

oldium ~ # rfkill list
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

I had this output 3 times immediately after each other. I'm using keyboard 
"up" and "enter" to repeat the last shell command, so this is a relatively 
slow operation. So the state when the acer-bluetooth was unblocked stayed for 
relatively long time before hci0 appeared in rfkill. Afterwards I saw:

oldium ~ # rfkill list
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
5: hci0: Bluetooth
        Soft blocked: yes
        Hard blocked: no

So it looks like the hci0 went blocked even when the acer-bluetooth switch was 
unblocked. So it looks like the hci0 state is independent on the initial acer-
bluetooth state.

Hopefully I have some time this evening (CET timezone) to add some stack 
traces and logs to see what really happens on my system.

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


[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