Open GoogleCodeExporter opened 9 years ago
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
> 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
> 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
[deleted comment]
Oh.. Suspend to ram is working..
Original comment by AlKo...@gmail.com
on 9 Mar 2011 at 3:36
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
> 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
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
[deleted comment]
dsdt table:
Original comment by AlKo...@gmail.com
on 9 Mar 2011 at 4:09
Attachments:
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
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
hmm on this machine screen backlight not work after post.
Original comment by AlKo...@gmail.com
on 9 Mar 2011 at 4:41
> 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
Attachments:
> 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
> 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
Attachments:
Original issue reported on code.google.com by
Jason.Donenfeld
on 10 Feb 2010 at 10:10