[RFC] propose to develop a rfkill daemon

[Dan Williams]

On Wed, 2010-09-01 at 11:01 -0600, Joey Lee wrote:
> Hi Marcel, 
> 
> 於 二，2010-08-31 於 16:59 -0400，Marcel Holtmann 提到：
> > > > Probably a good idea. Feel free to steal the bluetooth-killswitch.[ch]
> > > > code from gnome-bluetooth to achieve that.
> > > > 
> > > > The current API, though it only really handles Bluetooth adapters, shows
> > > > what level of details we'd need on the user-space applications side.
> > > 
> > > Just chatted a few lines with DavidZ, and thought about:
> > > 
> > > We grant read access for all users at /dev/rfkill. It might be good
> > > enough if we have something that can set stuff there with privileged
> > > operations, like pkexec, and don't need a full daemon for that?
> > 
> > I do think we need a proper daemon for this. The reason here is pretty
> > simple since it also has to listen on input events. Currently there is a
> > hack in the kernel that does this, but essentially this needs to be done
> > properly in userspace with user feedback. I just never got around doing
> > this since the input layer has no generic interface that collates the
> > different input interfaces and lets us put filters on it. I meant to
> > write some patches for it, but never got around it.
> > 
> 
> It's a good idea if rfkill daemon can also _listen_ the rfkill-input
> event from kernel/X-window, then daemon follow customerization behavior
> to control rfkill devices' state.
>  e.g.
> 	- wlan on, bluetooth on, wwan on
> 	- wlan on, bluetooth off, wwan off
> 	- wlan off, bluetooth on, wwan off
> 	...
> 	- wlan off, bluetooth off, wwan off
> 
> Currently, rfkill-input cann't handle the above complex behavior.
> 
> > And for MeeGo we have signed up ConnMan to be the central daemon to
> > handle the RFKILL settings and more importantly the flight mode
> > scenario. However that is of course more handheld and in-vehicle
> > targeted and it makes sense there.
> > 
> 
> I also work on implement the wifi hotkey control on SUSE MeeGo.
> I have check-out the latest ConnMan from git repo, ConnMan is only
> _listen_ rfkill state and have no DBus method can provide other
> applications for control rfkill state.
> 
> Please kindly correct me if I am wrong.

NetworkManager also only listens at this time.  Mainly because it's
actually kinda hard to modify rfkill state these days, what with
double-layers of rfkill (wifi card has one, platform has another that
affects wifi card).  I'd had plans to  make NM work better here but in
the end I really just wanted to punt it out to an rfkill daemon that I
could talk to via D-Bus instead of handling all the state internally in
NM.

> And, there have some rfkill interface generate by x86/laptop driver for
> power/LED control, I am not sure ConnMan how to handle those rfkill.

I tend to think that LED control is something that the distro should set
up via init scripts or some other mechanism, because it's not something
most users will touch once sane defaults are set.  It's also not
something you really need to let users tweak on a per-network basis.

Dan

> On the other hand, 
> We will not launch NM and ConnMan at the same time. There still need a
> generic rfkill daemon solution for all applications.
> 
> 
> Thank's a lot!
> Joey Lee
>