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 Johannes, 

æ äï2011-03-21 æ 15:35 +0100ïJohannes Berg æåï
> Hi,
> 
> > > > It maybe workaround another rfkill-input issue, but causes it replicate acer-wmi's 
> > > > bluetooth killswitch initial state (or any driver that used rfkill_init_sw_state) 
> > > > to any new bluetooth killswitch.
> > > > 
> > > > It's not make sense.
> > > 
> > > I think the reason is that rfkill-input only has a global concept of
> > > per-device states. The alternative would be to force a newly registered
> > > rfkill device to the state that was set by rfkill-input.
> > 
> > Yes
> 
> I don't know if that works though. Does it make more sense? I'm not
> sure. Why bother with "persistent" then anyway? I think the logic as we
> had it was meant to make things follow the persistent state you had
> before you shut down and that was saved in the BIOS or whatever.
> 

Sorry for I didn't really capture what your mean. Please then me
introduce the issue's background:

For the beginning, I added this patch to acer-wmi driver:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=466449cfe797b8a5d82d25d0e0e08426d8dfba19

Because Acer notebook's BIOS can keep the devices state when system
reboot, so, the above patch add the logic when acer-wmi driver initial
to query the devices state by wmi method then set soft-block to
acer-wmi's killswitch, including wlan, bluetooth and wwan.

The acer-wmi used rfkill_init_sw_state to set the initial state before
rfkill register.

There have source code in rfkill_init_sw_state to set rfkill to
persistent, then rfkill/core.c replicate acer-wmi's bluetooth state to
the same type's rfkill.

        if (!rfkill->persistent || rfkill_epo_lock_active) {
                schedule_work(&rfkill->sync_work);
        } else {
#ifdef CONFIG_RFKILL_INPUT
                bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);

                if (!atomic_read(&rfkill_input_disabled))		//when rfkill-input enable
                        __rfkill_switch_all(rfkill->type, soft_blocked);	//set sw block state to the same type
#endif
        }

> > > Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
> > > event?
> > 
> > Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea
> > if there have any userland daemon to listen the keycode.
> > 
> > I am trying to remove rfkill_init_sw_state then workaround this issue
> > in .set_block by maintain a driver initial flag in acer-wmi.
> 
> No I mean ... it seems that the BIOS reports both a hotkey and an rfkill
> event. Could those be clashing?
> 

No, BIOS only emit acpi notify when user press function key, acer-wmi
driver emit KEY_WLAN to userland after receive the acpi notify. Of
course at this moment, acer-wmi driver need to maintain rfkill state to
sync with real device state.

> It seems that what happens is roughly this:
>  1) at boot, all BT is set to soft-killed due to the way the BIOS
>     started up

Yes, acer BIOS's default value is bluetooth disabled. So, when system
boot, there only have acer-wmi's bluetooth killswitch:

0: acer-wireless: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: acer-bluetooth: Bluetooth
        Soft blocked: yes		# default is sw block
        Hard blocked: no
2: acer-threeg: Wireless WAN
        Soft blocked: no
        Hard blocked: no
4: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

There have no hci0's killswtich, because BT device power off by BIOS
when system cold boot.

>  2) when you press the button, it's a toggle, so rfkill-input toggles
>     all BT rfkill instances (acer and hci0)

Per OldÅich's report, he press bluetooth hardware key then see like the
following:

4: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
6: acer-wireless: Wireless LAN
        Soft blocked: no
        Hard blocked: no
7: acer-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no
8: acer-threeg: Wirele        Hard blocked: no
9: hci0: Bluetooth
        Soft blocked: yes	# create hci0 rfkill but default is soft blocked
        Hard blocked: no

I didn't have bluetooth HW key on my Acer machine, but I can unblock acer-wmi bluetooth
rfkill manually to reproduce this issue.

>  3) now acer _also_ reports, via rfkill_set_sw_state(), that the acer BT
>     rfkill instance is not soft-blocked
> 
> Then again, even that should work fine? Clearly I don't understand the
> issue yet.
> 

If only use bluetooth HW key to control the rfkill, then it should be
fine. But, OldÅich report still have problem cann't enable bluetooth
after he press HW key because hci0's bluetooth default set to soft
blocked.

> > Does it possible we add this rfkill module option for user can control
> > disable rfkill-input when rfkill driver probed?
> > 
> > Because, distro was shipped with different company's machine, like: Acer
> > or MSI, different machines almost have different wifi/bluetooth/wwan key
> > use case.
> 
> Well, I don't think we should require a config to work "out of the box",
> so I'm not sure that makes sense.
> 

If we want to remove rfkill-input, then we need re-compiler kernel. Why
don't add a option for enable/disable it ?

> > Sometimes, we want to use rfkill-input, but sometimes we have userland
> > GUI application to provide rfkill control panel to end user. We already
> > used urfkill daemon to disable rfkill-input by ioctl way, but like this
> > issue, it was happen on driver probe.
> 
> Yeah but when urfkill starts up, it could just force the status it
> thinks things have. Since it can simply override the current status
> there doesn't seem to be a need for disabling the logic first.
> 

Yes, fully agreed your point. 
That's why I highly suggest OldÅich to use urfkill daemon to correct
this situation by userland.

> Still though I don't understand how we arrive at the issue at all.
> 

OldÅich's point is current Kconfig for rfkill-input is set to !EXPERT,
that mean any normal user will mean the above problem: hci0's rfkill
default value is soft block. It didn't enable by acer'w HW bluetooth
key.
And, like you said, there still didn't have any distro include urfkill
daemon.

> OldÅich, can you run "rfkill event" while you press the button with a
> stock kernel that shows the problem and no patches?
> 
> johannes
> 

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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux