On Fri, 27 Mar 2009, Johannes Berg wrote: > ******IMPORTANT****** > When rfkill-input is ACTIVE, userspace is NOT TO CHANGE THE STATE OF AN RFKILL > SWITCH IN RESPONSE TO AN INPUT EVENT also handled by rfkill-input, unless it > has set to true the user_claim attribute for that particular switch. This rule > is *absolute*; do NOT violate it. > ******IMPORTANT****** > > ... > > When rfkill-input is not active, userspace must initiate a rfkill status > change by writing to the "state" attribute in order for anything to happen. > > > How the hell is userspace supposed to know whether rfkill-input is > active or not? Does anybody fucking care to implement any of this mess > in userspace? I think rephrasing that warning to: "set user_claim to 1 on any switches that you're going to mess with in response to rfkill input events" would be a LOT better. I should have written it that way. The truth is that userspace doestn't have to care about rfkill-input, unless it is trying to do what rfkill-input is supposed to (i.e. listening to input events and then trying to update switches), and if it is going to do that, it needs stuff that I never sent in for review. Anyway, I got sidetracked because I was Not Happy with the userspace ABI but couldn't come up with anything better. Better at least get those patches into the open. I just pushed a rebased version of the patches to somewhere public. It is at: git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git rfkill Please take a look and tell me what you think, and whether there is anything worth bothering with in there (FWIW, the patchset worked just fine last time I checked). As for your second question, I have been looking at the issues re. input devices and X.org evdev in the last two days, and the fact is that: it will have to be handled in userspace on most non-embedded scenarios, if things don't change in userspace soon. The problem is that X.org will exclusive-grab any input devices you let it touch, and rfkill_input will never see any events, anyway. So, right now, for the vast majority of the users, either an input device is not in use, or it is in exclusive-grab mode feeding X.org evdev. At this point, I don't have a clue on what would be the best way to go about addressing this issue, that is causing problems not only to rfkill_input, but also to anyone who would like to have hotkey handling outside of X.org in a system daemon, but still have x.org see the keys (without ugly 'event repeater' hacks). I have no idea if we should talk to the X.org people to see if we can drop that exclusive grab? Allow kernel-side input handlers to ignore exclusive grabs? Have rfkill-input be a you-want-it-in-the-kernel solution and simply don't care at all about userspace interfering with it? I was about to try to locate someone that deals with evdev to ask his ideas on the subject. -- "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
