Discussion:
[RFC] propose to develop a rfkill daemon
(too old to reply)
Joey Lee
2010-08-26 11:44:11 UTC
Permalink
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.


Thank's a lot!
Joey Lee
Bastien Nocera
2010-08-31 10:15:19 UTC
Permalink
Post by Joey Lee
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
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.

Cheers
Marcel Holtmann
2010-08-31 20:59:54 UTC
Permalink
Hi Kay,
Post by Bastien Nocera
Post by Joey Lee
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
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.
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
Bastien Nocera
2010-08-31 22:29:21 UTC
Permalink
On Tue, 2010-08-31 at 16:59 -0400, Marcel Holtmann wrote:
<snip>
Post by Marcel Holtmann
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.
There's already the input layer for that, and we can (or should be able
to) do all the input work directly in X.
Post by Marcel Holtmann
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.
So you've already got an rfkill daemon?
Bastien Nocera
2010-08-31 22:47:52 UTC
Permalink
<snip>
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?
A D-Bus mechanism would probably be good enough, seeing as the events
already have a way to get delivered.

The only part that would be more work is figuring out if we can actually
receive the killswitch input events in X, or if we're still in the suck
for those.
Kay Sievers
2010-08-31 19:19:35 UTC
Permalink
Post by Bastien Nocera
Post by Joey Lee
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
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
Joey Lee
2010-09-01 11:19:46 UTC
Permalink
HI Bastien,

? ??2010-08-31 ? 11:15 +0100?Bastien Nocera ???
Post by Bastien Nocera
Post by Joey Lee
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.
Thank'a a lot!

I have check the gnome-bluetooth, and saw the rfkill code in
lib/bluetooth-killswitch.c
There also have similar rfkill struct and source code in connman to
access /dev/rfkill. But, connman only _listen_ the rfkill event, didn't
set the rfkill state.

I will reference those source code deferentially.
Post by Bastien Nocera
The current API, though it only really handles Bluetooth adapters, shows
what level of details we'd need on the user-space applications side.
Userland will need control all devices that have rfkill interface,
wlan/bluetooth/wwan..., the userspace need to _listen_ and _set_ the
rfkill state. Almost like what the rfkill tool's features doing.
- listen rfkill state changed
- set rfkill state for a device type, e.g. wlan/bluetooth
- set rfkill state for a device


Thank's a lot!
Joey Lee
Joey Lee
2010-09-01 17:01:07 UTC
Permalink
Hi Marcel,

? ??2010-08-31 ? 16:59 -0400?Marcel Holtmann ???
Post by Marcel Holtmann
Post by Bastien Nocera
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.
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.
Post by Marcel Holtmann
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
Dan Williams
2010-09-28 15:44:31 UTC
Permalink
Post by Joey Lee
Hi Marcel,
? ??2010-08-31 ? 16:59 -0400?Marcel Holtmann ???
Post by Marcel Holtmann
Post by Bastien Nocera
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.
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.
Post by Marcel Holtmann
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.
Post by Joey Lee
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
Post by Joey Lee
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
Loading...