mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Pavel Machek <pavel@suse.cz>
Cc: dtor_core@ameritech.net, Oliver Neukum <oliver@neukum.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	James Simmons <jsimmons@pentafluge.infradead.org>,
	Adrian Bunk <bunk@stusta.de>,
	Linux Input Devices <linux-input@atrey.karlin.mff.cuni.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6: drivers/input/power.c is never built
Date: Fri, 18 Feb 2005 21:40:18 +0100	[thread overview]
Message-ID: <20050218204018.GA2760@ucw.cz> (raw)
In-Reply-To: <20050218202443.GB1403@elf.ucw.cz>

On Fri, Feb 18, 2005 at 09:24:43PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > But input layer shoudl not be used as a generic transport. I mean
> > > > > battery low, docking requests, etc has nothing to do with input.
> > > > 
> > > > Well, plugging in a power cord is a physical user action much like
> > > > closing the lid is, much like pressing the power button is, much like
> > > > pressing a key is.
> > > 
> > > What about power dying and my UPS switing on? I think it is out of
> > > input layer,
> > 
> > Yes, I was thinking about this, too. An UPS is pretty much the same
> > thing to a desktop as a battery is to a notebook. And I also got to the
> > conclusion that this is a bad idea.
> 
> Well, I'm not sure if input layer is suitable for batteries... Modern
> battery has quite a lot of parameters. It can tell you current
> voltage, current capacity (either mAh or mWh), design capacity, last
> capacity at full charge, current current, battery's estimate of run
> time (which may be better than system's estimate), ... But some
> batteries only know percentage of energy left, and some batteries only
> know current voltage (you can estimate %left from that). I'm not sure
> if input system can handle all that complexity...

I wouldn't want to pass all the battery info (UPSes can be even more
complex, able to switch on/off individual sockets, etc) through input,
just the basic events:

	AC power on/off
	battery full/normal/low/critical/(fail)

Then the other power-related events

	Lid open/closed
	Power button
	Sleep button

I think that's all you need to trigger actions. You don't need the exact
percentage of the battery, and you don't need the exact AC voltage at
input. 

Nice graphics battery monitors in X can gather their information from
the platform specific sources, since they'll need it all in the greatest
detail.

PS.

full = not charging
normal = OK state, charging if AC
low = better shutdown if you don't want to stress the battery
      (namely LiIon batteries prefer not to be discharged too much)
critical = last chance to shutdown cleanly
fail = battery present, but doesn't work.

A server, while booting should wait for battery going at least to 'low'
before mounting system read/write, otherwise subsequent power failures
might cause damage.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

  reply	other threads:[~2005-02-18 20:39 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-13  0:47 Adrian Bunk
2005-02-14 18:04 ` James Simmons
2005-02-14 19:34   ` Vojtech Pavlik
2005-02-18 12:22     ` Pavel Machek
2005-02-18 13:10       ` Richard Purdie
2005-02-18 13:26         ` Pavel Machek
2005-02-18 13:36           ` Oliver Neukum
2005-02-18 16:01             ` Pavel Machek
2005-02-18 17:00               ` Vojtech Pavlik
2005-02-18 17:05                 ` Oliver Neukum
2005-02-18 17:48                   ` Vojtech Pavlik
2005-02-18 21:32                     ` James Simmons
2005-02-18 20:14                   ` Pavel Machek
2005-02-18 20:39                     ` Oliver Neukum
2005-02-18 18:19                 ` Dmitry Torokhov
2005-02-18 18:39                   ` Vojtech Pavlik
2005-02-18 19:20                     ` Dmitry Torokhov
2005-02-18 20:05                       ` Vojtech Pavlik
2005-02-18 20:24                         ` Pavel Machek
2005-02-18 20:40                           ` Vojtech Pavlik [this message]
2005-02-18 20:59                             ` Pavel Machek
2005-02-18 21:23                             ` Oliver Neukum
2005-02-18 21:34                               ` Pavel Machek
2005-02-18 22:00                                 ` Oliver Neukum
2005-02-18 23:34                                   ` Pavel Machek
2005-02-18 23:51                                     ` Oliver Neukum
2005-02-19  0:13                                       ` Pavel Machek
2005-02-19  1:16                                       ` Xavier Bestel
2005-02-18 21:38                               ` Vojtech Pavlik
2005-02-18 23:31                                 ` Pavel Machek
2005-02-19  2:58                                   ` Dmitry Torokhov
2005-02-19  6:28                                     ` Nigel Cunningham
2005-02-19  6:53                                       ` Dmitry Torokhov
2005-02-19  9:10                                         ` Nigel Cunningham
2005-02-21 18:11                                       ` James Simmons
2005-02-21 18:34                                         ` Wichert Akkerman
2005-02-21 21:37                                           ` James Simmons
2005-02-21 22:50                                             ` Nigel Cunningham
2005-02-21 22:52                                               ` James Simmons
2005-02-21 22:57                                                 ` Wichert Akkerman
2005-02-21 22:54                                               ` Wichert Akkerman
2005-02-19 20:29                                     ` Pavel Machek
2005-02-19 20:31                                     ` Pavel Machek
2005-02-21 18:19                                 ` James Simmons
2005-02-18 14:02           ` Richard Purdie
2005-02-18 14:12           ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050218204018.GA2760@ucw.cz \
    --to=vojtech@suse.cz \
    --cc=bunk@stusta.de \
    --cc=dtor_core@ameritech.net \
    --cc=jsimmons@pentafluge.infradead.org \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver@neukum.org \
    --cc=pavel@suse.cz \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®