Hi All, 2010/10/4 Joey Lee <j...@novell.com>: > FYI. > > -------- 轉遞的郵件 -------- >> 從: Dan Williams <d...@redhat.com> >> 至: Joey Lee <j...@novell.com> >> 副本: mar...@holtmann.org, had...@hadess.net, >> devkit-devel@lists.freedesktop.org, har...@redhat.com, vbo...@suse.cz, >> kay.siev...@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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
