On Sun, 2009-06-07 at 18:16 +0100, Alan Jenkins wrote:
> Hmm, this looks more like a core feature than an rfkill-input bug:
>
> "
> v4: set default global state from userspace for rfkill hotplug
> (pointed out by Marcel)
>
> ...
>
> + if (ev.op == RFKILL_OP_CHANGE_ALL) {
> + if (ev.type == RFKILL_TYPE_ALL) {
> + enum rfkill_type i;
> + for (i = 0; i < NUM_RFKILL_TYPES; i++)
> + rfkill_global_states[i].cur = ev.soft;
> + } else {
> + rfkill_global_states[ev.type].cur = ev.soft;
> + }
> + }
>
>
> It still looks like this global state will apply even if rfkill-input is
> disabled and userspace has not requested OP_CHANGE_ALL; the default
> state will be enforced on hotplug. If you want to keep this, I think we
> still need my full scheme.
Your text and code quoting are in disconnect -- you're quoting code from
the /dev/rfkill handler. That confuses me. But anyway, yes, we should
probably simply not enforce the global state _iff_ the device set its
own state before registration.
> Eek! On a related note, what are we doing on resume? Johannes added it
> in a response to one of my annoying eeepc-laptop scenarios, but I didn't
> look at the code, only the results. It seems the individual devices are
> forced into the _global_ states (indexed by device type) on resume. I
> thought you were trying to neuter these global states so userspace had
> full discretion? Shouldn't we just restore the individual device state?
Yes, that seems like a bug.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
