As requested by davidz, forwarding on the blog post at:
http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/
DeviceKit-power latency control
We all know controlling latency is the best way to control power
consumption and still have a usable system. Putting the processor int
On Thu, 2008-11-06 at 12:26 -0500, David Zeuthen wrote:
> On Thu, 2008-11-06 at 16:47 +0000, Richard Hughes wrote:
> > I’ve put an interface file up here:
> > http://people.freedesktop.org/~hughsient/DeviceKit-power/gtk-doc/Latency.html
>
> Some comments
>
> 1. Regard
On Tue, 2008-11-11 at 16:17 +0100, Phil Knirsch wrote:
> Richard Hughes wrote:
> > On Tue, 2008-11-11 at 14:53 +0100, Phil Knirsch wrote:
> >> Using monitoring information e.g. from collectd or other sources this
> >> could automatically be detected though a
On Tue, 2008-11-11 at 08:54 -0500, David Zeuthen wrote:
> Can you upload the new interface when we've got the changes
> in? Since it's public API and all, another round of review might be
> good.
New interface uploaded here:
http://people.freedesktop.org/~hughsient/DeviceKit-power/gtk-doc/Latency.
On Tue, 2008-11-11 at 08:54 -0500, David Zeuthen wrote:
> On Tue, 2008-11-11 at 12:08 +0000, Richard Hughes wrote:
> > > Why wouldn't the admin just use the same method? I'm not sure why we
> > > need two separate methods. I mean, with a CancelLatencyRequest() and
On Tue, 2008-11-11 at 14:53 +0100, Phil Knirsch wrote:
> Using monitoring information e.g. from collectd or other sources this
> could automatically be detected though and then the system could be
> automatically transitioned into a related power saving states depending
> on the load.
What's do
On Mon, 2008-11-10 at 12:26 -0500, David Zeuthen wrote:
> If a cookie is what we want (and I think we do), we shouldn't implement
> it this way. Second, everything in a process share the D-Bus connection
> so this wouldn't be a very good cookie anyway.
Agreed, I've changed the interface.
> The po
On Tue, 2008-11-11 at 18:41 +0100, Phil Knirsch wrote:
> Yep, absolutely agree. But even there wouldn't it be nice if e.g. during
> the day that server would have a 10us latency for CPU and during the
> night automatically transition to higher and higher latencies, up to
> even 100ms or so? Or a
On Tue, 2008-11-11 at 18:46 +0100, Harald Hoyer wrote:
> How about a totally dynamic latency, which grows as soon as network
> traffic per hour decreases and the other way round.
I'm not sure. I just know we have to build the framework so that other
much clever people than me can build policy that
This morning I released 002. This doesn't have any of the PMQoS or
latency stuff in yet, we're still finalising the interface.
Version 002
~~~
Released: 2008-11-13
New Features:
- add in CanSuspend and CanHibernate into API (Richard Hughes)
- add two new properties, has-histo
Version 003
~~~
Released: 2008-12-09
New Features:
- Implement the .QoS interface -- still proof of concept (Richard Hughes)
Bugfixes:
- Enable the low power saving code in DkpHistory (Richard Hughes)
- Don't keep putting off the profile saving in DkpHistory (Richard Hughes)
-
Jon wants to automatically download drivers for his soundcard. The way I
envisage this happening is:
1. UDEV rule merges in PK_NEEDED_PACKAGE='alsa-firmware'
2. gnome-packagekit/kpackagekit watches DeviceKit for this key to appear
3. session triggers install if it's not already installed
Now, the
I've recently converted gnome-power-manager to DeviceKit-power. The
amount of code I've deleted is simply staggering, and apart from a few
typos it seems to have gone down quietly with users.
One feature I've yet to convert is cell phones, where the data is
presented from gnome-phone-manager (sess
On Fri, 2008-12-19 at 17:32 +, Bastien Nocera wrote:
> > I'm not sure we want to let sessions inject data into DeviceKit-power;
> > seems very complicated for handling the rather edge cases like this.
> >
> > Why can't gnome-power-manager (or whatever component that is drawing the
> > UI) simp
On Fri, 2008-12-19 at 21:54 +, Bastien Nocera wrote:
> But when things like gnome-power-manager, or gphoto2 are exporting
> battery information, the connections are per-user. Eg. only one user
> will get access to the camera when using gphoto2.
Cool. I've re-plumbed in the gnome-phone-manager
Version 004
~~~
Released: 2009-01-23
Bugfixes:
- Fix the battery capacity calculation. Fixes fd#19165 (Richard Hughes)
- Special case machines where the kernel does not convert charge to power
(Richard Hughes)
- Check all the power supply fields for valid data (Richard Hughes
Version 005
~~~
Released: 2009-02-02
New Features:
- Add a wakeups interface so we can get data from the system over DBus
(Richard Hughes)
- Allow showing the wakeup data in the devkit-power command line tool (Richard
Hughes)
Richard
On Thu, 2009-02-05 at 20:51 -0500, David Zeuthen wrote:
> On Thu, 2009-02-05 at 20:37 -0500, David Zeuthen wrote:
> > On Mon, 2009-02-02 at 15:35 +, Richard Hughes wrote:
> > > Version 005
> > > ~~~
> > > Released: 2009-02-02
> > >
> &g
On Fri, 2009-02-06 at 17:24 -0500, David Zeuthen wrote:
> So unless there are really good reasons (for example if
> privileges are required) for exposing this functionality via IPC I
> think we may want to remove it and make the users (e.g. g-p-m) use the
> native kernel interfaces instead.
Two re
Version 006
~~~
Released: 2009-02-10
Bugfixes:
- Fix compile failure with gcc-4.4.0 and old versions of glib2 (Richard Hughes)
- Only enable the wakeups polling if a client requires the data (Richard
Hughes)
- Correctly set the power-supply property (David Zeuthen)
- Don't crash
Last nights automated build failed:
devkit_disks_daemon-devkit-disks-daemon.o: In function
`devkit_disks_daemon_local_update_poller':
/home/hughsie/Code/DeviceKit-disks/src/devkit-disks-daemon.c:1202: undefined
reference to `poller_set_devices'
devkit_disks_daemon-devkit-disks-daemon.o: In funct
At the moment DeviceKit-power has the "wire" type of string for state.
Internally, this is represented by:
typedef enum {
DKP_DEVICE_STATE_CHARGING,
DKP_DEVICE_STATE_DISCHARGING,
DKP_DEVICE_STATE_EMPTY,
DKP_DEVICE_STATE_FULLY_CHARGED,
DKP_DEVICE_STATE_UNKNOW
On Fri, 2009-02-27 at 08:29 -0500, David Zeuthen wrote:
> > As long as I document the enum values, this is okay, right?
>
> Please hold off with this until we port DeviceKit-power to EggDBus/GBus
> (or whatever it will end up being called).
Right, but using EggDBus the enums would be uint types,
On Mon, 2009-03-02 at 16:33 +0100, Michael Biebl wrote:
> looks like configure.ac is bit out of sync:
>
> AC_INIT(DeviceKit-power, 003,
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel)
> AM_INIT_AUTOMAKE(DeviceKit-power, 007)
> (note the 003 vs 007)
Good catch.
> I suggest, setting
On Fri, 2009-02-27 at 11:03 -0500, David Zeuthen wrote:
> On Fri, 2009-02-27 at 15:25 +0000, Richard Hughes wrote:
> > Right, but using EggDBus the enums would be uint types,
> We'd probably want to change something else but that's fine, we've never
> promised Devic
On Mon, 2009-03-02 at 10:56 -0500, David Zeuthen wrote:
> On Mon, 2009-03-02 at 15:49 +0000, Richard Hughes wrote:
> > On Fri, 2009-02-27 at 11:03 -0500, David Zeuthen wrote:
> > > On Fri, 2009-02-27 at 15:25 +0000, Richard Hughes wrote:
> > > > Right, but using E
On Mon, 2009-03-02 at 11:35 -0500, David Zeuthen wrote:
> The main concern is that the presence of the signals leads you to
> believe you can just connect to connect to the bus and then they get
> delivered to you with some sane frequency.
Well, you can. The kernel only updates this data every n
On Mon, 2009-03-02 at 17:05 -0500, David Zeuthen wrote:
> NOTE NOTE NOTE: This is an unstable release of DeviceKit-disks, all
> API is subject to change.
Are you planning on shipping DeviceKit _and_ udev-extras in F11, or will
the latter obsolete the former?
Richard.
___
On Tue, 2009-03-03 at 17:06 -0500, David Zeuthen wrote:
> On Tue, 2009-03-03 at 09:38 +0000, Richard Hughes wrote:
> > Are you planning on shipping DeviceKit _and_ udev-extras in F11, or will
> > the latter obsolete the former?
>
> I think DeviceKit and what we're putti
In DeviceKit-power 007 I'm intending to ship a temporary
devkit-power-gobject library that will be used in xfce-power-manager and
gnome-power-manager.
At the moment we have four local versions of libdevkit-power in
different projects, and all four versions are different.
To use the library you ha
the GObject property system
(Richard Hughes)
- Move the library directory from libdevkit-power to devkit-power-gobject
(Richard Hughes)
- Ship a shared library. There are now three external projects using copies of
this, which is ridiculous (Richard Hughes)
- Require
On Sun, 2009-04-26 at 16:22 +0200, Kay Sievers wrote:
> DeviceKit-power will use libudev, and take over the all the
> power/battery/UPS handling from HAL. At this point, the part of HAL
> will be disabled.
Sure agree. Good email. One question:
Switches (killswitch, lid, tablet, headphone) are not
On Mon, 2009-04-27 at 09:50 +0200, Ali Abdallah wrote:
> It is a very good idea to have it in devkit power, i see no
> applications require lid events other than power managers.
There's a lid-is-closed property exposed in git master.
Richard.
___
devk
On Tue, 2009-05-05 at 22:24 +0200, Martin Pitt wrote:
> Does that also have a solution for the power button? (The other ACPI
> even that g-p-m listens to through hal)
The kernel pushes that up through INPUT now.
Richard.
___
devkit-devel mailing list
On Thu, Jun 11, 2009 at 8:13 PM, Michael
Terry wrote:
> With HAL, there was a SetPowerSave dbus command to (basically) run
> pm-powersave. There doesn't *seem* to be a similar command for
> DeviceKit-power.
I think that's by design, in that we should always be running in
"powersave" mode, not jus
On Thu, Jun 18, 2009 at 7:32 AM, John Thacker wrote:
> Has anyone had any luck getting a USB UPS to work with recent
> DeviceKit-power?
My UPS is still sitting in a box[1] after moving house, so I've been
unable to test DK-p with UPS's for some time. I would be most grateful
if someone could jum
On Fri, Jun 26, 2009 at 1:50 PM, Michael
Terry wrote:
> The decision about powersave-mode and such needn't be made a priori by
> dk-p, but could be made by the distribution in whether to ship the
> powersave-mode power.d script as part of pm-utils. The power.d
> mechanism doesn't strike me as inhe
On Sat, Jun 27, 2009 at 9:18 PM, Roland Dreier wrote:
> If the local variable error in dkp_daemon_set_pmutils_powersave() isn't
> initialized, it's likely to hold some random non-NULL value from the
> stack and glib functions won't overwrite it to return on error. So if
> g_spawn_command_line_asyn
On Sat, Jun 27, 2009 at 9:18 PM, Roland Dreier wrote:
> command is allocated with g_strdup_printf() so it needs to be freed with
> g_free() when we're done with it.
Committed, thanks. Maybe I should code when less sleepy next time :-)
Richard.
___
devki
On Sat, Jun 27, 2009 at 6:28 PM, Martin Pitt wrote:
> sorry for sending this by mail, I'm currently in a train and offline.
np.
> I noticed that your recent pm-powersave patch works fine when dk-p is
> running in a foreground console, but it fails when being spawned
> through D-Bus, since it does
On Sun, Jun 28, 2009 at 12:39 PM, Martin Pitt wrote:
> I don't particularly like it either, TBH, but it seemed less evil to
> me than hardcoding /usr/sbin. If you prefer the latter, I'm fine with
> that, I just thought that we shouldn't break /usr/local.
I've hardcoded them, like I did with the ot
I'm trying to fix UPS support in DeviceKit-power. It's basically all
down to incorrect udev rules. The device I'm trying to match is the
last one in the chain, i.e. the one with DEVNAME=/dev/usb/hiddev0 :
P: /devices/pci:00/:00:1a.7/usb1/1-4/1-4.1
N: bus/usb/001/007
S: char/189:6
E: DEVPAT
2009/7/2 Martin Pitt :
> ACTION!="add", GOTO="ups_end" # drop this if you need change events, too
> SUBSYSTEM!="usb", GOTO="ups_end"
> KERNEL!="hiddev*", GOTO="ups_end"
>
> ATTRS{idVendor}=="0463", ATTRS{idProduct}=="", [... your action here ... ]
> [... similar idVendor/idProduct rules ...]
>
As we all know, the hal-ectimisation continues. At the moment,
gnome-power-manager still uses HAL for two things:
* Ambient light sensors
* Setting the backlight on hardware without xrandr BRIGHTNESS support,
or where xrandr falls over
Now, I've held off adding support for backlight devices to
De
2009/7/2 Kay Sievers :
> No, better don't stuff things into the dmi device, not all platforms have
> that.
Then where in the database should this data go?
> This? http://cgit.freedesktop.org/~david/xdg-hostname/
That's the hostname, not the formfactor... Confused.
Richard.
___
One of the nice things about DMI data is that it gives you the form
factor of the device, so you can choose sensible defaults for laptops,
servers and handhelds. This data is exported in HAL, but not
DeviceKit-*
What about something like this:
SUBSYSTEM!="dmi", GOTO="dkp_formfactor_end"
ATTR{cha
2009/7/2 Kay Sievers :
> Yeah, it's a bit dangerous.
Yes, I think virtual devices are a quick way back to the HAL mess.
That's why I wanted to merge the data back to where it came from, so
to speak. All it's doing is providing a mapping for one key value to
another, with a DKP_ prefix.
> Yeah, ma
2009/7/2 David Zeuthen :
> Or maybe it turns out that we don't want something like this at all - I
> mean, you can't really trust DMI data in the first place so it's rather
> optimistic what Richard is trying to do. E.g. we don't want to give out
> potentially wrong data.
Then we add quirks for th
2009/7/2 Kay Sievers :
> Exactly, there is absolutely no way to tell what is a "server". Maybe
> the "laptop" classification kind of works (can use better indications
> for this), but there is no such thing as a "server" and "desktop" you
> can ever retrieve reliably from dmi data.
So DMI data is
2009/7/2 Bill Nottingham :
> laptop vs. is a form factor decision.
> Desktop vs. server is a use case decision.
True...
> While you can generally assume a 3U rack box or a blade is a server
> of some sort, it's much less clear for the 'desktop' form factors -
> they can just as easily be a 'serv
2009/7/2 David Zeuthen :
> Richard, I know you are just trying to push the envelope here and make
> things work out of the box - however, your assumption that a "form
> factor" value is available and trustworthy is just fundamentally flawed.
Okay, no worries, I'll agree that trying to be clever wi
2009/7/2 David Zeuthen :
> No, it is not a goal for policy agents like gnome-power-manager to be
> desktop neutral - in fact, it's an anti-goal.
Right, it's called GNOME Power Manager because it depends on all the
GNOME stack.
Richard.
___
devkit-devel
2009/7/2 Martin Pitt :
> On a related note, I had always wished g-p-m (and GNOME in general)
> had a separate mode/policy for "laptop is docked", i. e. this exists:
What would it do differently to the on AC case?
Richard.
___
devkit-devel mailing list
d
2009/7/3 David Zeuthen :
> It's completely wrong to do this as this, for example, will break
> multi-monitor setups. You should know very well that it's outside the
> scope of DeviceKit-power to do this - instead, I believe, you want to
> fix X or whatever display server you are using.
Right, and
2009/7/3 David Zeuthen :
> So you really need to revert that patch and stop trying to pretend to
> solve the worlds problems by violating the layering the rest of us are
> actually trying to make work. If you want to fix backlight, go hack on X
> or Wayland. Don't invent your own public interfaces
2009/7/3 David Zeuthen :
> On Fri, 2009-07-03 at 16:08 +0100, Richard Hughes wrote:
>> I'm not going to revert the patch,
>
> Then I will revert it if you don't. Seriously, Richard, we are _not_
> going to go down the wrong path here. I don't know why that point is
2009/7/3 Ali Abdallah :
> I have a suggestion, since backlight class exists in the kernel and it
> *works*, then best
> to have separate addon service from dkp just for doing these stuff, this
> will keep *users* happy,
> then dropping this service will be something easy without touching the dkp.
2009/7/3 Richard Hughes :
> How's that for a compromise?
Ohh, forgot to add, I've reverted the stuff from DeviceKit-power and
g-p-m as I wanted to make a release on Monday, and don't want to
release code in one release that we remove/move in the very next.
I also did
2009/7/6 Zhu, Peter J :
> I still see devkit-power make much call to devkit-gobject rather than using
> libudev. Any plan to remove that to embrace libudev?
Already done in the gudev branch. The reason that it's not yet been
pushed to master is I need to do a DeviceKit-power update for F11, and
t
At the moment DK-p has the following status values:
DKP_DEVICE_STATE_UNKNOWN,
DKP_DEVICE_STATE_CHARGING,
DKP_DEVICE_STATE_DISCHARGING,
DKP_DEVICE_STATE_EMPTY,
DKP_DEVICE_STATE_FULLY_CHARGED,
This limits us with multi-battery setups, where batteries can
disc
2009/7/6 Kay Sievers :
> Is FULL and EMPTY really a state of the device like CHARGING
> DISCHARGING? Wouldn't it be two different things what's currently
> "done with it" and what's "in there"?
Yes, as batteries can be fully charged at 85% or empty at 12%.
> What's done with it:
> CHARGING (not
2009/7/6 Kay Sievers :
> They would be gray, but showing the current charge level?
Yes, something like that.
Richard.
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
laptop batteries
are officially supported.
New Features:
- Interface with pm-powersave as external vendors are using this
(Richard Hughes)
- Enable pretty compiler output with new automake versions (Richard Hughes)
- udev rules files now live in /lib/udev/rules.d, not
/etc/udev/rules.d
Version 010
~~~
Released: 2009-07-22
Note:
- The DBus interface of DeviceKit-power may be subject to change in future
versions of this daemon.
- This project now depends on GUdev and PolicyKit1
New Features:
- Port to GUdev (Richard Hughes)
- Port to PolicyKit1 (Richard Hughes
2009/7/24 Arnaud Quette :
> you'll find attached a small patch for DeviceKit-power that update, complete
> and sanitize the USB/HID UPS rules file.
Ohh, could you prepare a patch against git master please.
> note that I can automatically generate this file in the NUT tree, so that
> you can easil
2009/7/27 Arnaud Quette :
> I'll soon get back with some features and improvements propositions.
Cool. I've merged your patch with a few tiny fixes (dropping the 0x in
the vendor matches), thanks.
Richard.
___
devkit-devel mailing list
devkit-devel@list
2009/7/24 Krzysztof Kotlenga :
> Just a notice - README needs an update to reflect current dependencies.
> Thanks and keep up good work! :-)
commit db729c1793e25dfc014cef3258c259c56a42d65a
Author: Richard Hughes
Date: Tue Jul 28 13:46:29 2009 +0100
Update README to reflect reality
I've pushed an experimental branch "not-just-gudev" which allows
non-linux platforms to plug code into DeviceKit-power. It's not
tested, but I would appreciate if non-linux people could check it out
and tell me what you think. Thanks.
Richard.
___
devkit
2009/7/29 Arnaud Quette :
> I take this opportunity to recall that the UPS support code in DK-p is Linux
> only, since it relies on the hiddev Linux driver.
Yup.
> Richard: do you have any plan in this area, and possibly according to the
> proposition I once made (using NUT as a bridge...)? I've
2009/7/30 Arnaud Quette :
> another minor update with a new entry, and an interesting typo fix ;-)
Ha! :-)
Patch applied, thanks.
Richard.
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/de
2009/9/4 David Zeuthen :
> Either way, as I said earlier I don't mind changing the property names
> even if they are still (technically) valid (albeit unconventional).
FWIW, I've just changed about 6 or 7 properties in PackageKit to use
WindowsStyleCaps from the old-property-format. I must admit I
2009/9/9 Jedy Wang :
> I wonder why reboot/shutdown is not supported in devicekit-power.
> According to my understanding, they are related to power management. Is
> this because they are already implemented in ConsoleKit?
Yes, gnome-power-manager uses ConsoleKit to do these operations.
Richard.
_
On 18/09/2009, David Zeuthen wrote:
> Yeah, the dbus-glib code generator automatically translates to GObject
> style property names (e.g. IdUsage -> id-usage) so the hunks against the
> daemon source code are not needed. I've committed the rest here
I've done DeviceKit-power in 1587fc5758f008f990
On 22/09/2009, Davide Bettio wrote:
> Can you update devicekit-disks and devicekit-power documentation?
TBH, I'm not sure where we should be uploading this to. I've been
using http://people.freedesktop.org/~hughsient/DeviceKit-power/ but
this doesn't seem right. I see David uses
http://hal.freede
If you want any patches / fixes included for the release then you've
got a few days left for review. Testing especially welcome.
If you're expecting DeviceKit-power to work on Solaris or FreeBSD in
future releases, there's a framework in place just waiting to be used.
Hint hint.
Richard.
2009/10/6 Davide Bettio :
>> Eg. libdevkit-power-gobject 010 and DeviceKit-power 011 will not work
>> together (in case someone does a partial package upgrade).
>
> You must use the same version for both.
Yes, I think it's pretty insane packaging policy if you're shipping
half of one package as a
hacks.
New Features:
- Return meaningful errors if the user tries to suspend or hibernate without
kernel support or swap set up (Richard Hughes)
- Use the sysfs file 'type' to work out the battery type before using a
fallback (Enrico Zini, Richard Hughes)
Bugfixes:
- Update l
2009/10/7 Davide Bettio :
> DeviceKit-Power documentation seems to be missing.
> Can you publish it?
Ahh, it got deleted after the freedesktop home 'purge'. I've
re-uploaded it here:
http://people.freedesktop.org/~hughsient/DeviceKit-power/
Thanks.
___
ld you
try with the latest git and tell me if this also fixes the problem
please. Thanks.
Richard.
From b69e31ef05a18be74c4ff69ed3a6ce79a0550bc2 Mon Sep 17 00:00:00 2001
From: Richard Hughes
Date: Wed, 14 Oct 2009 10:34:10 +0100
Subject: [PATCH] Ensure we only reset the update-time property when we have done the
2009/10/14 Pramod Dematagoda :
> I updated to the latest git and tried without my work around Richard,
> but the bug shows up again and it disappears once I apply my patch, so
> it would seem that the daemon still does not get notified properly after
> the delayed refresh.
Could you include a daem
2009/10/16 Pramod Dematagoda :
> The unpatched log is what is obtained using the current DKP git, the
> patched one is with my workaround.
Cool, thanks. Can you try git master now, as it seems to work for me
in all cases now.
Thanks.
Richard.
___
devki
Version 012
~~~
Released: 2009-10-19
Note:
- The DBus interface of DeviceKit-power may be subject to change in future
versions of this daemon.
New Features:
- Detect encrypted swap and prevent hibernate in this case. Fixes
fd#23196 (Richard Hughes)
- Add g_object_notify() calls for
2009/11/2 Daniel Troeder :
> $ dbus-send --system --dest=org.freedesktop.DeviceKit.Power
> --type=method_call --print-reply=yes /org/freedesktop/DeviceKit/Power
> org.freedesktop.DeviceKit.Power.Hibernate
> Error org.freedesktop.DeviceKit.Power.GeneralError: Swap space is encrypted
Better logic
2009/11/13 Matthew Garrett :
> useful on nvidia. These are very much a legacy holdover, and at this
> point I'd recommend dropping support for them entirely. The market share
> of everyone else put together is miniscule, and if they're not
> interested in supporting Linux properly then we shouldn't
2009/11/6 Emilio López :
> Running "devkit-power -d", it reveals it's not
> gnome-power-manager's fault, as devkit doesn't detect the battery and says
> it's running on AC power. I'm using devkit-power 011 on Ubuntu Karmic Koala,
> and my PC is an Acer Aspire 6930.
Do you have any battery devices
2009/11/17 Emilio López :
> emi...@laptop:~$ ls /sys/class/power_supply
> ACAD
There's the problem.
> emi...@laptop:~$ cat /proc/acpi/battery/BAT1/state
> present: yes
> capacity state: ok
> charging state: discharging
> present rate: 2056 mA
> remaini
2009/12/1 David Zeuthen :
> I believe Richard has similar plans for DeviceKit-power.
Indeed I do. I'm going to push out one more release of DeviceKit-power
next Monday (for the distros) and then pull the rename branch into git
master.
Richard.
___
devki
2009/12/2 Arnaud Quette :
> any idea on the new DK-power name (probably 'upower' for the coherence
> of the whole)?
upower for sure.
Richard.
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/
2009/12/1 Victor Lowther :
> It works for me, but none of the system I own end up actually querying
> the quirk database. :)
If it helps, I'm in a 100% KMS world right now too.
Richard.
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
ht
2009/12/2 Victor Lowther :
> What needs to be done to teach devicekit-power and gnome-power-manager
> about hybrid suspend? I am going to have a hybrid suspend mode as an
> option in pm-utils that does not rely on userspace suspend or tuxonice,
> but I am not offered hybrid suspend as an option in
2009/12/2 Tobias Arrskog :
> I guess this is obvious but might aswell ask, will the name change be
> reflected in the dbus names aswell?
Yes, the interface name, the library name, the binary name, the whole shebang.
Because of this, distros may want to keep shipping DK-p in stable
releases and ju
2009/12/2 Martin Pitt :
> Personally I find this more appealing. To me, hybrid mode seems
> conceptually closer to suspend than to hibernate, just with a safety
> net (and of course a much longer suspend time).
What does Windows 7 and OSX do? Do they put a safe suspend in the
menus? Do they have t
2009/12/3 Kay Sievers :
> As far as I know, Mac OS has hybrid only, no separate hibernate. Vista
> has hybrid by default, but (custom) hibernate can be triggered from
> the interface. Both do not have the simple (unsafe) suspend.
Sure, so both have two UI elements, not three. I still think we shou
2009/12/6 Ross Burton :
> That's a nice theory and all, but are devicekit-disks or -power actually
> compilable on non-Linux? (that's a rhetorical question by the way)
Sure, DK-p has the linux stuff separated out. I've compiled it for
freebsd recently.
Richard
___
-power --monitor, print a timestamp before each message for
debugging. Fixes fd#24666 (Richard Hughes)
Bugfixes:
- Update the list of HID UPS (Arnaud Quette)
- Use a gdouble for percentage to fix on-battery reporting (Byron Clark)
- Bug 24262 – incorrect battery recall warning for Lenovo T61
2009/12/8 Jedy Wang :
> 1) When will the renaming happen, in one week, one month, before
> gnome-2-30's release or after?
I'm not sure. I'm tempted to push the upower code into a new git repo,
for clarity.
> 2) What level of ABI stability will upower/udisks provide?
For me personally, I think th
2009/12/8 Dario Freddi :
> But I think a better idea would be having the signal being streamed from
> upower (since if the aim is providing an unique and future-proof system),
> triggered from an hook in pm-utils. I think such a solution would be the best
> of both worlds.
You have to be careful w
2009/12/8 Dario Freddi :
> The Awakening signal instead would be more useful and less dangerous. Let's
> say that, in the end, the best solution for everyone could possibly be just
> adding the Awakening signal.
Fine for me. If somebody has a few minutes, I would love a patch to
upower that adds a
2009/12/8 Tobias Arrskog :
> I posted a patch a few weeks ago, It might have been overlocked or just
> uggly :)
> Basically it did a dbus-event from pm-utils.
> http://lists.freedesktop.org/archives/devkit-devel/2009-November/000527.html
No, you need to define the signal in the DeviceKit-power int
2009/12/9 Jedy Wang :
> Thanks for your reply. Will gnome-powre-manager 2.30 depends on upower?
Yes, I hope so as long as we can add it to the GNOME external deps list.
> Except name changing, are there any new features in upower?
Nope. At some point I'm going to talk to Bastien about ambient li
1 - 100 of 292 matches
Mail list logo
