Hmm,
I found nothing interesting in your acpidump.
It seems that there are no ACPI fan/thermal devices in your bios.
In fact, many thermal/fan are ACPI transparent and they are controlled
by the bios or something else like hardware monitor.
Is there an obvious overheating problem on your system?
On 8/23/07, Zhang, Rui wrote:
Hmm,
I found nothing interesting in your acpidump.
It seems that there are no ACPI fan/thermal devices in your bios.
In fact, many thermal/fan are ACPI transparent and they are controlled
by the bios or something else like hardware monitor.
Is there an obvious
I like it, Rui.
I think that upon this patch, we can start to deprecate acpi_bus_generate_event,
as every user of it is now handled by the input layer or netlink.
applied.
thanks,
-Len
On Wednesday 22 August 2007 13:24, Zhang Rui wrote:
As a replacement of /prco/acpi/event, all ACPI events
Thanks for the refreshed patch series, Rui.
I've added it to acpi-test.
Still waiting on an ACK from Dmitry on the input.h definitions.
-Len
On Monday 20 August 2007 06:23, Zhang Rui wrote:
From: Yu Luming [EMAIL PROTECTED]
Add keycode for ACPI video driver hotkey events.
Signed-off-by:
On 8/23/07, Len Brown [EMAIL PROTECTED] wrote:
Thanks for the refreshed patch series, Rui.
I've added it to acpi-test.
Still waiting on an ACK from Dmitry on the input.h definitions.
Sorry, I am still trying to recover from a hard drive failure...
The keycodes conflict with a pending patch
This is a good debug patch.
But I'd rather not bother upstream with it,
unless there is another case besides bugzilla 8630
that needs it. For Linux should be fixed to handle
the failure in 8630 automatically w/o need for user-intervention.
thanks,
-Len
On Monday 20 August 2007 05:48, Zhao Yakui
On Thu, 23 Aug 2007, Dmitry Torokhov wrote:
On 8/23/07, Len Brown [EMAIL PROTECTED] wrote:
Thanks for the refreshed patch series, Rui.
I've added it to acpi-test.
Still waiting on an ACK from Dmitry on the input.h definitions.
Sorry, I am still trying to recover from a hard drive
Hi Len!
On Thu, 23 Aug 2007, Len Brown wrote:
I like it, Rui.
I think that upon this patch, we can start to deprecate
acpi_bus_generate_event,
as every user of it is now handled by the input layer or netlink.
applied.
This calls for (good!) changes in thinkpad-acpi and some issues I
The following patch adds support for features on various Fujitsu laptops
which are not accessible using the standard ACPI kernel modules. Of
particular interest to me is the software control of screen brightness,
which allows software to turn the screen back on following a resume from
Thanks for the feedback.
+static int acpi_fuj02b1_get_volume_state(void *data)
This probably wants to be exported as an ALSA mixer rather than a
special device in /proc.
Or dropped altogether. As I mentioned, this patch is simply something I
picked up off the net. The only really
+static int acpi_fuj02b1_get_volume_state(void *data)
This probably wants to be exported as an ALSA mixer rather than a
special device in /proc.
+static int acpi_fuj02b1_get_brightness_state(void *data)
And this certainly wants to use the backlight class.
+static int
On Thursday 23 August 2007 17:22, Henrique de Moraes Holschuh wrote:
Hi Len!
On Thu, 23 Aug 2007, Len Brown wrote:
I like it, Rui.
I think that upon this patch, we can start to deprecate
acpi_bus_generate_event,
as every user of it is now handled by the input layer or netlink.
Oh, i forgot to mention also...
There should be no new files created under /proc/acpi
for platform specific drivers.
Sure. In the case of the backlight control (which is the thing I most care
about) this will be taken care of by virue of utilising the backlight class
as per Matthew's email.
On Thursday 23 August 2007 22:13, Len Brown wrote:
I agree with everything Matthew wrote.
Also, please move it to drivers/misc, to keep msi-laptop,
sony-laptop, asus-laptop, and thinkpad-acpi company.
toshiba-acpi is in drivers/acpi just because it is being neglected --
but the new scheme
On Tuesday 21 August 2007 09:22, Alexey Starikovskiy wrote:
+ printk(KERN_ERR PREFIX ECDT is broken\n);
I think this is
1. guaranteed to happen
2. guaranteed to alarm users and be viewed as a regression.
They have no clue what an ECDT is, and this warning
doesn't tell them what
Len Brown wrote:
On Tuesday 21 August 2007 09:22, Alexey Starikovskiy wrote:
+printk(KERN_ERR PREFIX ECDT is broken\n);
I think this is
1. guaranteed to happen
No, it does not happen on machine with correct ECDT, e.g. my TP is ok.
2. guaranteed to alarm users and
On Fri, 2007-08-24 at 02:32 +0100, Matthew Garrett wrote:
+static int acpi_fuj02b1_get_volume_state(void *data)
This probably wants to be exported as an ALSA mixer rather than a
special device in /proc.
+static int acpi_fuj02b1_get_brightness_state(void *data)
And this certainly
This fix breaks another ASUS in 8909 and 8919. Revert it for now.
Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED]
---
drivers/acpi/ec.c | 47 +++
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ec.c
On Thursday 23 August 2007 16:10, Dmitry Torokhov wrote:
On 8/23/07, Len Brown [EMAIL PROTECTED] wrote:
Thanks for the refreshed patch series, Rui.
I've added it to acpi-test.
Still waiting on an ACK from Dmitry on the input.h definitions.
Sorry, I am still trying to recover from a
On Fri, Aug 24, 2007 at 11:55:41AM +0800, Zhang Rui wrote:
I have the same question for ACPI video driver.
Take KEY_BRIGHTNESSUP/KEY_BRIGHTNESSDOWN for example, if ACPI video
driver gets such a notification, it will change the brightness level
first and then send an event to user space.
The
On Thursday 23 August 2007 23:15, Jonathan Woithe wrote:
Oh, i forgot to mention also...
There should be no new files created under /proc/acpi
for platform specific drivers.
Sure. In the case of the backlight control (which is the thing I most care
about) this will be taken care of by
On Wednesday 15 August 2007 12:32, Bjorn Helgaas wrote:
Fix a few more Lindent things and remove some unused code and
unnecessary casts.
The last patch removes some null pointer checks in cases where
I think it's better to just oops immediately rather than return
an error.
These look fine
On Friday 24 August 2007 00:10, Alexey Starikovskiy wrote:
This fix breaks another ASUS in 8909 and 8919. Revert it for now.
thanks Alexey.
Being -rc3, I agree it is prudent for now to apply this
and go back to the situation we had in 2.6.22
while a fix that doesn't cause other regressions
Applied.
thanks,
-Len
On Thursday 16 August 2007 12:18, Guillaume Chazarain wrote:
[Resent, with a bigger recipients list]
Hi,
The asus laptop driver conditionnaly registers leds in asus_led_register()
depending on their availability, but unconditionnaly registers them all at
exit time
On Monday 13 August 2007 08:10, Mattia Dongili wrote:
On Sun, Aug 12, 2007 at 04:20:28PM +0900, Mattia Dongili wrote:
Make the driver aware of this case and manage the existence of a
second separate IO port.
definitely too late for this now, sorry for the bad timing.
Could you push it to
System working fine, suspend-to disk crashes on shutdown
# dmidecode 2.9
SMBIOS 2.4 present.
42 structures occupying 1539 bytes.
Table at 0x000DC010.
Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: LENOVO
Version: 63ET62WW
Release Date: 04/30/07
26 matches
Mail list logo
