Sascha Silbe | 1 May 2010 18:44

[PATCH] fix recognition of lithium iron phosphate (LiFePO4) batteries

The linux kernel returns "LiFe" for lithium iron phosphate batteries,
not LiFo.
---
 src/linux/up-device-supply.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/linux/up-device-supply.c b/src/linux/up-device-supply.c
index 173959a..cb5903b 100644
--- a/src/linux/up-device-supply.c
+++ b/src/linux/up-device-supply.c
 <at>  <at>  -269,7 +269,7  <at>  <at>  up_device_supply_convert_device_technology (const gchar *type)
 		return UP_DEVICE_TECHNOLOGY_LITHIUM_POLYMER;
 	if (g_ascii_strcasecmp (type, "nimh") == 0)
 		return UP_DEVICE_TECHNOLOGY_NICKEL_METAL_HYDRIDE;
-	if (g_ascii_strcasecmp (type, "lifo") == 0)
+	if (g_ascii_strcasecmp (type, "life") == 0)
 		return UP_DEVICE_TECHNOLOGY_LITHIUM_IRON_PHOSPHATE;
 	return UP_DEVICE_TECHNOLOGY_UNKNOWN;
 }
--

-- 
1.6.5

Richard Hughes | 3 May 2010 16:18
Picon

Re: [PATCH] fix recognition of lithium iron phosphate (LiFePO4) batteries

On 1 May 2010 17:44, Sascha Silbe <sascha-pgp <at> silbe.org> wrote:
> diff --git a/src/linux/up-device-supply.c b/src/linux/up-device-supply.c
> index 173959a..cb5903b 100644
> --- a/src/linux/up-device-supply.c
> +++ b/src/linux/up-device-supply.c
>  <at>  <at>  -269,7 +269,7  <at>  <at>  up_device_supply_convert_device_technology (const gchar *type)
>                return UP_DEVICE_TECHNOLOGY_LITHIUM_POLYMER;
>        if (g_ascii_strcasecmp (type, "nimh") == 0)
>                return UP_DEVICE_TECHNOLOGY_NICKEL_METAL_HYDRIDE;
> -       if (g_ascii_strcasecmp (type, "lifo") == 0)
> +       if (g_ascii_strcasecmp (type, "life") == 0)
>                return UP_DEVICE_TECHNOLOGY_LITHIUM_IRON_PHOSPHATE;
>        return UP_DEVICE_TECHNOLOGY_UNKNOWN;
>  }

Applied, many thanks.

Richard.
_______________________________________________
devkit-devel mailing list
devkit-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Richard Hughes | 6 May 2010 11:30
Picon

UPower 0.9.3 released!

Version 0.9.3
~~~~~~~~~~~
Released: 2010-05-06

New Features:
 - Add a config file with SleepTimeout and AllowHibernateEncryptedSwap
entries (Richard Hughes)

Bugfixes:
 - Fix c&p typo in documentation (Michael Biebl)
 - The gettext package should match the tarball name (Richard Hughes)
 - Provide UpDaemon with C setters rather than relying on GObject
properties (Richard Hughes)
 - Sanity check the device is not already in the list before adding
(Richard Hughes)
 - Fix recognition of lithium iron phosphate (LiFePO4) batteries (Sascha Silbe)

Richard.
Baybal Ni | 7 May 2010 10:02
Picon

Why I can't compile upower without policykit and other *kit stuff?

Why I can't compile upower without policykit and other *kit stuff?
Richard Hughes | 7 May 2010 10:26
Picon

Re: Why I can't compile upower without policykit and other *kit stuff?

On 7 May 2010 09:02, Baybal Ni <nikulinpi <at> gmail.com> wrote:
> Why I can't compile upower without policykit and other *kit stuff?

Because UPower uses PolicyKit as a security framework. Why do you want
to change it?

Richard.
Baybal Ni | 7 May 2010 10:34
Picon

Re: Why I can't compile upower without policykit and other *kit stuff?

Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework.

On 7 May 2010 01:26, "Richard Hughes" <hughsient <at> gmail.com> wrote:

On 7 May 2010 09:02, Baybal Ni <nikulinpi <at> gmail.com> wrote:
> Why I can't compile upower without pol...

Because UPower uses PolicyKit as a security framework. Why do you want
to change it?

Richard.
<div>
<p>Yes, if it's security matter at least make it working without suid root first, like use pam instead. This policykit is hardly a security framework.</p>
<p></p>
<blockquote type="cite">On 7 May 2010 01:26, "Richard Hughes" &lt;<a href="mailto:hughsient <at> gmail.com">hughsient <at> gmail.com</a>&gt; wrote:<br><br><p>On 7 May 2010 09:02, Baybal Ni &lt;<a href="mailto:nikulinpi <at> gmail.com">nikulinpi <at> gmail.com</a>&gt; wrote:<br>
&gt; Why I can't compile upower without pol...</p>Because UPower uses PolicyKit as a security framework. Why do you want<br>
to change it?<br><br>
Richard.<br>
</blockquote>
</div>
David Zeuthen | 7 May 2010 14:36
Picon

Re: Why I can't compile upower without policykit and other *kit stuff?

On Fri, May 7, 2010 at 4:34 AM, Baybal Ni <nikulinpi <at> gmail.com> wrote:
> Yes, if it's security matter at least make it working without suid root
> first, like use pam instead. This policykit is hardly a security framework.

Can you elaborate on the last statement please?

     David
Tobias Arrskog | 7 May 2010 21:30
Favicon

Sleeping signal is only emitted if AboutToSleep is called

Hi!

I'm one of the developer over at team-xbmc and I recently noticed that UPower have added the Sleeping and Resuming signals, awesome!

I noticed a problem with them when implementing them into xbmc however. The resuming signal works fine but the sleeping signal is only emitted if I call AboutToSleep.
According to docs its supposed to be emitted on calls to hibernate and suspend aswell, which its not. In XBMC we could easily call AboutToSleep first but gnome doesn't seem to do this and
then the event won't get emitted to us and we are kept in the dark about the sleep.

Also as an application all what I want is signals that happen when 1) a sleep will occur unless something goes terribly wrong (but note here it should be beyond the point of no return regarding cancelation of sleep). 2) on resume (this one works perfectly) and optionally 3) when the system might sleep but I have the power to cancel it.
In 1 I must assume that the system will sleep and I can do stuff like stop playback etc. and 1 second is enough to handle anything to prepare for that. 3 would be nice since then I can do certain stuff that won't interfere with the usage of the application, like auto-saving something in case the sleep would fail. This one could easily be optional for the application thats about to call since the actual suspend will still signal sleeping. 
I consider the current sleep signal being 1, thus it might be abit weird to have AboutToSleep signal Sleeping since there is no obligation for another application to call suspend / hibernate. Perhaps I assume wrong here?

Thanks for an awesome job, the new UPower is otherwise extremely good! (UDisk and those are aswell very nice).

Cheers,
Tobias.
<div>
<p>Hi!</p>
<div>I'm one of the developer over at team-xbmc and I recently noticed that UPower have added the Sleeping and Resuming signals, awesome!<div><br></div>
<div>I noticed a problem with them when implementing them into xbmc however. The resuming signal works fine but the sleeping signal is only emitted if I call AboutToSleep.</div>
<div>According to docs its supposed to be emitted on calls to hibernate and suspend aswell, which its not. In XBMC we could easily call AboutToSleep first but gnome doesn't seem to do this and</div>
</div>
<div>then the event won't get emitted to us and we are kept in the dark about the sleep.</div>
<div><br></div>
<div>Also as an application all what I want is signals that happen when 1) a sleep will occur unless something goes terribly wrong (but note here it should be beyond the point of no return regarding cancelation of sleep). 2) on resume (this one works perfectly) and optionally 3) when the system might sleep but I have the power to cancel it.</div>
<div>In 1 I must assume that the system will sleep and I can do stuff like stop playback etc. and 1 second is enough to handle anything to prepare for that. 3 would be nice since then I can do certain stuff that won't interfere with the usage of the application, like auto-saving something in case the sleep would fail. This one could easily be optional for the application thats about to call since the actual suspend will still signal sleeping.&nbsp;</div>
<div>I consider the current sleep signal being 1, thus it might be abit weird to have AboutToSleep signal Sleeping since there is no obligation for another application to call suspend / hibernate. Perhaps I assume wrong here?</div>
<div><br></div>
<div>Thanks for an awesome job, the new UPower is otherwise extremely good! (UDisk and those are aswell very nice).</div>
<div><br></div>
<div>Cheers,</div>
<div>Tobias.</div>
</div>
Richard Hughes | 7 May 2010 21:48
Picon

Re: Sleeping signal is only emitted if AboutToSleep is called

On 7 May 2010 20:30, Tobias Arrskog <topfs2 <at> xboxmediacenter.com> wrote:
> I noticed a problem with them when implementing them into xbmc however. The
> resuming signal works fine but the sleeping signal is only emitted if I call
> AboutToSleep.

That sounds like a bug. I'll fix that up now.

Richard.
Richard Hughes | 7 May 2010 21:58
Picon

Re: Sleeping signal is only emitted if AboutToSleep is called

On 7 May 2010 20:48, Richard Hughes <hughsient <at> gmail.com> wrote:
> On 7 May 2010 20:30, Tobias Arrskog <topfs2 <at> xboxmediacenter.com> wrote:
>> I noticed a problem with them when implementing them into xbmc however. The
>> resuming signal works fine but the sleeping signal is only emitted if I call
>> AboutToSleep.
>
> That sounds like a bug. I'll fix that up now.

Could you try with upower from git master please? There's a SRPM here
if that helps: http://people.freedesktop.org/~hughsient/fedora/13/SRPMS/

Thanks.

Richard.

Gmane