[Fwd: Re: [RFC] propose to develop a rfkill daemon]

[Gary Ching-Pang Lin]

Hi All,

2010/10/4 Joey Lee <jlee at novell.com>:
> FYI.
>
> -------- 轉遞的郵件 --------
>> 從: Dan Williams <dcbw at redhat.com>
>> 至: Joey Lee <jlee at novell.com>
>> 副本: marcel at holtmann.org, hadess at hadess.net,
>> devkit-devel at lists.freedesktop.org, harald at redhat.com, vbotka at suse.cz,
>> kay.sievers at suse.de
>> 主旨: Re: [RFC] propose to develop a rfkill daemon
>> 日期: Tue, 28 Sep 2010 10:47:20 -0500
>>
>> 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
>> >
>>
>>
>
>
I am working with Joey and implementing the rfkill daemon. I put the source code
my github repo: http://github.com/lcp/urfkill

It currently provides a few DBus method:
1. Block/Unblock: The methods to block or unblock a specific type of
killswitches.
2. GetAll: It returns the list of killswitches
3. GetKillswitch: It returns the information of a killswitch.

There are also some signals which are useful to monitor the status of
killswitches:
RfkillAdded(), RfkillChanged(), and RfkillRemoved().

I also implemented a glib binding to make it easier to use.

Since this is a prototype for evaluation, any suggestion is appreciated.

Thanks,

Gary Lin