From: Pavel Machek <pavel@suse.cz>
To: Thomas Renninger <trenn@suse.de>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
linux-acpi@vger.kernel.org, linux-pm@lists.osdl.org,
Stefan Seyfried <seife@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] [1/3] Generic in-kernel AC status
Date: Thu, 16 Feb 2006 23:44:40 +0100 [thread overview]
Message-ID: <20060216224439.GL3490@openzaurus.ucw.cz> (raw)
In-Reply-To: <43F3206B.6090902@suse.de>
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
Hi!
> >This is not true as far as my box is concerned
> >(Asus L5D). It starts with
> >the _highest_ clock available.
> Hmm, but then there shouldn't be any critical
> overheat problems and if,
> the hardware has to switch off the machine
> hard. OS always could freeze,
> but the battery must not start to burn...
I told that to hw designers... too late. Fortunately batteries usually
only crash machine if you overload them.
> IMO, the /sys/.../brightness patch should go in
> as soon as possible, I think
> all everybody agrees here?
Yep.
> Maybe I oversaw an issue, but I really don't
> see a reason for connecting
> the brightness to ac in kernel space.
We are not going to connect it. But to implement .../brightness, you need to
know ac/battery on several "broken" notebooks.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@suse.cz>
To: Thomas Renninger <trenn@suse.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@suse.cz>,
Stefan Seyfried <seife@suse.de>,
Matthew Garrett <mjg59@srcf.ucam.org>,
linux-pm@lists.osdl.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] [1/3] Generic in-kernel AC status
Date: Thu, 16 Feb 2006 23:44:40 +0100 [thread overview]
Message-ID: <20060216224439.GL3490@openzaurus.ucw.cz> (raw)
In-Reply-To: <43F3206B.6090902@suse.de>
Hi!
> >This is not true as far as my box is concerned
> >(Asus L5D). It starts with
> >the _highest_ clock available.
> Hmm, but then there shouldn't be any critical
> overheat problems and if,
> the hardware has to switch off the machine
> hard. OS always could freeze,
> but the battery must not start to burn...
I told that to hw designers... too late. Fortunately batteries usually
only crash machine if you overload them.
> IMO, the /sys/.../brightness patch should go in
> as soon as possible, I think
> all everybody agrees here?
Yep.
> Maybe I oversaw an issue, but I really don't
> see a reason for connecting
> the brightness to ac in kernel space.
We are not going to connect it. But to implement .../brightness, you need to
know ac/battery on several "broken" notebooks.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
next prev parent reply other threads:[~2006-02-16 22:44 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 12:57 [PATCH, RFC] [1/3] Generic in-kernel AC status Matthew Garrett
2006-02-08 13:03 ` [PATCH, RFC] [2/3] ACPI support for generic " Matthew Garrett
2006-02-08 13:04 ` [PATCH, RFC] [1/3] Generic " Matthew Garrett
2006-02-08 13:05 ` [PATCH, RFC] [3/3] APM support for generic " Matthew Garrett
2006-02-08 16:58 ` [linux-pm] Re: [PATCH, RFC] [1/3] Generic " Greg KH
2006-02-08 17:08 ` Matthew Garrett
2006-02-08 17:08 ` [linux-pm] " Matthew Garrett
2006-02-08 17:16 ` Greg KH
2006-02-08 17:49 ` Matthew Garrett
2006-02-09 5:46 ` Greg KH
2006-02-09 8:53 ` Gabor Gombas
2006-02-10 12:21 ` Pavel Machek
2006-02-10 12:21 ` Pavel Machek
2006-02-10 13:13 ` Gabor Gombas
2006-02-10 13:13 ` [linux-pm] " Gabor Gombas
2006-02-10 13:19 ` Matthew Garrett
2006-02-10 13:54 ` Pavel Machek
2006-02-10 13:54 ` Pavel Machek
2006-02-10 13:56 ` Gabor Gombas
2006-02-10 13:56 ` [linux-pm] " Gabor Gombas
2006-02-08 22:25 ` Philipp Matthias Hahn
2006-02-10 12:21 ` Pavel Machek
2006-02-10 8:06 ` Stefan Seyfried
2006-02-10 8:06 ` Stefan Seyfried
2006-02-10 12:19 ` Pavel Machek
2006-02-10 12:19 ` Pavel Machek
2006-02-10 12:32 ` Stefan Seyfried
2006-02-10 12:32 ` Stefan Seyfried
2006-02-10 13:46 ` Pavel Machek
2006-02-10 13:46 ` Pavel Machek
2006-02-12 10:17 ` Jan Engelhardt
2006-02-12 11:27 ` Kyle Moffett
2006-02-14 17:44 ` Thomas Renninger
2006-02-14 17:44 ` Thomas Renninger
2006-02-14 20:17 ` Rafael J. Wysocki
2006-02-14 20:17 ` Rafael J. Wysocki
2006-02-15 12:36 ` Thomas Renninger
2006-02-15 12:36 ` Thomas Renninger
2006-02-15 12:47 ` Matthew Garrett
2006-02-15 12:47 ` Matthew Garrett
2006-02-15 15:04 ` Thomas Renninger
2006-02-16 22:44 ` Pavel Machek [this message]
2006-02-16 22:44 ` Pavel Machek
2006-02-16 22:39 ` Pavel Machek
2006-02-16 22:39 ` Pavel Machek
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=20060216224439.GL3490@openzaurus.ucw.cz \
--to=pavel@suse.cz \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mjg59@srcf.ucam.org \
--cc=seife@suse.de \
--cc=trenn@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.