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
