On Fri, 2009-03-27 at 12:08 -0300, Henrique de Moraes Holschuh wrote: > > It seems to me it'll only get called > > * when you read sysfs > > * on resume > > * on epo > > Yes. It is mostly something that the rfkill core uses to get an up-to-date > state when it knows it needs one, and it is not good for anything else. Ouch, ok. > > How do we ever react to a button press then to make a uevent? > > rfkill-related uevents exist to signal change in state of the rfkill > switches, REGARDLESS of the reason. So they are NOT related to button > presses, except in-so-far that a button press might have changed a rfkill > switch state. STOP WRITING ALL CAPS PLEASE. Look, I know that rfkill is related to the button press, if that button affects the hw kill state. > So, the short answer is: rfkill_force_state(). Call it when the radio > rfkill state changed, and the core will generate uevents. You do realise though that none of the platform drivers actually call that, right? > The core doesn't have any helpers for this, so if you need polling, for > example, you do it in your driver and call rfkill_force_state() as needed. OK -- IMHO the only reasonable thing is to actually add polling if get_state is assigned -- anything else is pointless. I also don't see how get_state is actually needed, drivers can just use force_state after suspend/resume etc. > Where does the button press enters the picture in your driver? Knowing > that, I can illustrate how it would plug to rfkill core, or to the input > device core (I am yet to see a case where it should be plugged to both). I'm not actually interested in a driver. I need to integrate rfkill into mac80211, and for that I need to rewrite it to have a usable API. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
