[Add Alan, since you're discussing his patch why did you leave him out?]
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.
Is it possible that acer-wmi reports both a hotkey event _and_ an rfkill
event?
> > 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.
> - Add comment in Documentation/rfkill.txt for remind user can use
> 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?
johannes
--
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
