Re: Awkward rfkill corner cases

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 20 Aug 2008, Matthew Garrett wrote:
> One completely unrelated question. In the following situation (relevant 
> to Dells, not the Eee)
> 
> * The system has a key (not a switch) that in firmware disables the 
> hardware (HARD_BLOCKED)

Ick.  I sure hope you can query the firmware, so that you can look at it as
if it were a switch instead of a key (and look at the key press event as a
"switch changed state" event -- never mind it is difficult to hook to that
event right now)?

I mean, trying to deal with firmware/hardware that changes states on its own
in any other basis than "it is a switch", is error prone.  You miss one
event, you go out of sync.  That's bad.

> * That key generates an event through the keyboard controller, but not 
> through any other obviously detectable means

Ok.

> * The radio control is also controllable through software (SOFT_BLOCKED)
> 
> Should pressing the key generate a KEY_WLAN event?

Frankly?  I think so.  It would be nice if you could hook the key as a "hint
that the rfkill controller may have changed state" on the driver, and ALSO
as a normal input device (so that it can command more than just that one
WLAN radio).

But I think it would be EVEN BETTER if you could somehow suppress that KEY_*
event, and synthesize an EV_SW SW_WLAN in its place (you will have to ask
Dmitry to add it, since it is a first use) instead.  If you cannot, KEY_WLAN
will have to make do.

> I note that rfkill-input will, if the device is in HARD_BLOCKED state, 
> attempt to set it to UNBLOCKED. This sounds like generating the keycode 

I have some patches in flight that will make rfkill-input smarter about it.
But that's just an enhancement.  The current way it operates is annoying,
but last time I checked, it doesn't blow up.

Just return -EPERM on your device driver's toggle_radio() callback if you
are at HARD_BLOCKED and someone asks you to go to UNBLOCKED.  That is what
the API calls for (if it is not clear enough, we can improve the docs).

> is the wrong thing to do, since it'll cause rfkill-input to try to undo 
> the change that's just been made. However, if the key isn't mapped 
> there's no obvious way for any of the stack to determine that a change 
> has been made and propagate that to userspace. What should we be doing 
> here?

Never worry about propagating rfkill state to userspace in a driver.  rfkill
will do it by itself using uevents, that code has already been accepted.
The rfkill class will do it for all rfkill controllers, and rfkill input may
be taught to do it later if userspace people ask for it (nobody did it yet
because it is not very useful, since what you want is reports of what really
IS happening to the radios, and those come from the rfkill class.  All
rfkill-input could tell userspace is what it is *trying* to change radio
states, but not whether they did really happen).

The reason why you'd want to send a KEY_WLAN event (or, if you can, an EV_SW
SW_WLAN event) is to change that key from something that controls an
specific WLAN radio, to something that can *potentially* control every WLAN
radio attached to the box.   It is *not* done to report status to userspace
[unless you meat report state to something in userspace that is doing what
rfkill-input does in the kernel, but we haven't enhanced rfkill-input and
rfkill to export all states needed for such an userspace implementation
yet].

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh