I hope this could be fixed soon. It`s annoyng having the keyboard glowing 
whenever I
press a key. I suspect this could affect the already poor batery life.

any update on this issue? I would like just to be able to turn completely off 
the 
keyboard backlight

It seems that the ambient light sensor and keyboard back light are controlled 
via
ACPI.  I disassembled the DSDT from our BIOS and found them (and the methods), 
and
have been looking into the sony-laptop module in the kernel.  Anyone else 
interested
in collaborating and or swapping info to augment the sony-laptop module?

2 c.rammy
can you say, what methods (name) did you found?
I will try add they in sony-laptop module

Hello, just got a F121FX. Looking through the .dsl file... what are those 
methods called that control the keyboard backlight?
Thanks, Sam

Same issue in VPCS120FL

Hello, I can control keyboard backlight on my VAIO VPCS12A7R, but not trough 
ACPI, I'm use embedded controller. I'm write tiny code to do this.
May be this help to hack this option.

With best regards!

P.S. Sorry for my bad english.

Same issue on VPCS12C5E

Hmm. On Your laptop would work my small util. Please try it.
If this util would work on Your laptop, tell me please.

Hello. I have the S13.

Alkozel , your util can manage the backlight ? How it is set? In linux natively 
backlight is activated when we type. In windows it is based on the ambient 
light.

Yes, but not based on ALS, this util can set off, or on (backlight is activated 
when we type)

Warning this util write to the EC, this util testet on VPCS12 models only.
on other models i recomend to check the address that control backlight. You can 
use the ectool (http://www.coreboot.org/Laptop) to check this.

With best regards!

Ouch , looks very hard !

What is the risk if i try with a S13 without ectool ? 

And when he is installed , what we should type to put on or off your tool ? 

Sorry, but i don't known. This util write directly to the EC...
I'm help You, if help my.
Download the ectool.
Compile it, and run these command (need root)

ectool > 1.txt
sleep 5; ectool > 2.txt
sleep 20; ectool > 3.txt

after You run command, please don't touch keyboard.

Send these files to me.

[deleted comment]

I can do this.. I have a vpcs12c5e. Might be useful trying it on my laptop? 

Two question:
1. if I compile it, it can somehow dangerous for my computer?
2. this tool will control the keyboard backlight; but it will use the light 
sensor or I have to set it manually?

@10: Works on Sony Vaio VPCS11E7E! Thank you very much!

[deleted comment]

I have confirmation for your model - this util worked on VPCS12C5
Sorry this util not use backlight sensor, You can manually switch off keyboard 
backlight or switch on (automatic on backlit, when You touch any key on 
keyboard).

Thanks! It works!
Now my laptop is running with almost full of its power.. it lacks only the 
ambient light sensor to tune the keyboard backlight!

Thanks again!

I tried decoding ectool's output for an hour but failed to see a pattern for my 
VPCF127FX. There were a lot of changes for a seemingly idle laptop. What I did 
is to "watch" it every 0.5s. In the course of 1 minute, there were more than a 
dozen changes to the controller's memory.

I ruled out all these changing spots when I lit the keyboard up, but there were 
no newly changed spot as far as I could tell.

AlKozel, if it works the same as in your laptop. Can you tell me what trick you 
used/what to look out for to discover the right memory range?.

Thanks.

watch -n0 ectool

please give me output of these commands:

ectool > 1.txt
sleep 5; ectool > 2.txt
sleep 20; ectool > 3.txt

Here it is: http://tinypaste.com/590b6

I tried watching the output in real time and diffing the output at different 
times with no fruits. I can give out a series of output at predefined interval 
(say 0.1s) if that is helpful.

Thanks.

@ AIKo, 

 I am having the same issue with my VAIO VPCF111FX. If I can't get it fixed I am going to have to go back to Windows because my battery drains way to fast with the screen at maximum brightness and the keyboard always lighting up with ever key I hit. Do you think your utility will fix my issue? If so you are my hero! 

Hello,
I'm working on my VPCS12C5E laptop, and I can say that the keyboard backlight 
control will be available in sony-laptop, hopefully, soon (using the ACPI 
interface). May I have a couple of VPCF DSDT files to check whether it might 
work there too? Thanks!

Here it is, there are a bunch more files that the tool outputs, please tell me 
if you need anything else. My laptop is VPCF127FX.

Thanks.

Do not write to the EC directly, it is not necessary (we already know how to 
control it via ACPI) and might be dangerous. If you are able to compile a 
custom kernel (or a kernel module) I can provide you a patch to make the 
keyboard fully working. BTW, which distribution are you using?

Sorry for the late reply, I've had my hands full last week. I tested the 
patches with 2.6.37.3 today with these results:
- With vaio-test3.patch:
  + I could change brightness on terminal (X and nvidia module not loaded) via /sys/class/backlight/acpi_video0/brightness. Value ranges from 1 to 8.
  + I could suspend and hibernate reliably in the terminal and X.
  + As soon as X started, changing the brightness file had no effect. Brightness could then be changed only by nvidia_bl. To make sure, I set EnableBrightnessControl to 1 but it had no difference.
- With full-2.6.37.patch:
  + I could not change brightness via the ACPI file as above.
  + Suspend in terminal and X failed (hibernate not tested).
  + After X started, changing the brightness file had no effect as usual.

I will test ALS with the latest patch again to see if ACPI event works.

ALS event worked with the latest patch, thanks.

Would you attach the 'latest' here, please?

I'm not sure if there has been updates, but the latest downloadable patches can 
be found in comment 73rd. What's working flawlessly (albeit without ALS data) 
is vaio-test3.patch in comment 41st though.

Hi, happy to see some other people joining the tests!
I re-designed the code, it looks much better now, I removed lots of controls 
while the driver now takes care about the interrupt and thresholds stuff. I'm 
attaching a new patch and a new script (you have to change the backlight 
device, from sony to nvidia_backlight).
You can also find all the patches (renamed full to test5) at 
http://www.absence.it/vaio-acpi/source/patches/

The new interface (r=read w=write):
als_backlight (r): the suggested backlight value (percent, 0-100)
als_lux (r): light ambient (lux)
als_lux_threshold (rw): lux threshold for the maximum (100%) backlight value
als_model (r): the ALS model
als_power (rw): power on/off

Let's solve the suspend issue... any further log? Does suspend work before 
loading the nvidia_backlight module?

Thanks, the patch worked well. I adapted the script to work with nvidia_bl. If 
anyone has nvidia graphics and wonders about the script please let me know.

[deleted comment]

I haven't been able to test suspend though. Without additional log, I'm afraid 
there's not much point to try. I'll give it a go when 2.6.38 arrives in the 
next few days though. If anyone has nvidia graphics please try if it's OK. 
Thanks.

Suspend didn't work with or without the nvidia_bl module. I tested it by 
suspending in the terminal and X without loading the module. In both cases the 
display remained blank when resuming.

[deleted comment]

Are you sure this is caused by the sony-laptop module? Try to remove the module 
before triggering the suspend. You might try to disable the backlight device 
applying this patch (to the already vaio-test patched code). Post your last 
kern.log containing the failed resume.

About the script, I forgot about the step change and this:
> TARG_BRGT=$(($BACKLIT_PERC * BACKLIT_MAX / 100))

TARG_BRGT=$(($BACKLIT_PERC * $BACKLIT_MAX / 100))

You can also add these lines before the keyboard code:

sleep 0.02
echo $TARG_BRGT > /sys/class/backlight/nvidia_backlight/brightness

Remember to enable the sensor every time the module is loaded. Use it for a 
while and report if strange behaviour occurs (expecially in low light 
environments), then in the next days I'll ask you to do a small code change and 
verify everything is still fine. Don't bother too much about the script, it's 
just a temporary solution and rather intended to check whether the driver is 
now properly.

PS: before applying the patch: is the sony backlight device missing even 
without the nvidia_backlight module?

The 'problem' with auto dimming is that I know some people, like me, usually 
set the brightness based on what they're doing. For reading I leave it close to 
minimum or medium, for watching videos or gaming I usually set it close to 
maximum.

If als_lux_threshold is writable but static then in some instances the display 
may be a bit too dim, or too bright.

For that I'm thinking als_lux_threshold can be bound to the display brightness 
change keys (or other keys) so instead of absolute brightness it will be 
relative to the environment, but still gives people control. More simply, there 
can be a GUI applet to set the active 'mode': reading, watching video or gaming.

Edit: Actually the Nokia N900 does that too, the brightness control that can be 
set by user is still relative to the ambient lighting.

> Are you sure this is caused by the sony-laptop module? Try to remove the 
module before triggering the suspend. You might try to disable the backlight 
device applying this patch (to the already vaio-test patched code). Post your 
last kern.log containing the failed resume.

I was thinking along the same line, I'll do what you suggested and report back 
soon.

Yes I know that there is no chance to adjust the backlight value once the als 
is on, it's an annoying issue, but it's due to the lack of a daemon or the lack 
of the autodimming code in the driver. It will be solved for sure, not 
immediately unfortunately.
About the applet, in my dreams there is a sort of "vaio control center" applet 
where you can easily and quickly change all these settings but...

I'm back :) . So this is what was done:
- vaio-test3 module loaded
- vaio-test3 module unloaded
- test6 module loaded
- als_lux verified working
- test6 module unloaded
- Suspend/resume OK

I haven't succeeded to resuming the machine with patches after vaio-test3.

> About the script, I forgot about the step change and this:
Thanks, I didn't notice that, although the script worked fine (backlight 
changed gradually).

> You can also add these lines before the keyboard code:
Doesn't it set the backlight immediately?.

> Remember to enable the sensor every time the module is loaded. Use it for a 
while and report if strange behaviour occurs (expecially in low light 
environments)
There are quite a few unusual display backlight behaviors with the nvidia_bl 
module which I suspect is caused by hardware, but so far no other strange 
things reharding ALS were encountered.

> PS: before applying the patch: is the sony backlight device missing even 
without the nvidia_backlight module?
That's right, what I did was:
- Unloaded nvidia_bl
- Loaded sony-laptop with latest patch
- Check /sys/class/backlight and only acpi_video0 was present.

> I haven't succeeded to resuming the machine with patches after vaio-test3.

Ok, it is something in the driver, maybe the ALS or the backlight device (even 
thought I have no clues...).

> Doesn't it set the backlight immediately?.

It's not necessary, if you want to be sure it reaches the target and don't get 
just close to it because of the step > 1 (after the for loop, of course).

Ok, you can then revert the backlight_disable.patch after the suspend/resume 
test and add the acpi_backlight=sony parameter to your grub config file. The 
point is to understand whether the fine grain backlight controls available in 
our vaio's are working with the in intel gpu only. So look for and try to use 
the sony backlight device before and after loading the nvidia_backlight module. 
Be sure the parameter is recognized and honoured.

> Yes I know that there is no chance to adjust the backlight value once the als 
is on, it's an annoying issue, but it's due to the lack of a daemon or the lack 
of the autodimming code in the driver. It will be solved for sure, not 
immediately unfortunately.

Can you elaborate on how a daemon will allow dynamic adjustment of maximum 
brightness?. I think the problem here is we're trying to adjust the brightness 
to the most comfortable level, but people have differing opinions about what 
they feel are most comfortable. Under the same lighting, I want it dimmer when 
reading to not cause strain to my eyes, but I want maximum brightness when 
playing games to not miss any details.

Similarly, I'll gladly accept darker/hard to read screen in favor of better 
battery life. Although that can be done with no problems.

If possible, can you change the code (just for experiment) so that it notifies 
userspace whenever an interrupt occurs. At the moment it is acpid which handles 
the event, but we can allow for better compatibility by providing other means. 
I can see some ways to do it (forgive me if that's not possible, I'm not very 
familiar with kernel's internal):
- Notify via dbus if dbus is available
- Update a file in /sys/devices/platform/sony-laptop (e.g. als_lux_changed). 
File is modified whenever brightness changes by a certain threshold. The file 
can then be monitored by inotify/fanotify.
- Create an API so userspace can access sony-laptop module values, as well as 
being able to subscribe to events.

> About the applet, in my dreams there is a sort of "vaio control center" 
applet where you can easily and quickly change all these settings but...

Since we got most things working, such a GUI can be done quickly. I can build a 
small app for this when you deem the code is ready.

[deleted comment]

Oh.. Suspend to ram is working..

test results for vaio-test6 patch (sony vpcs12a7r):
+kbd_backlight can control
+ODD control
+charger limmiter
+als (can enable it and read data, kbd_light not based on als)
-touchpad control
-screen backlight control (screen backlight control work withount sony-laptop, 
or with sony-laptop, but als_power must set to 0)

i'm not use nvidia_bl to control the screen backlight.

i'm use these hacks:
on xorg.conf set Option          "RegistryDwords"        
"EnableBrightnessControl=1"
and add to 
/usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi

these lines:

      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" string="Sony Corporation">                                                              
              <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains_outof="VPCS12A7R">                                                    
                      <!-- needed since the acpi video module reports it handle the events, but it don't work on this machines-->                                       
                      <merge key="laptop_panel.brightness_in_hardware" type="bool">false</merge>                                                                        
      </match>                                                                                                                                                          
      </match>

> Ok, you can then revert the backlight_disable.patch after the suspend/resume 
test and add the acpi_backlight=sony parameter to your grub config file. The 
point is to understand whether the fine grain backlight controls available in 
our vaio's are working with the in intel gpu only. So look for and try to use 
the sony backlight device before and after loading the nvidia_backlight module. 
Be sure the parameter is recognized and honoured.

Sorry, I didn't test suspending with vaio-test6+backlight_disable patches in 
the last report. I have lots of source files opened and it would be a burden if 
it fails. I'll try it in due time.

Is acpi_backlight=sony the same as acpi_backlight=vendor?.

To reiterate, the only instance I could change backlight via ACPI file was in a 
terminal with vaio-test3 patch applied (I didn't test if vaio-test6 worked in 
the same condition). As soon as X started (I didn't check if it worked in 
terminal if only nvidia module is loaded), changing brightness via ACPI no 
longer works.

With or without the nvidia_bl module:
- After X started, changing to any terminal is possible but the display always 
stay blank (I could still login, input commands or change back to X normally 
though). The only time I could change to a working terminal is when using 
nouveau+KMS.

With nvidia_bl module:
- I can change brightness, but if brightness is any other values less than 
maximum: as soon as I turn off the backlight one way or another (by pressing 
DISPLAY OFF button on the keyboard, or by 'xset dpms force off'), when the 
backlight comes back, it is extremely dim for about 3 seconds, then off 
completely.
- To regain brightness, I have to set brightness to maximum, then turn off/on 
display backlight (by the Display Off button or xset command). Brightness is 
then stay as maximum again. For that reason I have had a key bound to set 
brightness to maximum.

With ACPI (sony-laptop) when it works:
- I could change brightness and used Display Off button and hadn't experienced 
such problem. Brightness could be set to minimum (1) without being afraid that 
the backlight will turn off automatically.

Can you list your laptop specs?. I couldn't find it on Google. Thanks.

[deleted comment]

dsdt table:

13.3", Core i7-620M/8Gb/Nvidia GF310M/500Gb/6250 wi-fi+wimax/bd-rw

lspci:

root@m-ws:/home/alexey# lspci 
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation Core Processor PCI Express x16 Root Port 
(rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series 
Chipset HECI Controller (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 05)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio (rev 05)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 1 (rev 05)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 2 (rev 05)
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 3 (rev 05)
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 4 (rev 05)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express 
Root Port 5 (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 
Enhanced Host Controller (rev 05)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface 
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port 
SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller 
(rev 05)
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series 
Chipset Thermal Subsystem (rev 05)
01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce 310M] (rev 
a2)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev 
a1)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N + WiMAX 6250 
(rev 35)
03:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller
03:00.1 System peripheral: Ricoh Co Ltd Memory Stick Host Controller
03:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller
03:00.4 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller
04:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet 
(rev c0)
ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
Generic Non-core Registers (rev 02)
ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture 
System Address Decoder (rev 02)
ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
ff:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
ff:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)

Since my graphics card is different (GeForce 330M) and this has been my first 
Sony laptop I can't say for sure. Although all laptops I've got didn't exhibit 
the same issues (changing terminals worked, backlight can be changed by 
hardware - it works right after POST) until this one. It would be great if 
someone with F series (or GF 330M) can test it.

hmm on this machine screen backlight not work after post.

> Can you elaborate on how a daemon will allow dynamic adjustment of maximum 
brightness?

In windows (where everything is likely controlled by one single piece of 
software) you can adjust the screen backlight with the Fn F5/F6 combos even 
with the autodimming enabled, both take into account the other when changing 
the brightness. To be able to do this some more code is needed. The 
als_threshold setting is present to allow some tuning, if necessary (the 
current default suits me fine but can't say this is true for all of you), but 
it's not intended for that purpose.
About the interrupt/event management, there are two reasonable ways:
- include the autodimming code in the driver (but it must chose and control the 
right backlight device, and might be rejected)
- write a daemon that manage all the vaio related acpi events (there a few 
others, like the HDD protection, but I plan to implement it later) and maybe 
some other stuff. It can eventually generate dbus events if necessary (is it?).
Regarding the GUI, I'd be glad to see someone working on that, it would be 
great :)
But the major step is to have a (almost) clear idea on how the HW is supposed 
to work and a decent driver layer. The ALS requires a fine grain regulation to 
allow minimal and smooth changes, I have not a clear idea how it should work on 
notebook different than mine, not yet, so I'm sticking with this right now.

> +ODD control

A cleaner bus disconnection is still lacking (but possible) but should work as 
well in the meantime.

> +als (can enable it and read data, kbd_light not based on als)

you need the sony-als.sh script I posted earlier, and the attached file (change 
the written path if necessary, depending on your distro).

> -touchpad control

I know, it use to fail here as well on my VPCS

> -screen backlight control (screen backlight control work withount 
sony-laptop, or with sony-laptop, but als_power must set to 0)

interesting... is the sony backlight device present in /sys/class/backlight/?

> the only instance I could change backlight via ACPI file was in a terminal 
with vaio-test3 patch applied

Ok, got it. The old sony controls are useless, only 8 steps available.

> Is acpi_backlight=sony the same as acpi_backlight=vendor?.

? It should allow to pick up the backlight device you desire to use. Is the 
string "brightness ignored, must be controlled by ACPI video driver" present in 
your logs?

> With nvidia_bl module: [...]

regardless the patch you use?

> With ACPI (sony-laptop) when it works:

you mean with the test3 patch?

> hmm on this machine screen backlight not work after post.

More info on this please :)

Thanks for your collaboration :)

> In windows (where everything is likely controlled by one single piece of 
software) you can adjust the screen backlight with the Fn F5/F6 combos even 
with the autodimming enabled, both take into account the other when changing 
the brightness. To be able to do this some more code is needed. The 
als_threshold setting is present to allow some tuning, if necessary (the 
current default suits me fine but can't say this is true for all of you), but 
it's not intended for that purpose.

From what you described, I think a relative auto dimming is what we need. 
User-controlled back light is stored in a separate variable and may be 
different from actual brightness (as is the case with brightness and 
actual_brightness?). In which case, actual brightness will vary based on the 
lighting. For example
- actual_brightness = brightness+offset
- offset ranges from (say) -25% to +25%, that will be mapped to 0% and 100% 
ambient light.

I think it should work nicely on all use-cases (backlight changes based on 
environment while user is still in control). Although we need to decide where 
to store that variable (driver/script/daemon), storing outside the driver seems 
obvious but I might be wrong. The script we've got should require minimal 
changes for it to work.

> include the autodimming code in the driver (but it must chose and control the 
right backlight device, and might be rejected)

I agree, seems that isn't the right place. If we can do it in userspace then we 
should.

> write a daemon that manage all the vaio related acpi events (there a few 
others, like the HDD protection, but I plan to implement it later) and maybe 
some other stuff. It can eventually generate dbus events if necessary (is it?).

I'll give it a shot. At first the daemon will only support ALS features.

> Regarding the GUI, I'd be glad to see someone working on that, it would be 
great :)

Can you the list of features in VAIO Control Centre that you need the most?. 
I'll try implementing it with the keyboard backlight, battery limiter and ALS 
stuff first.

> The ALS requires a fine grain regulation to allow minimal and smooth changes

Do you mean we have to update brightness gradually?. What is the reason that we 
can't set to target brightness directly?.

>> Is acpi_backlight=sony the same as acpi_backlight=vendor?.
> ? It should allow to pick up the backlight device you desire to use. Is the 
string "brightness ignored, must be controlled by ACPI video driver" present in 
your logs?

The string is present in the log. Do I still need to pass that parameter to the 
kernel?.

>> With nvidia_bl module: [...]
> regardless the patch you use?

True, the two modules don't clash at anything, as far as I can tell.

>> With ACPI (sony-laptop) when it works:
> you mean with the test3 patch?

Yes, although I haven't tested vaio-test6 in the same condition. 
full-2.6.37.patch didn't work.

> interesting... is the sony backlight device present in /sys/class/backlight/?
no this device is not present.

> hmm on this machine screen backlight not work after post.
> More info on this please :)

If OS is not loaded screen backlight control not work.
On linux OS, need to start X with nvidia proprietary driver. and this line in 
xorg.conf (device section): Option          "RegistryDwords"        
"EnableBrightnessControl=1"
and hal fdi must have hack.
on another way screen backlight set to maximum and not controlled any way.

logs for sony-backlight (test6 on 2.6.37.2):