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
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
