On Mon, 2009-03-30 at 10:39 -0700, Inaky Perez-Gonzalez wrote:
> On Monday 30 March 2009, Johannes Berg wrote:
> >
> > * wimax
> > -> need help, seems to report rfkill states to input device?
> > don't understand
>
> Not really.
>
> What it does is if the device exposes a hw rfkill key, export that
> key as an input device, as well as using it to report the state
> change.
>
> So there are three main entry points:
>
> wimax_report_rfkill_hw() -- device driver report to stack
>
> device reports a change in the hw rfkill key; switch the radio to
> whichever state AND report a key event through the input layer
But reporting the key through the input layer is wrong, afaict.
> wimax_report_rfkill_sw() -- device driver report to stack
>
> device reports a change in the sw rfkill state; this is needed for
> cases where the radio is shared amongst different technologies (wifi
> and wimax, for example, in the case of the 5150). When you turn on
> Wifi, WiMAX switches off (and vice versa).
>
> As well, if from SW you flip it off, this gets called back but does
> nothing as the state is updated already.
Shouldn't that be a hard block then? Or can the software turn it back on
(and consequently turn off wifi)?
> wimax_rfkill / wimax_rfkill_toggle_radio -- user interface
>
> The user wants to flip the SW switch on/off
Right.
So let's go back to my first assertion:
"seems to report rfkill states to input device"
wimax_report_rfkill_hw:
enum rfkill_state rfkill_state;
...
input_report_key(wimax_dev->rfkill_input, KEY_WIMAX,
rfkill_state);
??
I don't see why it should have an input device at all, to be honest.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
