[RFC] propose to develop a rfkill daemon

[Joey Lee]

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.

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.

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