Sony-Laptop Module Support #6

GoogleCodeExporter · Apr 1, 2015

The Vaio comes with a Windows utility for changing the keyboard backlight 
settings. There is currently no way to access these settings on Linux.

Original issue reported on code.google.com by Jason.Donenfeld on 10 Feb 2010 at 10:10

GoogleCodeExporter · Apr 1, 2015

Original comment by Jason.Donenfeld on 10 Feb 2010 at 10:11

Added labels: Priority-Low
Removed labels: Priority-Medium

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by mruf...@gmail.com on 25 Feb 2010 at 6:32

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by mar.ro...@gmail.com on 29 May 2010 at 4:31

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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?

Original comment by c.ra...@gmail.com on 31 May 2010 at 12:10

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by MFalal...@gmail.com on 1 Jul 2010 at 5:21

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by samini...@gmail.com on 6 Sep 2010 at 3:36

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Same issue in VPCS120FL

Original comment by suga92 on 25 Sep 2010 at 7:26

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by AlKo...@gmail.com on 14 Dec 2010 at 9:26

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter · Apr 1, 2015

Same issue on VPCS12C5E

Original comment by alec...@toshiba-connect.it on 15 Dec 2010 at 1:10

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by AlKo...@gmail.com on 15 Dec 2010 at 2:57

Added labels: ****
Removed labels: ****

Attachments:

kbd_lit_v0001.tar.bz2

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by dheraul...@gmail.com on 21 Dec 2010 at 9:27

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by AlKo...@gmail.com on 23 Dec 2010 at 10:03

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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!

Original comment by AlKo...@gmail.com on 23 Dec 2010 at 10:08

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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 ?

Original comment by dheraul...@gmail.com on 23 Dec 2010 at 8:36

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by AlKo...@gmail.com on 25 Dec 2010 at 3:09

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

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?

Original comment by alec...@toshiba-connect.it on 26 Jan 2011 at 12:02

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by shibo...@gmail.com on 27 Jan 2011 at 11:30

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

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).

Original comment by AlKo...@gmail.com on 27 Jan 2011 at 11:31

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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!

Original comment by alec...@toshiba-connect.it on 28 Jan 2011 at 10:46

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 2 Feb 2011 at 9:18

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

watch -n0 ectool

please give me output of these commands:

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

Original comment by AlKo...@gmail.com on 2 Feb 2011 at 8:21

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 3 Feb 2011 at 3:16

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

@ 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!

Original comment by anthony....@googlemail.com on 6 Feb 2011 at 9:08

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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!

Original comment by ma...@absence.it on 8 Feb 2011 at 5:30

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 8 Feb 2011 at 6:00

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter · Apr 1, 2015

Thank you for your quick reply. I just had a really quick look but it seems 
that stuff like the ALS sensor, the keyboard backlight and the battery charge 
limiter can be controlled in the same way I do with my vpcs. Please, have some 
more patience until the code is ready, I might attach here a patch later, for 
testing purpose only.
Thanks.

Original comment by ma...@absence.it on 8 Feb 2011 at 7:12

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

PS: your exact VPCF model?

Original comment by ma...@absence.it on 8 Feb 2011 at 7:13

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

The exact name is VPCF127FX, which I suppose F is the series, 127F the model 
name and X being black.

It is very good to know that this can be fixed. I have been battling with the 
backlight every once in a while,

Thanks.

Original comment by vanhtu1...@gmail.com on 8 Feb 2011 at 7:29

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

I would love to give it a try if you will kindly provide a patch for kernel 
2.6.36.3 or to the specific files changed :) .

Original comment by vanhtu1...@gmail.com on 8 Feb 2011 at 7:32

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Hello, can you confirm that under linux the keyboard backlight default settings 
are: on, 10 sec timeout (+ fade out)? A patch is coming...
And may I ask you to perform a couple of tests with the ALS as soon as I 
prepare the code? Thanks

Original comment by ma...@absence.it on 10 Feb 2011 at 8:12

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

It is precisely 15 seconds since I press a key (+keyboard lights up) until it 
completely fades out. When a key is pressed, it lights up at medium brightness 
for 1 sec, stays lit up at maximum level for 13 secs then fades out in 1 sec.

Original comment by vanhtu1...@gmail.com on 10 Feb 2011 at 8:26

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Does the Vaio Control Center show four possible settings (10 secs, 30 secs, 60 
secs, nerver)? Is it something like this: 
http://absence.it/vaio-acpi/VPCS-ves_vcc/tastiera.png ?
I'm attaching the patch (apply against 2.6.36.3) with some more stuff you have 
to test as well. Ok, you should be now able to see in 
/sys/device/platform/sony-laptop these files:
- kbd_backlight: 1 backlight enabled on key pressure, 0 disabled (default on 
module loading)
- kbd_backlight_timeout: 0 -> 10 secs (default), 1 -> 30 secs, 2 -> 60 secs, 3 
-> always on
- battery_charge_limiter: 0 disabled (full 100% charge), 1 limit at 80%, 2 
limit at 50%
- touchpad: read -> touchpad status, write -> enable (1)/ disable (0).
The touchpad control use to fail on my Vaio S, but might work for you, please 
let me know (about the status changes too). You could also check whether the 
wireless interfaces on/off status is preserved across reboot/power off.
After trying all this stuff please attach a "dmesg > dmesg.log" and/or the 
kern.log file. Feedback and testers are very welcome.
I'm going to provide another patch for the ALS in the next days. See you soon.

Original comment by ma...@absence.it on 11 Feb 2011 at 11:55

Added labels: ****
Removed labels: ****

Attachments:

vaio-test1.patch

GoogleCodeExporter · Apr 1, 2015

I couldn't recall how it looked like since I don't have Windows on my laptop 
anymore, but it's very likely to be the same as yours. Although I measured the 
time with a stopwatch so 15 secs were accurate.

The patch applied successfully against drivers/platform/x86/sony-laptop.c , but 
gave errors when I compiled it:
-------------
$ make -j12 SHELL=/bin/bash M=drivers/platform/x86/
  CC [M]  drivers/platform/x86/sony-laptop.o
drivers/platform/x86/sony-laptop.c:980:10: error: 
‘SONYPI_EVENT_VENDOR_PRESSED’ undeclared here (not in a function)
drivers/platform/x86/sony-laptop.c:2109:10: error: ‘SONYPI_EVENT_IGNORE’ 
undeclared here (not in a function)
drivers/platform/x86/sony-laptop.c:2109:2: error: initializer element is not 
constant
drivers/platform/x86/sony-laptop.c:2109:2: error: (near initialization for 
‘sonypi_wlessev[0].event’)
drivers/platform/x86/sony-laptop.c:2110:2: error: initializer element is not 
constant
drivers/platform/x86/sony-laptop.c:2110:2: error: (near initialization for 
‘sonypi_wlessev[1].event’)
drivers/platform/x86/sony-laptop.c:1473:13: warning: 
‘sony_nc_optdev_update’ defined but not used
drivers/platform/x86/sony-laptop.c:1523:12: warning: ‘sony_nc_optdev_setup’ 
defined but not used
drivers/platform/x86/sony-laptop.c:1552:12: warning: 
‘sony_nc_optdev_cleanup’ defined but not used
make[1]: *** [drivers/platform/x86/sony-laptop.o] Error 1
make: *** [_module_drivers/platform/x86] Error 2
-------------

After reverse-applied the patch, I could compile the module again. One thing to 
note is that applying the patch showed a lot of offsets warning (Hunk #64 
succeeded at 3284 (offset 4 lines), etc.) . Can you make sure that this is for 
2.6.36.3?. Running 2.6.37 is not an option for me since I've had a lot of 
stability problems with it.

Thank you

Original comment by vanhtu1...@gmail.com on 11 Feb 2011 at 12:39

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

I added these two lines to sonypi.h and it compiled well, I'm testing the 
module at the moment.

#define SONYPI_EVENT_VENDOR_PRESSED             73
#define SONYPI_EVENT_IGNORE                     74

Original comment by vanhtu1...@gmail.com on 11 Feb 2011 at 1:04

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Thank you!. I have tested all the new settings and they worked great, took 
effect immediately. The touchpad could be enabled/disabled without problem. 
Finally the wait is over (bar the ALS issue :) .

I'm reluctant to reboot (what I did was reloading the module) so I cannot check 
if wifi state will be consistent at the moment. But I am sure others will be 
eager to verify that for you. Here are the relevant logs when I loaded the old 
module and the patched one:
-----------
Feb 11 12:54:55 foobar dhclient: DHCPREQUEST on wlan0 to 1.1.1.1 port 67
Feb 11 12:54:55 foobar dhclient: DHCPACK from 1.1.1.1
Feb 11 12:54:55 foobar dhclient: bound to 10.32.65.95 -- renewal in 237 seconds.
Feb 11 12:57:14 foobar kernel: sony-laptop: Sony Notebook Control Driver v0.6.
Feb 11 12:57:14 foobar NetworkManager[5809]: <info> found WiFi radio killswitch 
rfkill15 (at 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/SNY5001:00/rfkill/rfki
ll15) (driver Sony Notebook Control Driver)
Feb 11 12:57:14 foobar kernel: input: Sony Vaio Keys as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/SNY5001:00/input/input48
Feb 11 12:57:14 foobar kernel: input: Sony Vaio Jogdial as 
/devices/virtual/input/input49
Feb 11 12:57:16 foobar blueman-mechanism: Starting blueman-mechanism
Feb 11 12:57:46 foobar blueman-mechanism: Exiting
Feb 11 12:58:53 foobar dhclient: DHCPREQUEST on wlan0 to 1.1.1.1 port 67
Feb 11 12:58:53 foobar dhclient: DHCPACK from 1.1.1.1
Feb 11 12:58:53 foobar dhclient: bound to 10.32.65.95 -- renewal in 253 seconds.
Feb 11 13:02:12 foobar NetworkManager[5809]: <info> radio killswitch 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/SNY5001:00/rfkill/rfki
ll15 disappeared
Feb 11 13:02:27 foobar kernel: sony-laptop: Sony Notebook Control Driver v0.6.
Feb 11 13:02:27 foobar NetworkManager[5809]: <info> found WiFi radio killswitch 
rfkill17 (at 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/SNY5001:00/rfkill/rfki
ll17) (driver Sony Notebook Control Driver)
Feb 11 13:02:27 foobar kernel: input: Sony Vaio Keys as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/SNY5001:00/input/input50
Feb 11 13:02:27 foobar kernel: input: Sony Vaio Jogdial as 
/devices/virtual/input/input51
Feb 11 13:03:06 foobar dhclient: DHCPREQUEST on wlan0 to 1.1.1.1 port 67
Feb 11 13:03:06 foobar dhclient: DHCPACK from 1.1.1.1
Feb 11 13:03:06 foobar dhclient: bound to 10.32.65.95 -- renewal in 300 seconds.
Feb 11 13:03:09 foobar -- MARK --
-----------

I hope to be the first to test the ALS patch. Thanks.

Original comment by vanhtu1...@gmail.com on 11 Feb 2011 at 1:14

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Yeah, I'm sorry, I forgot about the header file changes. A new patch is 
attached.
I also forgot to tell you to load the sony-laptop module with the "debug=1" 
parameter, otherwise the log files are useless. I'd like to see whether the 
kernel complains about the touchpad state change. Thanks

Original comment by ma...@absence.it on 11 Feb 2011 at 8:16

Added labels: ****
Removed labels: ****

Attachments:

vaio-test2.patch

GoogleCodeExporter · Apr 1, 2015

Here is the relevant lines in my everything.log: http://pastebin.com/DLkVMcWE . 
The patch compiled and worked fine and it seemed there were no errors reported 
about the touchpad.

Thanks

Original comment by vanhtu1...@gmail.com on 11 Feb 2011 at 8:37

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Thank you very much :) It looks like today I can't help but making mistakes 
(the battery_charge_limiter was reporting incorrect values), the right patch 
attached.
Ok, good, but I have to ask you: when disabled, does the touchpad preserve its 
state when exiting from the suspend or hibernation mode? And... do you remember 
whether it was possible, in Windows, to power down the DVD drive? Is this 
feature available on this notebook?

Original comment by ma...@absence.it on 11 Feb 2011 at 10:02

Added labels: ****
Removed labels: ****

Attachments:

vaio-test3.patch

GoogleCodeExporter · Apr 1, 2015

The battery_charge_limiter reported the correct value for me (1) but that might 
be a coincidence. The touchpad remained disabled when I suspended and resumed 
the laptop, enabling it worked fine after that.

I'm not aware that you can power down the DVD drive. I made a search for that 
feature in Sony laptops without success, so I think it is unlikely (or it was 
hidden for access by software). What I have been doing is blacklisting sr_mod 
in the hopes that would save some power.

I did a reboot today and it looked like my Wifi stayed off at boot up (it was 
off when restarted).

Original comment by vanhtu1...@gmail.com on 12 Feb 2011 at 12:59

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

An unrelated issue: Sometimes around kernel 2.6.36 to 2.6.37 I experienced odd 
USB errors for the built-in Bluetooth USB device:
---
usb 1-1.6: device descriptor read/8, error -110
usb 1-1.6: device descriptor read/8, error -110
hub 1-1:1.0: unable to enumerate USB device on port 6
(6-9 lines more)
---

It only happens at boot up and other USB devices are not functional. The errors 
happen between 2 to 3 minutes and stopped. Afterwards, all USB devices work. 
Except for the bluetooth that I have to disable, enable, disable and enable 
again to make it work.

I'm not sure where to report this issue so I'm sorry if this is not the right 
place.

Original comment by vanhtu1...@gmail.com on 12 Feb 2011 at 1:00

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Ok, very good :)
About the DVD device, some portable Vaios (such as the S and Z series) have the 
ability to turn the drive off, while some others have not (the E and, I now 
suppose [1], the F series). The patch applies to the S and Z series as well, if 
someone cares.
Regarding the USB issue, have a look at bugzilla.kernel.org, maybe it's an 
already known issue.

[1] and the DSDT you provided seems to prove it.

Original comment by ma...@absence.it on 12 Feb 2011 at 8:30

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Hello again. Even though an ALS related issue is already present at this site, 
I'm posting here the patch for testing the light sensor (it also includes a new 
fine grain lcd backlight control). Apply against a clean 2.6.36.3. Load the 
module with the debug=1 parameter and please attach a "dmesg > dmesg.log" 
and/or the kern.log file after the following tests.
Once done, I need some feedback, I need to understand whether the ALS present 
on your vaio acts like the one I have on mine.
So, follow:
- echo 1 > /sys/device/platform/sony-laptop/als_power
- echo 3 > /sys/device/platform/sony-laptop/als_interrupt_enable
- cat /sys/device/platform/sony-laptop/als_interrupt_enable
tell me whether you see 3 or 0.
Then:
- start acpi_listen in a new terminal
- echo 1 > /sys/device/platform/sony-laptop/als_lsen
- echo 1 > /sys/device/platform/sony-laptop/als_interrupt_enable
- cat /sys/device/platform/sony-laptop/als_interrupt_enable
tell me whether you read 1 or 0, the event shown by acpi_listen and how many 
times it's been notified, and whether you can change the backlight through the 
Fn-F5/F6 combos. Please provide your ALS model too (read als_model). It should 
be enough at the moment.

Original comment by ma...@absence.it on 21 Feb 2011 at 12:30

Added labels: ****
Removed labels: ****

Attachments:

full.patch

GoogleCodeExporter · Apr 1, 2015

I have moved on to kernel 2.6.37.1 as it seems to have fixed the USB issue 
(among others). Your latest patch (along with vaio-test3.patch) can apply 
cleanly against 2.6.37.1 if the hunk at 3573 is removed. Just FYI.

I'm testing the patch and will report soon.

Original comment by vanhtu1...@gmail.com on 21 Feb 2011 at 1:13

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Here is the relevant log: http://tinypaste.com/e4446

als_power was already set to 1 .
als_interrupt_enable was 0, I changed it to 3, but it remained 0 afterward.

I have removed support for the deprecated /proc/acpi in the kernel so I cannot 
run acpid (I haven't used acpid for quite a while). If there is other way to 
listen for event, I'll be happy to test.

als_lsen was 2560 .
als_interrupt_enable was 0, I changed it to 1, but it remained 0 afterward.

I can change the backlight with nvidia_bl and have bound the keys to Fn-F5/F6, 
although nvidia_bl exposes it through 
/sys/class/backlight/nvidia_backlight/brightness so I am not sure if your 
method is the same.

als_model says "Unknown ALS model" :( . Is there a kernel module that I need to 
enable? (I disabled most ALS devices in the config).

Thanks

Original comment by vanhtu1...@gmail.com on 21 Feb 2011 at 1:37

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

I found that TSL2550 is in the kernel config, but TSL256[0-3] is in staging 
section. Do you suppose enabling those modules will allow sony-laptop to 
control it?.

The ALS device name seems to be hard-coded in a look up table in the patch so 
it looks like enabling the modules won't do anything. But I might be wrong.

Update: I have looked at the files under /sys/class/backlight/ . There are 
acpi_video0, nvidia_backlight and sony . nvidia_backlight shows the correct 
values when I change brightness, but the files in the other two directories 
remained the same:
$ ls /sys/class/backlight/sony/
actual_brightness  bl_power  brightness  max_brightness  power  subsystem  
uevent
$ cat /sys/class/backlight/sony/*
255
0
255
255
cat: /sys/class/backlight/sony/power: Is a directory
cat: /sys/class/backlight/sony/subsystem: Is a directory

$ ls /sys/class/backlight/nvidia_backlight/
actual_brightness  bl_power  brightness  max_brightness  power  subsystem  
uevent
$ cat /sys/class/backlight/nvidia_backlight/*
2300
0
2300
3968
cat: /sys/class/backlight/nvidia_backlight/power: Is a directory
cat: /sys/class/backlight/nvidia_backlight/subsystem: Is a directory

Original comment by vanhtu1...@gmail.com on 21 Feb 2011 at 2:05

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Please provide further logs, I can't see any of your tries with the als_* 
files. The acpi event (caused by a meaningful light intensity change) can be 
seen in your logs too, it was easier to be identified in that way, but it's not 
an issue (but complete logs are necessary).

> als_interrupt_enable was 0, I changed it to 3, but it remained 0 afterward.
> als_interrupt_enable was 0, I changed it to 1, but it remained 0 afterward.

Both OK.

> als_lsen was 2560
> als_model says "Unknown ALS model"

weird...

About the screen backlight controls, what does 
"/sys/class/backlight/nvidia_backlight/max_brightness" says?

Ok, we'd better not to poke at the als settings at the moment, let me see a 
"cat als_*" and the dmesg log after that. To see the relevant part only, you 
can call "dmesg -c" before reading the values (and dmesg afterward, as usual).

About the other driver in the kernel tree (the TSL2550 is a totally different 
ALS), it seems that the ALS is directly connected to the Embedded Controller so 
it should not work, but you can try and report on success.

Original comment by ma...@absence.it on 21 Feb 2011 at 2:42

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

You are right about the incomplete log, after issuing the echos there were 
additional logs but I already pasted the output after modprobe so didn't think 
it was important, sorry.

Commands output: http://tinypaste.com/28de6
Here is the dmesg after all commands: http://tinypaste.com/050245
I also changed the brightness up/down using the function keys, which adjusts 
/sys/class/backlight/nvidia_backlight/brightness by 200 each time.


$ cat /sys/class/backlight/nvidia_backlight/max_brightness 
3968
Please note that max_brightness depends on the max_level module parameter, in 
my system nvidia_bl is loaded with: options nvidia_bl max_level=127000 shift=5 
. I got these values by trial and error so they may not make much sense.

Original comment by vanhtu1...@gmail.com on 21 Feb 2011 at 5:16

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

With full.patch my system failed to resume from susoend twice. I am almost 
certain of it since I tried to suspend right after booting up and it failed to 
resume (backlight turned on but display stayed black, Magic SysRq didn't work). 
Recompiling the module with vaio-test3.patch allowed the system to resume as 
normal.

Original comment by vanhtu1...@gmail.com on 21 Feb 2011 at 5:20

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Thank you for your logs, this time are fine. Looking at both the module output 
and your DSDT I've found the reason of those weird values: in your laptop the 
output returned by the ACPI method is the input buffer partially overwritten 
with the values we are looking for, so a few bits/bytes of that buffer must be 
ignored (while on mine a new clean buffer is returned). I'm solving this right 
now, but before allowing you to try another patch, could you please cat any 
other file present in /sys/device/platform/sony-laptop so that I can verify the 
issue is not present elsewhere? Just dmesg -c, cat * and dmesg, then cut & 
paste.
Thank you for reporting the suspend issue as well, at the moment I have no 
clues so if you experience that problem again please provide your logs (you can 
drop me an email if you prefer).

Original comment by ma...@absence.it on 22 Feb 2011 at 9:43

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

Sorry for the late reply, here is the logs anyway :) (with vaio-test3.patch): 
http://tinypaste.com/6dffd5

The logs were from these commands:

$ sudo rmmod -v sony_laptop
rmmod sony_laptop, wait=no
$ sudo modprobe -v sony-laptop debug=1
insmod /lib/modules/2.6.37.1-2/kernel/drivers/platform/x86/sony-laptop.ko 
debug=1
$ cd /sys/devices/platform/sony-laptop/
$ for f in *; do echo FILE: $f; cat $f; done 
FILE: battery_charge_limiter
2
FILE: driver
cat: driver: Is a directory
FILE: handles
0x0101 0x0000 0x0100 0x0137 0x0124 0x013a 0x0139 0x0140 0x0103 0x0136 0x011d 
0x0114 0x0000 0x0000 0x0105 0x0122 
FILE: kbd_backlight
0
FILE: kbd_backlight_timeout
0
FILE: modalias
platform:sony-laptop
FILE: power
cat: power: Is a directory
FILE: subsystem
cat: subsystem: Is a directory
FILE: touchpad
1
FILE: uevent
DRIVER=sony-laptop
MODALIAS=platform:sony-laptop

I do suspends frequently and with the vanilla kernel (as well as with 
vaio-test3 patch) there have been no problems.

Thanks.

Original comment by vanhtu1...@gmail.com on 22 Feb 2011 at 3:18

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

here is the new patch for .37.1
ok, now you can play with the sensor (for autodimming a control daemon/script 
is still lacking at the moment, but the difficult part is over):
- als_ch0, als_ch1: raw value for visible+IR light (ch0) and IR only light (ch1)
- als_illuminance: illuminance in lux, not avaiable... not yet even though is 
necessary for autodimming.
- als_notify: enable or disable the light change notification event generation 
(it looks like 0x03 is generated on your notebook) when, in turn, an interrupt 
is generated by the sensor. BTW, could you please verify whether your Fn-F5/F6 
combo is working with it enabled before/after an interrupt is asserted?
- als_timings: ADC integration time (2 is usually fine)
- als_interrupt_enable: 1 enable the interrupt generation on light change, 2 an 
interrupt is immediately generated (for testing purpose only... it doesn't seem 
to work on your notebook, does it?)
- als_power: power on, power off the sensor
- als_ev_reason: 0 no event reason, 1 unknown event reason, 2 unknown event 
reason(if you discover something interesting about this value let me know)
- als_interrupt_persistence: integration cycles before considering the light 
change meaningful and asserting the interrupt.
- als_threshold_high, als_threshold_low: upper limit, "If the value generated 
by channel 0 crosses below or is equal to the low threshold specified, an 
interrupt is asserted", If the value generated by channel 0 crosses
above the high threshold specified, an interrupt is asserted" (meaningful light 
change,)
- als_gain: 0 x1 gain, 1 x16 gain.

This patch is just for testing, some of these files will probably change in the 
future, or might be absent.
Now the interesting part is how you control your screen backlight, it seems 
that you use nvidia_backlight (right?), but what about acpi_video0? Could you 
please verify that controls in "sony" are not working at all?

Original comment by ma...@absence.it on 22 Feb 2011 at 4:03

Added labels: ****
Removed labels: ****

Attachments:

vaio-test4.patch

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

I'm testing the patch, will update the report gradually.

The brightness control with Fn keys does not work eventhough I set als_notify 
to 1. Here is the relevant log when I pressed Fn-F6 (brightness up) 3 times. 
The first 2 times were without the key bound to the brightness change script, 
the 3rd time was with the script (using nvidia_backlight sysfs file): 
http://tinypaste.com/ce173b

als_threshold_high was set to 30, als_threshold_low was set to 10 since in my 
room als_ch0 ranged from 0 to 40 .

als_ch{0,1} changed their values as expected.
als_illuminance = 'not implemented'
als_notify was set to 1 and remained 1
als_timings = 2
als_interrupt_enable did not make the sensor generate events with it set to 
either 1 or 2 when I covered my hand over the sensor.
als_power = 1, I guessed that's how it was supposed to be.
als_ev_reason = 1
als_interrupt_persistence = 0
als_gain = 0

$ for f in /sys/class/backlight/acpi_video0/*; do echo FILE: $f; cat $f; done
FILE: /sys/class/backlight/acpi_video0/actual_brightness
8
FILE: /sys/class/backlight/acpi_video0/bl_power
0
FILE: /sys/class/backlight/acpi_video0/brightness
8
FILE: /sys/class/backlight/acpi_video0/max_brightness
8
FILE: /sys/class/backlight/acpi_video0/uevent

Interestingly, there was no longer a directory named 'sony'. As you can see the 
values seemed to be set to default. Although the brightness could be changed by 
nvidia_backlight, the change was not reflected in the files. Attempts to set 
the values in these files manually failed.

Original comment by vanhtu1...@gmail.com on 22 Feb 2011 at 4:44

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

> ok, now you can play with the sensor (for autodimming a control daemon/script 
is still lacking at the moment, but the difficult part is over):

Do you mean eventually we will need a script to control the keyboard backlight 
anyway?. If so then I may as well start writing one.

Edit: If the hardware interrupt is intercepted by the driver then I suppose the 
driver should handle changing the backlight itself?.

Original comment by vanhtu1...@gmail.com on 22 Feb 2011 at 5:00

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

On our notebooks, using ACPI, it works this way (more or less):
Let's suppose that gain and timing settings are fine for the current light 
ambient condition (they somehow resemble the exposure settings for a camera). 
Now, we want to be notified if a significant light change occurs (and persists 
for a certain period of time), for example in the +/-10% range, respect to the 
current value. We read ch0 and set threshold_high and threshold_low 
accordingly, then enable the interrupt (generated on threshold crossing). When 
interrupt is asserted by the sensor,it is immediately cleared by the Embedded 
Controller (that piece of hw that controls all the vaio specific function), and 
if als_notify is set to 1 we also receive an acpi event (otherwise we are not 
aware of the light change). Every time we receive this event we should set new 
thresholds and change the screen (and maybe the keyboard) backlight settings.
The idea is to write a script or, even better, a daemon that do this last step 
in userspace (but it might control some other features, very much like the Vaio 
Event Service for windows), read the als values (illuminance included), set new 
als values (basically new thresholds) and set the proper backlight value (for 
example writing in /sys/class/backlight/sony/brightness). So at the moment the 
patch itself is quite useless, but you can play a little bit with it and report 
whether everything is working as it is supposed to.
That said... my laptop have no discrete graphics, I have no idea about the 
backlight controls for notebooks equipped with nvidia gpus (could you please 
explain to me a little bit how it works?), but I'd say it's a bit strange for 
you to have all those backlight devices... BTW, the new backlight controls 
should be the cause of your suspend issue, is it still present?

Original comment by ma...@absence.it on 22 Feb 2011 at 5:44

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Thanks for the information. I'm not aware of any solution for the display 
backlight problem. It seems like there are weird interaction issues in most 
Sony Vaio laptops with discrete graphics. Even though I got most things working 
now, when switching from X to any terminals they are blank.

So it looks like if we can get the display backlight under control by ACPI, 
we'll be in a position to write such a daemon. For now, though, I can make the 
keyboard backlight turn on and off depending on environment's lighting with a 
script so that is a good step forward.

As far as I can tell the content of sony and acpi_video0 in my system are 
identical. /sys/class/backlight/nvidia_backlight is created by the nvidia_bl 
module. nvidia_bl controls the backlight by writing to the GPU's register. I 
guess that's why there is no way to control the backlight without appropriate 
software. The Fn keys don't work right away at boot up, while most laptops I've 
got can.

I'd rather not put my data at risk :) but I will try to suspend the system in 
due time.

Original comment by vanhtu1...@gmail.com on 22 Feb 2011 at 6:25

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Do you plan to have this merged to mainline kernel?.

I tested the patch again but in my laptop there was no ACPI events generated 
(thresholds were set appropriately as above). Is this working in your laptop?.

Original comment by vanhtu1...@gmail.com on 23 Feb 2011 at 2:03

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Sure, the code will be pushed upstream as soon as it is ready for the inclusion 
(but currently it's a long way to go for the ALS I'm afraid, there is still a 
lot of work to be done).

About the event, in your logs I see:

sony-laptop: called SN07 with 0x10860503 (result: 0x10860501)  <-- interrupt 
enabled
sony-laptop: found handle 0x0100 (offset: 0x02)                <-- event 
decoding
[...]
sony-laptop: sony_nc_notify, event: 0x03                       <-- event 
notified
Can you confirm this event number?

Remember, the ALS must be powered on, then enable the als_notify and the 
als_interrupt_enable; if you have the thresholds set to 0 it should be 
generated immediately, otherwise a light change is necessary (BTW, you might 
try once again the forced interrupt generation writing 2 to 
als_interrupt_enable).

I spent a few minutes to write a userspace tool for calculating lux (attached) 
as I will need it later for testing, you might use it as a temporary solution 
for autodimming, if you have some scripting skills:
- place sony-als in /etc/acpi/events/ (or similar depending on your distro)
- write your own /etc/acpi/sony-als.sh script, where you use this tool for 
reading the lux value and set the backlight accordingly, then set new threshold 
limits and enable again the interrupt.
- restart the acpid daemon

You should try to understand which backlight device really controls the lcd 
screen (only nvidia_backlight?). Is "sony" still no longer present? Does 
changing the brightness value in "sony" affect the sceen backlight? And what 
about the "brightness change script" you mentioned in one of your previous 
posts? What it is?

Original comment by ma...@absence.it on 23 Feb 2011 at 4:02

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter · Apr 1, 2015

The event number is correct, although it fired immediately no matter what the 
current thresholds are:
- In my room als_ch0 = 40
- als_threshold_high was set to 40
- als_threshold_low was set to 80 (and it stayed as 20, the value is 1/4 of the 
input for all values I've tried, e.g. if I set it to 20, it changed to 5)
- als_interrupt_enabled is cleared to 0 after the event (from what you 
described, it is expected).

I pasted the commands and their output here: http://tinypaste.com/d0047

I don't use acpid but I will see how to handle ACPI events without it. I'm 
running Arch Linux.

Only nvidia_backlight controls the backlight. I cannot modify any of the values 
in acpi_video0 (got "Permission Denied"). With the latest patch "sony" is no 
longer present in /sys/class/backlight. In full.patch it was, but I couldn't 
modify it either way.

The brightness change script adjusts the current brightness by the requested 
amount and limits it within a range. It writes to 
/sys/class/backlight/nvidia_backlight/brightness . The hard-coded limits only 
really work if nvidia_bl is loaded with "max_level=127000 shift=5" .

Original comment by vanhtu1...@gmail.com on 23 Feb 2011 at 6:19

Added labels: ****
Removed labels: ****

Attachments:

adjust-brightness.sh

GoogleCodeExporter · Apr 1, 2015

I wrote a script to automatically reset thresholds and interrupt but it was 
never called. Can you check if it is working in your system?. I'm using the 
latest acpid 2.0.8 as it has supports for netlink and input layer.

Original comment by vanhtu1...@gmail.com on 23 Feb 2011 at 7:51

Added labels: ****
Removed labels: ****

Attachments:

sony-als.sh

GoogleCodeExporter · Apr 1, 2015

Thank you for noticing the bug: my fault when converting to hex, change the 
line number 1508 from

    ret1 = sony_call_snc_handle(abc_handle, ((value & 0x00ff) << 0x16) | 0x820500, &result1);

to

    ret1 = sony_call_snc_handle(abc_handle, ((value & 0x00ff) << 0x18) | 0x820500, &result1);

About your script, you don't need to pharse the event if the file I attached 
(sony-als) is in the right place, just calculate a new screen backlight value 
based on the lux value, then set new threshold limits (I suggest +/-15% of the 
current ch0 value) and enable the interrupt generation.

Original comment by ma...@absence.it on 24 Feb 2011 at 10:07

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

I updated the script and the patch as suggested. The problem is I cannot get 
acpid to call sony-als.sh . I tested the default anything event handler and it 
worked. But sony-als wouldn't work even if 'anything' is removed.

Update: I used acpi_listen to check for sony/button event but it did not show 
any although als_interrupt_enable is set to 1 then automatically cleared. 
als_notify, als_power are 1 . Other events such as lid and button are working.

Original comment by vanhtu1...@gmail.com on 24 Feb 2011 at 10:32

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Sorry, I don't know why it doesn't work on your system, but I can assure the 
event is forwarded to the ACPI bus, so it's not a problem with the driver. The 
device is sony/hotkey SNC, look for that and append the right event number. It 
works here.
Ok, the driver it's a mess at the moment, needs lots of improvements and code 
cleaning, but it's fully working now, so I'm attaching new patches. If you 
notice something weird please let me know.

Original comment by ma...@absence.it on 25 Feb 2011 at 12:26

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter · Apr 1, 2015

I tested the full-2.6.37.patch again but it still doesn't work. Given that 
als_interrupt fired correctly when als_ch0 exceeded thresholds, I'll just have 
to assume that acpid 2.x works differently from the 1.x, or it does not fully 
support the sysfs interface (/proc/acpi/events does not exist in my kernel).

Here is the command output log: http://tinypaste.com/1d78b
Here is the dmesg output log: http://tinypaste.com/87037 (I tested ACPI by 
pressing power button once, but it worked with brightness changes and other 
buttons)

If it helps, I attached the updated sony-als.sh , you can use it if ACPI works 
for you. You should see the Illumination changed in the kernel log when 
brightness is changed by 15%.

If there is anything else I can test, please tell.

Original comment by vanhtu1...@gmail.com on 25 Feb 2011 at 2:44

Added labels: ****
Removed labels: ****

Attachments:

sony-als.sh

GoogleCodeExporter · Apr 1, 2015

What I have now is a script that loops in 1s interval and checks for 
als_interrupt.

I plan to write a daemon that looks for changes in als_interrupt using the file 
notification API. Marco, can you tell me if userspace application can catch the 
interrupt emitted by the sensor, I am not familiar with it. If not, is checking 
for als_interrupt a good way to do it?. Not everyone is using acpid and 
/proc/acpi/events is being deprecated.

Original comment by vanhtu1...@gmail.com on 25 Feb 2011 at 2:48

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Hi, acpid requires /proc/acpi/events, so as a temporary solution you compile 
your kernel with it enabled. No one but the EC can see the interrupt, we 
instead receive an acpi notification if als_notify is enabled. I don't know 
about the "file notification API", but as soon as the interrupt is cleared by 
the EC (due to an interrupt generated by the ALS) als_interrupt shows zero when 
reading, but you have to read it! So you need polling, which is not a good 
solution. Use acpid, will investigate after the driver is done. Have patience.

Original comment by ma...@absence.it on 26 Feb 2011 at 11:24

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Unfortunately with the latest patch the suspend problem still presents on my 
system. Resume will works as long as sony-laptop is unpatched or patched with 
vaio-test3.patch (no matter how many times I reloaded the module).

acpid 2.0.8 supports the sysfs interface and it worked with all the buttons 
I've tried (PROG{1-3}, PWR, lid events, etc.) . The notification API I intend 
to use is fanotify. As far as I can tell, it is the latest (best?) notification 
facility and doesn't require polling from the programmer's point of view.

If I can instead catch ACPI events as how acpid works then that would be a 
happy solution. In the mean time, I'll try to push out a demo that uses 
fanotify.

Original comment by vanhtu1...@gmail.com on 26 Feb 2011 at 3:27

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

I need your logs to investigate the resume issue.
The "notification API" won't work, please enable the deprecated 
/proc/acpi/event instead and check whether it works.

Original comment by ma...@absence.it on 27 Feb 2011 at 2:18

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Here is the log with the failed resume: http://tinypaste.com/906c8 . Although 
it doesn't seem to contain any useful info. syslog-ng will log the 
suspend/resume process after a successful resume. Here is how the log looks 
like after a suspend/resume cycle instead: http://tinypaste.com/135b5 .

The 2nd log was taken from a file that was configured with "level(debug..emerg) 
and not facility(auth, authpriv)" in syslog-ng.conf .

I tried fanotify and it indeed didn't work with als_interrupt. It reported the 
file change OK with an "echo 1" but failed to notice when it was automatically 
cleared.

I'll see into acpid 2 some more. It is odd that other events worked.

Original comment by vanhtu1...@gmail.com on 27 Feb 2011 at 5:05

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

By the way, does the acpid requirement mean there will be no possibility to 
write a daemon for this?.

Original comment by vanhtu1...@gmail.com on 27 Feb 2011 at 5:11

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

It turned out that /proc/acpi/events has been said to be deprecated for at 
least 4 years :/ . I'm enabling it then.

Does suspend work well in your system with the patch?. Please tell me if you 
need more information.

Original comment by vanhtu1...@gmail.com on 28 Feb 2011 at 11:13

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

I had a look at your logs but are useless, send me any log you have, you can 
use my mail address.
Here on my vaio everything is working fine, both suspend and screen autodimming 
(though it's quite rough at the moment).

Original comment by ma...@absence.it on 28 Feb 2011 at 3:18

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Sorry, the logs given were about as far as I could get (is debug the most 
verbose level?). In my system, failing to resume means no logs will be written 
before suspend and after resume.

My GPU is a dedicated nvidia GT 330M, I've no idea how to get dmesg log without 
a serial port.

Original comment by vanhtu1...@gmail.com on 28 Feb 2011 at 6:02

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Uhm... I will think about it later. Enabling /proc/acpi/events worked for you? 
I'm changing the code and it seems to work fine now, even though not everything 
is in place.

Original comment by ma...@absence.it on 2 Mar 2011 at 2:46

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Kbd_lights
Just checked the values reported by ectool. 
There are a few values that keep changing between 0,5 and 20 sec sleeps on a 
VPCF121. 

How can I figure out what are legal values to write to the various addresses to 
try to turn it permanently on?

Original comment by samini...@gmail.com on 8 Mar 2011 at 10:49

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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?

Original comment by ma...@absence.it on 8 Mar 2011 at 4:05

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 8 Mar 2011 at 4:55

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

ALS event worked with the latest patch, thanks.

Original comment by vanhtu1...@gmail.com on 8 Mar 2011 at 5:02

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

Would you attach the 'latest' here, please?

Original comment by Jason.Donenfeld on 8 Mar 2011 at 5:06

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 8 Mar 2011 at 6:18

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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?

Original comment by ma...@absence.it on 9 Mar 2011 at 9:10

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 10:44

Added labels: ****
Removed labels: ****

Attachments:

sony-als.sh

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 11:07

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

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?

Original comment by ma...@absence.it on 9 Mar 2011 at 2:10

Added labels: ****
Removed labels: ****

Attachments:

backlight_disable.patch

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 2:11

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 2:13

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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...

Original comment by ma...@absence.it on 9 Mar 2011 at 2:21

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 2:27

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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.

Original comment by ma...@absence.it on 9 Mar 2011 at 3:19

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 3:22

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

Oh.. Suspend to ram is working..

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 3:36

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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>

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 3:37

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 3:47

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 3:59

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

[deleted comment]

GoogleCodeExporter · Apr 1, 2015

dsdt table:

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 4:09

Added labels: ****
Removed labels: ****

Attachments:

DSDT.dsl

GoogleCodeExporter · Apr 1, 2015

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)

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 4:24

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 4:34

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

hmm on this machine screen backlight not work after post.

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 4:41

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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 :)

Original comment by ma...@absence.it on 9 Mar 2011 at 5:52

Added labels: ****
Removed labels: ****

Attachments:

vpcs-als

GoogleCodeExporter · Apr 1, 2015

> 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.

Original comment by vanhtu1...@gmail.com on 9 Mar 2011 at 6:34

Added labels: ****
Removed labels: ****

GoogleCodeExporter · Apr 1, 2015

> 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):

Original comment by AlKo...@gmail.com on 9 Mar 2011 at 6:43

Added labels: ****
Removed labels: ****

Attachments:

GoogleCodeExporter added Priority-High Type-Defect auto-migrated labels Apr 1, 2015

tvogel/vaio-f11-linux

Join GitHub today

Sony-Laptop Module Support #6

Comments

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter added Priority-High Type-Defect auto-migrated labels Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015

GoogleCodeExporter commented Apr 1, 2015