Re: [PATCH v2 2/2] eeepc-laptop: Use standard interfaces

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

On Wed, 20 Aug 2008, Matthew Garrett wrote:
> On Tue, Aug 19, 2008 at 08:09:50PM -0300, Henrique de Moraes Holschuh wrote:
> > Looks fine to me at first glance.  I do wonder if there are no events at all
> > you could hook to rfkill_force_state() instead of (or in addition to) using
> > the get_state()?
> 
> The only change event is generated by hitting the wifi key, which ties 
> into rfkill-input. Won't that already force a state update on the event?

Yes, but one must keep this in mind:

1. If the event has no bearing on compulsory hardware state changes (i.e.
the hardware won't change state by itself when the event happens, it is
really just reporting a simple key press that will do nothing by itself),
you just report the key as an event.

2. If the hardware/firmware *ALSO* compulsory changes the rfkill state (i.e.
the event also means the real rfkill controller state probably changed), you
take the opportunity to do a forced immediate state poll and
rfkill_force_state() the new state.

So, it basically depends whether the EEEPC hardware/firmware does (1) or
(2).  If it is (1), the patch is correct.  If it is (2), it should do a bit
more stuff that ends up with a call to rfkill_force_state().

The reason is that there is absolutely *NO* reason why rfkill-input (or
anything else for that matter) has to obey the input event.  They can just
discard it if they want: it is a local system policy matter.  Therefore, if
there is anything in *hardware* or *firmware* that is already acting on that
event, you *MUST* arrange for a call to rfkill_force_state().

-- 
  "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