On Mon, 2009-03-30 at 10:23 -0300, Henrique de Moraes Holschuh wrote: > On Sat, 28 Mar 2009, Johannes Berg wrote: > > Ok so you want to add "global" states mostly -- that's fine, but not all > > that useful since userspace cannot really claim globally. I also don't > > see a point -- if userspace wanted to do global stuff it might just as > > well do nothing. > > The point of doing global stuff is to do rfkill-input in userspace, the way > userspace might want to do it. > > Without the global state being exposed, userspace really can't do anything > properly, and rfkill-input is needed for any semblance of good rfkill input > event handling. Right -- but I've been wondering about those global states completely. I still need to look at input.c in more detail though. It seems that it can trivially get out of sync, if for example a global event turns _all_ radios off, but then a wlan event turns wlan back on, and then what's the state of the "all" switch? > I can't say I strongly want it, since I am happy enough with rfkill-input, > though. But the API to userspace _is_ incomplete if the global states and > global functionality are not exposed. I've kinda removed the entire userspace API part from rfkill, mostly out of laziness (so I guess I'll add it back) but also because I don't quite see the point. Has anyone come up with a usecase for it? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
