On Fri, 2009-03-27 at 21:52 -0300, Henrique de Moraes Holschuh wrote: > > Indeed, but that's useless since almost all drivers disable userspace > > claiming... I'll re-implement it later for only the software state. > > I think we can remove the "disable userspace claiming" stuff entirely, > and retain user_claim. user_claim just means rfkill_input won't touch > a rfkill controller, there is no problem if the state changes because > the rfkill controller's driver had to do a rfkill_force_state() for > some reason. No -- the problem here is that despite the driver having hard-killed it still needs to be able to handle the soft state thingie. Which is why user_claim_unsupported was added. Yes, agree with you, but only a little -- we just need to make the rfkill core smarter. > Sure: all that matters is that you won't have two different actors > trying to implement handling for, e.g. EV_KEY KEY_BLUETOOTH, by > complementing the state of a rfkill switch. If you do, actor A > complements, then B complements, and the net effect is that no change > happened :) Indeed. But by disabling user claiming we have removed that problem entirely ;) No, like I said, I don't disagree, but the implementation sucks. I'm going to add this back in a way that drivers don't need to do special handling. > > > Anyway, I got sidetracked because I was Not Happy with the userspace ABI but > > > couldn't come up with anything better. > > > > It's not like we can change it now... > > I don't mean the rfkill core API that is already in place... I mean > the new one in the "RFC" patchset I just posted. 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. > Yes. But the exclusive grab _is_ needed for regular keyboards, > otherwise anyone can snoop on what you type. But it is not what one > would like to happen to hotkey input devices... most of the time. > It is confusing as heck. I see you've figured this out already over in another part of the thread. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
