[RFC] propose to develop a rfkill daemon

[Marcel Holtmann]

Hi Kay,

> > > I am working on implement function key features in gnome-settings-daemon
> > > to control wlan/bluetooth/wan. There have some use case need control
> > > rfkill by userland applications, some netbook use one function key to
> > > control 2 - 3 wifi devices. On windows, it's also implemented by
> > > userland application.
> > > 
> > > Before HAL removed, I enhanced gnome-settings-daemon to control rfkill
> > > by call HAL dbus function. But, there have no middleware/daemon can help
> > > applications to control rfkill state after HAL removed.
> > > 
> > > Kay kindly give me some idea, and after google this topic, found the
> > > following RedHat bug for gnome-bluetooth:
> > >  https://bugzilla.redhat.com/show_bug.cgi?id=514798
> > > and
> > >  http://www.spinics.net/lists/hotplug/msg02464.html
> > >  
> > > At last, RedHat direct add user acls for /dev/rfkill by udev rule.
> > > But, looks like a rfkill daemon still need for
> > > gnome-bluetooth(bluetoothd).
> > > 
> > > Follow Marcel's comment: the _better_ way is implement a "
> > > D-Bus enabled RFKILL daemon that integrates with PolicyKit"
> > > 
> > > I want to develop a rfkill daemon like upower and udisk, to provide
> > > D-Bus methods and integrates with PolicyKit, maybe the name is urfkill.
> > > 
> > > Does it a good idea? Appreciate any suggestions for this topic.
> > 
> > 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.

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.

Regards

Marcel