DeviceKit-power future plans

Richard Hughes hughsient at gmail.com
Mon Aug 18 04:49:15 PDT 2008


On Fri, 2008-08-15 at 12:24 -0400, David Zeuthen wrote:
> On Fri, 2008-08-15 at 11:41 +0100, Richard Hughes wrote:
> > >  - The Suspend() method on HAL takes a parameter on how long to sleep;
> > >    AFAIK no one uses this mostly because the wakeup code in Linux sucks.
> > >    The one on DeviceKit-power doesn't. Should it?
> > 
> > I'm not sure. Maybe another method SetWakeUp time might be better, as
> > then we can just return with NotSupported if the system can't do it.
> > Plus then we support wake up from hibernation and shutdown for free.
> 
> Sounds a bit racy. But it just might work. Something to think about.

Nahh, the client just does:

SetWakeUp(12:00:00T2008-06-21)
Suspend()

and if SetWakeUp comes back as NotSupported() then the client knows the
autowakeup will fail.

> > >  - The udev rules should probably use DKP_ID_BATTERY instead of
> > >    ID_BATTERY. Just to be nice and not pollute the main name space.
> > 
> > Done. Should all the properties be DPK prefixed? For instance:
> > 
> > SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c508",
> > ENV{ID_PRODUCT}="Cordless Optical TrackMan",
> > ENV{DKP_ID_BATTERY_TYPE}="mouse", ENV{ID_CSR_HAS_SMS}="1"
> 
> Where does ID_CSR_HAS_SMS come from?

I've removed this in git, we don't actually need this.

> > >    - and if do want this
> > >      - should be licensed more liberally (MIT instead of GPL)
> > >      - consistency!
> > 
> > Right, I'm pretty bad at licences. I've go no problem with MIT, just all
> > your original source files were GPLv2+
> 
> Thinking about the license some more, AFL2.1 + GPLv2+ is probably better
> since that's the license for libdbus-glib and libdbus.

IMHO: Dual licencing ickyness.

> Thinking about the name some more, it's probably wrong to call it
> libdevkit-power; it should be libdevkit-power-gobject.

Sure.

> > > I don't see why DeviceKit-power should be involved with dealing with
> > > quirks - I think we should just punt the quirks to the pm-utils project,
> > > e.g. make sure that project delivers the right quirks if the system
> > > needs it (and I think pm-utils should just use udev rules but that's up
> > > to the pm-utils maintainers). 
> > 
> > udev rules on what device?
> 
> I don't know. That's up to the pm-utils team I think.

I'll talk to Victor and see what he thinks.

Richard.




More information about the devkit-devel mailing list