rfkill-input madness

rfkill-input madness

[Johannes Berg]

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

The doc says:

        ******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?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rfkill-input madness

[Henrique de Moraes Holschuh]

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

Re: rfkill-input madness

[Johannes Berg]

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

On Fri, 2009-03-27 at 11:30 -0300, Henrique de Moraes Holschuh wrote:

> 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.

Indeed, but that's useless since almost all drivers disable userspace
claiming... I'll re-implement it later for only the software state.

> 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.

Care to explain?

> 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...

> 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).

Ok, when I get online again :)

> 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.

Indeed, but that means *X* needs to implement all this, or something
running in X, which is undesirable... Other things are sure to run afoul
of this too, for example some hal button handlers.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rfkill-input madness

[Henrique de Moraes Holschuh]

On Fri, 27 Mar 2009, Johannes Berg wrote:
> On Fri, 2009-03-27 at 11:30 -0300, Henrique de Moraes Holschuh wrote:
> > 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.
> 
> 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.

> > 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.
> 
> Care to explain?

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 :)

> > 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.

> > 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.

...

> Indeed, but that means *X* needs to implement all this, or something
> running in X, which is undesirable... Other things are sure to run
> afoul of this too, for example some hal button handlers.

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.

-- 
  "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

Re: rfkill-input madness

[Johannes Berg]

[-- 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 --]

Re: rfkill-input madness

[Henrique de Moraes Holschuh]

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.

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.

-- 
  "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

Re: rfkill-input madness

[Johannes Berg]

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

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

Re: rfkill-input madness

[Henrique de Moraes Holschuh]

On Mon, 30 Mar 2009, Johannes Berg wrote:
> 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?

Here's what is (was :-) ) in rfkill-input:

1. There are per-type global switches (and no "all" switch)
2. There is a flag, EPO (emergency power off).

rfkill-input translates any "EV_SW SW_RFKILL_ALL ACTIVE" events into "enable
EPO".  It saves the states of the switches beforehand, so that it can
optionally restore them.

When something enables the EPO, all switches go into block.  And they refuse
to go out of block until the EPO flag is cleared.   I.e. it has the proper
semanthics for a safety device.

What happens when you clear EPO isn't much.  The rfkill core doesn't care
much, all that it knows is that switches are not prohibited to go out of
block anymore once the EPO flag is clear.

rfkill-input, OTOH, can be configured to do one of three things when it gets
"EV_SW SW_RFKILL_ALL INACTIVE":

1. just clear the EPO flag (the user will have to go and manually unblock
the switches through sysfs or normal events that rfkill-input processes)

2. clear the EPO flag, and restore the global switches to the state previous
to the EPO

3. clear the EPO, and unblock all switches.


So, there is NOT an "all" switch.  But there is the handling of the
SW_RFKILL_ALL event by rfkill-input.

> > 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?

I'd talk that over with our Network Manager maintainer, he is the one who
might want it.

-- 
  "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

Re: rfkill-input madness

[Johannes Berg]

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

On Mon, 2009-03-30 at 14:21 -0300, Henrique de Moraes Holschuh wrote:

> Here's what is (was :-) ) in rfkill-input:

Heh :) I've been refactoring rfkill-input too -- but I haven't actually
changed it.

> 1. There are per-type global switches (and no "all" switch)
> 2. There is a flag, EPO (emergency power off).
> 
> rfkill-input translates any "EV_SW SW_RFKILL_ALL ACTIVE" events into "enable
> EPO".  It saves the states of the switches beforehand, so that it can
> optionally restore them.
> 
> When something enables the EPO, all switches go into block.  And they refuse
> to go out of block until the EPO flag is cleared.   I.e. it has the proper
> semantics for a safety device.
> 
> What happens when you clear EPO isn't much.  The rfkill core doesn't care
> much, all that it knows is that switches are not prohibited to go out of
> block anymore once the EPO flag is clear.
> 
> rfkill-input, OTOH, can be configured to do one of three things when it gets
> "EV_SW SW_RFKILL_ALL INACTIVE":
> 
> 1. just clear the EPO flag (the user will have to go and manually unblock
> the switches through sysfs or normal events that rfkill-input processes)
> 
> 2. clear the EPO flag, and restore the global switches to the state previous
> to the EPO
> 
> 3. clear the EPO, and unblock all switches.

Ok, that makes sense, and I think I understood this much already from
cleaning out rfkill-input.c (which killed a few dozen lines of code w/o
any functionality changes)

> So, there is NOT an "all" switch.  But there is the handling of the
> SW_RFKILL_ALL event by rfkill-input.
> 
> > > 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?
> 
> I'd talk that over with our Network Manager maintainer, he is the one who
> might want it.

As far as I understood him (he was giving an example), Dan doesn't care.
But let's ask :) (CC'ed)
Dan, would you want to have NM control rfkill from userspace, instead of
using rfkill-input?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]