Re: rfkill-input madness

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]