On Fri, 27 Mar 2009, Johannes Berg wrote: > When you implement get_state but don't do force_state, how does > get_state ever get called? > > 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. > 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. So, the short answer is: rfkill_force_state(). Call it when the radio rfkill state changed, and the core will generate uevents. 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. 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). -- "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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
