search

tvogel / vaio-f11-linux

Automatically exported from code.google.com/p/vaio-f11-linux
7 stars 2 forks source link

Sony-Laptop Module Support #6

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
ALS event worked with the latest patch, thanks.

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

GoogleCodeExporter commented 9 years ago 
Would you attach the 'latest' here, please?

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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

Attachments:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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