[RFC] propose to develop a rfkill daemon

[Kay Sievers]

On Tue, 2010-08-31 at 11:15 +0100, Bastien Nocera wrote:
> On Thu, 2010-08-26 at 05:44 -0600, Joey Lee wrote:
> > Dear all experts, 
> > 
> > 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?

Kay