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 æ 12:43 +0100ïJohannes Berg æåï
> [Add Alan, since you're discussing his patch why did you leave him out?]
> 

First, I am sorry for I forgot to add Alan and also a bit of late to add
Cc. you and other rfkill experts, and thank's for your response.

I will keep it in mind to remember add Cc to patch contributor in the
future.

> On Mon, 2011-03-21 at 05:26 -0600, Joey Lee wrote:
> 
> > > > -#ifdef CONFIG_RFKILL_INPUT
> > > > -               bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > > -
> > > > -               if (!atomic_read(&rfkill_input_disabled))
> > > > -                       __rfkill_switch_all(rfkill->type, soft_blocked);
> > > > -#endif
> > > > -       }
> > > > +       } //else {
> > > > +//#ifdef CONFIG_RFKILL_INPUT
> > > > +//             bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
> > > > +//
> > > > +//             if (!atomic_read(&rfkill_input_disabled))
> > > > +//                     __rfkill_switch_all(rfkill->type, soft_blocked);
> > > > +//#endif
> > > > +//     }
> > > > 
> > > >         rfkill_send_events(rfkill, RFKILL_OP_ADD);
> > > 
> > > Both work. I've tested first CONFIG_RFKILL_INPUT disabled. Second I've tried to 
> > > enable CONFIG_RFKILL_INPUT, but remove the mentioned block of code. The result 
> > > is working bluetooth HW switch.
> > > 
> > 
> > Yes, that because the following patch introduce
> > driver with persistent state will affect the global state only if rfkill-input
> > is enabled:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3fa1329eaf2a7b97124dacf5b663fd51346ac19
> 
> > 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

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

> > > Disabling CONFIG_RFKILL_INPUT works - see above. I had a look at Kconfig in 
> > > net/rfkill and there is a line "default y if !EXPERT" which means (I think) 
> > > that it would be enabled by default for anybody not enabling expert options. 
> > > So other non-expert users would have the same troubles as I have.
> > 
> > I agreed your point, and I don't think rfkill-input need enable for all
> > non-Expert user because it sometimes have conflict with EC or userland
> > behavior.
> 
> I don't think this makes sense. Until distros routinely ship an rfkill
> daemon, we absolutely need rfkill-input.
> 
> > The root cause is what I said in the above, it's hard to fix in kernel
> > module because user only can choice enable/disable rfkill-input in
> > Kconfig and even cann't choice it when system boot.
> > 
> > I thought we need:
> >  - set rfkill-input to EXPERT, remove !EXPERT
> >  - add a kernel option to rfkill for user can choice enable it or not
> > when system boot.

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

> >  - Ad> > urfkill daemon (or any other userland daemon) to replace rfkill-input.
> > 
> > Of course need rfkill experts' more professional comments for this
> > topic.
> > I will try to generate a patches to implement the above 3 things then
> > send out to rfkill experts for review.
> 
> I disagree -- let's discuss more first.
> 
> What really happens on Acer machines when the user presses a button?
> Does it generate more than one event?

Different acer machine have different behavior, but I don't know have
Acer machine emit more then one key event in function key. I know have
some MSI netbook emit more then one key event.

But, 
this bluetooth killswitch state issue is not relate to emit more then
one event.


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


[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux