Marco, Could you split the actual ALS driver and the modifications to the rest in 2 separate patches? On Mon, Jun 06, 2011 at 09:41:24AM +0200, Javier Achirica wrote: > On Mon, Jun 6, 2011 at 12:21 AM, Marco Chiappero <marco@xxxxxxxxxx> wrote: > > Il 05/06/2011 07:31, Mattia Dongili ha scritto: > >> > >> To my understanding, SNC will receive GPEs in two cases under managed > >> mode: > >> 1. when the user request a backlight change via the standard acpi_video > >> 2. when ambient light changes > > > > Right, more in detail: > > > > When managed mode is set to 1, automatic backlight is desired by the user > > and a userspace tool is supposed to take control of every backlight change, > > to be applied via als_backlight node (which offers a fine grain backlight > > control for smooth transitions). It will receive two different types of ALS > > events, depending on the source of the event, as you said: 1 - ambient light > > change 2 - backlight change request via backlight device (in linux, the > > standard acpi_video backlight device). When either of the two events occurs, > > this software will calculate a new backlight level (using a model specific > > formula) and set it by writing in the als_backlight file mentioned earlier. > > (NOTE: this is how the hardware has been designed and it supposed to work > > even though workarounds are possible). I don't think this is a feasible solution. sony-laptop already exposes the fine grained backlight control and there is nothing preventing userspace from doing the appropriate backlight calculation beforehand without this back and forth with the kernel. i.e. would it work if you always enable managed mode to receive the ambient light events and just let userpace react for automatic dimming? Also, userspace will intercept key-presses and scale the user requested brightness change to an appropriate value using the current lux values. At this point you could have a generic software (modulo the not yet standardized als interface) handling any laptop that has these simpler features. > > When managed mode is set to 0, no automatic backlight control is requested > > by the user and no userspace software is doing any backlight regulation > > based on the ALS readings. This implies that no ALS events are generated > > (regardless the source) and the standard ACPI backlight methods (used by > > the acpi_video backlight device) will work properly as usual. > > > >> In both cases your code sends an acpi event to userspace. Let alone the > >> acpi event discussion that belongs to another thread, why aren't we > >> just setting the requested brightness? > > > > Simply because any calculation can be done in userspace, but if we can the question was why sending a "user requested to change brightness"-event instead of setting the brightness. The calculation should be done in userspace but for what we know the user input could already take ALS parameters into consideration so we should just set that value. > > include the calculation stuff inside the driver, then we can get rid of the > > daemon, everything will be easier and we can avoid the als_backlight file > > too. Is it possible? The formulas are a bit complex but just a few lines of > > code, while the keyboard backlight based on the ambient light is just a > > matter of a threshold check. > > It bothers me a bit that due to the fact that Sony implemented complex > formulas using floating point arithmetic, that would require us to use > floating point within the kernel. In fact in Sony Windows drivers > everything is done in user-space. Hiding the calculation of the lux > values and handling interrupt set-up in the kernel seems like a good > thing, but moving all management there, not. agreed, one such policy handling has little to do with the kernel. -- mattia :wq! -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
