lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ