Re: [gpm] Using HAL: reporting.low and reporting.warning

[Jaap Haitsma <jaap haitsma org>]

Richard Hughes wrote:
> On Tue, 2006-01-10 at 04:38 +0100, Jaap Haitsma wrote:
>
> > Richard Hughes wrote:
> >
> > > On Sat, 2006-01-07 at 05:11 +0100, Jaap Haitsma wrote:
> > >
> > >
> > > > Hi Richard,
> > > >
> > > > My batteries have as properties in HAL a reporting.low and 
> > > > reporting.warning (also charge_level.low and charge_level.warning and 
> > > > these have the same number so I guess they are the same thing)
> > >
> > >
> > > Yes, defined by ACPI, and exported by HAL. I'm not sure if these are set
> > > at manufacture time, or change with the battery lifetime.
> >
> > These settings are fixed. Low or critical battery capacity remains low 
> > no matter how old your batteries are.
> >
> > The thing that changes is the last_full capacity. These decrease due to 
> > aging of the battery.
>
>
> Hmm, it's a shame low and critical are not updated for the lifetime of
> the battery.

Probably I wasn't clear

But they should not be updated. With for example 1000mWh left and a 
latop taking about 10000mWh you'll have always 6 minutes of battery life 
left. The thing that's going down is the full charge which might have 
been 50000mWh when you buy them (so you 5 hours of battery time). The 
full capacity might go down to 30000mWh after a year of heavy use which 
gives you 3 hours of battery time. The critical threshold in that case 
will still be 1000mWh which still gives you 6 minutes.


> > > > Can't we use these properties instead of the sliders? Or are these 
> > > > properties not present for all type of batteries?
> > >
> > >
> > > I think maybe these values could set the default for the sliders, but I
> > > think the sliders should remain -- as people have different preferences
> >
> > Let me try to convince you that people do not have different preferences 
> > here.
> >
> > When batteries are getting low people just want a warning which says 
> > that their batteries are low and that they have let's say 10, 20 or 30 
> > minutes more.
>
>
> The thing is, I'm pretty good at ignoring the first few warnings, rather
> than scrambling to find the ac_adapter. I'm sure other people are just
> the opposite.
>
>
> > If batteries are critical there should be a warning dialog 
> > and the laptop should hibernate within 10 seconds if the user does not 
> > cancel it. (We should still add this option that a user can cancel 
> > hibernation, a user might want to hit the send button of his mail 
> > program before hibernating )
>
>
> We need to use the libnotify callbacks for this I think.
>
>
> > The sliders with percentages do not work well if you for example now and 
> > then use 2 batteries now or use batteries with different capacities.
>
>
> Yes, this is a valid point. What about we just throw these sliders away,
> and define a per-time warning, like a lot of people want.
>
> As long as we have a sufficiently long warning time, compared to the
> resolution of the updates and the changing of the cpu load, the aliasing
> and inaccuracy shouldn't be a problem.
>
> What about:
>
> 1 notice at 20 minutes
> 1 warning at 10 minutes
> 1 critical warning at 5 minutes, with a link that lets the user abort
> the action?
> 2 minutes later, the action is performed regardless

I'm all for it with some minor changes

I'd say to make you notice things we should use modal dialogs when thing 
s are getting critical.

So:
1 notification warning at 20 minutes
1 modal dialog at 10 minutes ( to make sure the user notices this)
1 critical warning at 5 minutes in modal dialog (will hibernate within 
10 seconds) with a button that lets the user abort the action

2 minutes later a dialog pops up with a message that the system will 
hibernate in 10 seconds. This gives the user a change to still do this 
last minute thing.



> Does this have to be configurable? 

No

Jaap