[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1249348343.3556.120.camel@localhost.localdomain>
Date: Tue, 04 Aug 2009 09:12:23 +0800
From: ykzhao <yakui.zhao@...el.com>
To: Zhang Rui <rui.zhang@...el.com>
Cc: linux-acpi <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
Richard Purdie <rpurdie@...ys.net>,
Matthew Garrett <mjg59@...f.ucam.org>,
Pavel Machek <pavel@....cz>
Subject: Re: [PATCH 0/3] Generic sysfs support for ACPI ALS and other
ALS devices
On Mon, 2009-08-03 at 17:10 +0800, Zhang Rui wrote:
> Hi, all,
>
> This is the patch set I made to introduce ACPI ALS device driver
> and a generic sysfs I/F for all the ALS devices, like ACPI ALS,
> platform ALS, etc.
>
> Patch 01 introduces the ACPI ALS device driver.
Great jobs.
But I still have two questions about the patch set.
1. _ALP polling method
This optional object returns the recommended polling frequency for
the ambient sensor. And OSPM can use the recommended polling frequency
to poll the ambient sensor.
Of course the spec 9.2.6 also says that the use of polling is allowed
but strongly discouraged by this specification. In such case we had
better not use the polling frequency. Instead it will totally depend on
the async notification event.
Can some message be printed that the polling frequency is depreciated
when the _ALP is not zero?
2. what is the ALS policy and how to use it?
The main purpose of ambient sensor is to adjust the brightness
according to the current luminance environment. From this patch set it
seems that this will be done in user space. But it is not very clear how
to adjust the brightness based on the current luminance.
Can we describe it more clearly?
Another little issue is the memory leak in the patch 1.
When it receives the notification event(0x82), it will re-evaluate the
mapping between brightness and luminance. The memory space occupied by
previous mapping should be freed.
Thanks.
>
> Patch 02 introduces ALS sysfs class.
> Two sysfs I/F are created for each ALS device.
> /sys/class/als/alsX/illuminance:
> the amount of light incident upon a specified surface area.
> /sys/class/als/alsX/mappings:
> ambient light illuminance to display luminance mappings
> that can be used by an OS to calibrate its ambient light policy
> this is what I got on a test box:
> cat /sys/class/als/als0/mappings
> Illuminance Adjustment
> 0 70
> 10 73
> 80 85
> 300 100
> 1000 150
> - noting that display luminance adjustment values are specified
> using relative percentages in order simplify the means by which
> these adjustments are applied in lieu of changes to the user’s
> display brightness preference.
>
> Patch 03 introduces the generic sysfs I/F for ACPI ALS devices.
>
> Patch 02/03 are RFC patches because I'm not sure if these sysfs I/F are
> generic enough for other ALS devices, and if there is any attribute that
> I missed.
> For example, ACPI ALS has some optional properties like ambient light
> temperature and ambient light color chromaticity, but I'm not sure if
> they should be exported to user spaces via ALS sysfs class.
>
> Any comments are welcome.
>
> thanks,
> rui
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists