Hello, I'm new to device kit and I have a very simple question to ask to the developers. I'm wondering if device-kit can have the possibility to handle wireless power management, so that applications like gnome-power-manager or network-manager would let the user save more power. Thank you for spending your time on opensource projects. Nicolò
Hi, I noticed, that all DeviceKit packages install their udev rules files into /etc/udev/rules.d Isn't that deprecated by now (yet still supported) and one should use /lib/udev/rules.d instead? Michael -- -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
On Mon, Apr 6, 2009 at 11:48, Michael Biebl <mbiebl <at> gmail.com> wrote: > I noticed, that all DeviceKit packages install their udev rules files > into /etc/udev/rules.d > > Isn't that deprecated by now (yet still supported) and one should use > /lib/udev/rules.d instead? It should, yes. All system supplied rules are not "config files", and should not end up in /etc. But the base DeviceKit daemon, that is just an event multiplexer, may go away and get replaced by udev itself. We will send an update on this the next weeks, when we do a final decision. Thanks, Kay
On Mon, 2009-04-06 at 20:48 +0200, Michael Biebl wrote: > Hi, > > I noticed, that all DeviceKit packages install their udev rules files > into /etc/udev/rules.d > > Isn't that deprecated by now (yet still supported) and one should use > /lib/udev/rules.d instead? Fixed for DeviceKit-disks here http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=01f7533db564201ce61b188d138de2b19a18d7b2 Thanks, David
Hello.
I like to make a program using DeviceKit daemon by python-dbus.
So I made a sample program to call DeviceKit method and connect
Devicekit signal.
this is sample program
import gobject
import dbus
import dbus.service
import dbus.mainloop.glib
devkit_bus = "org.freedesktop.DeviceKit"
devkit_objpath = "/org/freedesktop/DeviceKit"
devkit_iface = "org.freedesktop.DeviceKit"
def on_device_event (*args, **kwds):
print "on_device_event"
if __name__ == "__main__":
dbus.mainloop.glib.DBusGMainLoop (set_as_default=True)
bus = dbus.SystemBus ()
proxy = bus.get_object (devkit_bus, devkit_objpath)
iface = dbus.Interface (proxy, devkit_iface)
for device in iface.EnumerateBySubsystem (["usb"]):
print device
print proxy.Introspect
(Continue reading)
2009/4/6 Kay Sievers <kay.sievers <at> vrfy.org>: > > But the base DeviceKit daemon, that is just an event multiplexer, may > go away and get replaced by udev itself. We will send an update on > this the next weeks, when we do a final decision. Any updates on this? Would be nice what you guys are planning and in which direction it is heading. Would this be part of udev/udev-extras? Would udev become dependend on D-Bus? Cheers, Michael -- -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
On Mon, 2009-04-27 at 03:58 +0200, Michael Biebl wrote: > 2009/4/27 Kay Sievers <kay.sievers <at> vrfy.org>: > > On Sun, Apr 26, 2009 at 23:45, Michael Biebl <mbiebl <at> gmail.com> wrote: > > >>>> Would this be part of udev/udev-extras? Would udev become dependend on D-Bus? > >>> > >>> No. If things work out as planned, DeviceKit, the main daemon, will go > >>> away. Subsystem daemons will subscribe directly to device evens with > >>> libudev. Udev/the kernel will do the event multiplexing/filtering, > >>> there will be no D-Bus involved. It will be part of main udev, not > >>> udev-extras. When will this happen? We are planning to port DeviceKit, DeviceKit-power and DeviceKit-disk to Solaris. Maybe we have to update our plan. Regards, Jedy > > What's the idea for platforms like Solaris or FreeBSD (which don't have udev)? > > > Cheers, > Michael
On Mon, 2009-04-27 at 03:58 +0200, Michael Biebl wrote:
> What's the idea for platforms like Solaris or FreeBSD (which don't have udev)?
The (D-Bus) interface of the subsystem daemons, that is DeviceKit-disks,
DeviceKit-power, is not in any way Linux specific. We will take patches
for other operating systems.
David
On Sun, Apr 26, 2009 at 23:45, Michael Biebl <mbiebl <at> gmail.com> wrote: > Afaics, no such work has been done yet within hal, which allows to > disable the different components. Yeah, that will be done, when we consider the stuff to be ready. It will be pretty easy to that, I expect. > On the other hand, gnome-power-manager already uses DeviceKit-power. > Will future versions of e.g. gnome-power-manager or gnome-mount fall > back safely on HAL or will there be no problem if DeviceKit-power and > HAL (with power mangement enabled) are run in parallel? You can still run both at the same time. The current g-p-m will not use hal, and not fall back. You can still use the old version for that. Gnome-mount uses HAL and will not be ported to DK-disks. Nautilus/gvfs already uses DK-disks, and gnome-mount can just go away after the final switch-over. >>> Would this be part of udev/udev-extras? Would udev become dependend on D-Bus? >> >> No. If things work out as planned, DeviceKit, the main daemon, will go >> away. Subsystem daemons will subscribe directly to device evens with >> libudev. Udev/the kernel will do the event multiplexing/filtering, >> there will be no D-Bus involved. It will be part of main udev, not >> udev-extras. > > When approximately (weeks, months) do you expect this to happen?(Continue reading)
Hi Kay, thanks a lot for the informative reply 2009/4/26 Kay Sievers <kay.sievers <at> vrfy.org>: > On Sun, Apr 26, 2009 at 05:54, Michael Biebl <mbiebl <at> gmail.com> wrote: >> 2009/4/6 Kay Sievers <kay.sievers <at> vrfy.org>: >>> >>> But the base DeviceKit daemon, that is just an event multiplexer, may >>> go away and get replaced by udev itself. We will send an update on >>> this the next weeks, when we do a final decision. >> >> Any updates on this? Would be nice what you guys are planning and in >> which direction it is heading. > > Still all in an experimental state. We are not in a hurry, because > almost everything works already with the current HAL stuff, and we > don't need to break things in a rush anymore. It will still be almost > the same model, with some mistakes removed, and have different > interfaces. The transition from non-HAL to HAL was much more painful. > This will just replace HAL bit by bit, cut stuff in independent > pieces. It can run with HAL in parallel as long as needed. We will > disable pieces in HAL, when they are properly replaced by new stuff. Afaics, no such work has been done yet within hal, which allows to disable the different components. On the other hand, gnome-power-manager already uses DeviceKit-power. Will future versions of e.g. gnome-power-manager or gnome-mount fall back safely on HAL or will there be no problem if DeviceKit-power and HAL (with power mangement enabled) are run in parallel?(Continue reading)
RSS Feed3 | |
|---|---|
24 | |
19 | |
13 | |
6 | |
3 | |
3 | |
16 | |
2 | |
1 | |
18 | |
38 | |
16 | |
3 | |
13 | |
14 | |
14 | |
14 | |
14 | |
20 | |
6 | |
25 | |
19 | |
21 | |
4 | |
28 | |
11 | |
12 | |
12 | |
20 | |
52 | |
20 | |
18 | |
19 | |
29 | |
24 | |
34 | |
22 | |
13 | |
68 | |
94 | |
29 | |
64 | |
25 | |
21 | |
146 | |
70 | |
41 | |
15 | |
18 | |
15 | |
3 | |
27 | |
22 | |
2 |
