Bug 11095

Summary: IGD OpRegion doesn't work - Sony Vaio SZ61MN
Product: Drivers Reporter: Sebastian Pohl (sebastianp)
Component: Video(Other)Assignee: drivers_video-other
Severity: normal CC: alan, jbarnes, malattia, mjg59-kernel, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:
Bug Depends on: 10221    
Bug Blocks: 56331    
Attachments: acpidump made with pmtools
Output of grep . /sys/firmware/acpi/interrupts/*
customized DSDT
Sort of screenshot showing the errors during boot process
customized DSDT
dmesg with new kernel and acpi debug
debug layer file
acpi debug level file
Kernel config File
customized DSDT
output dmesg -c before echoing to the backlight class
output dmesg after echoing to the backlight class

Description Sebastian Pohl 2008-07-16 02:09:26 UTC
Latest working kernel version: never
Earliest failing kernel version:
Distribution: Arch Linux
Hardware Environment: Sony Vaio Laptop - SZ61MN
Software Environment: Arch Linux with Gnome Desktop
Problem Description: brightness control not working, display always at 100% brigthness

Steps to reproduce: Altering brightness -> doesnt work
Comment 1 Sebastian Pohl 2008-07-16 02:11:38 UTC
Created attachment 16834 [details]
acpidump made with pmtools

As adviced by the linux-acpi mailing list i attached the acpidump.
Comment 2 Sebastian Pohl 2008-07-16 08:18:43 UTC
There is a working work-around ( :) ) here:

Is this sufficient as a solution or can this still be a bug?
Comment 3 Zhang Rui 2008-07-16 18:46:06 UTC
this is not a bug.
It's an IGD OpRegion BIOS in your laptop which is not fully implemented yet.
Talking about generic solutions, the backlight can be supported in two ways,
1. the ACPI video driver. this can be done once the IGD stuff is finished.
2. the sony-laptop driver. But it seems it's not supported currently as well.

I don't know if there is any Sony platform specific methods in this laptop. If yes, we should do something magic in sony-laptop driver so that users can get rid of the workarounds, right? :)
Comment 4 Sebastian Pohl 2008-07-17 04:18:26 UTC
(In reply to comment #3)
> this is not a bug.
> It's an IGD OpRegion BIOS in your laptop which is not fully implemented yet.
> Talking about generic solutions, the backlight can be supported in two ways,
> 1. the ACPI video driver. this can be done once the IGD stuff is finished.
> 2. the sony-laptop driver. But it seems it's not supported currently as well.
> I don't know if there is any Sony platform specific methods in this laptop.
> If
> yes, we should do something magic in sony-laptop driver so that users can get
> rid of the workarounds, right? :)

Thanks for your help so far. You changed the status to NEEDINFO. What info do you need? Hope i can provide it!
Comment 5 Zhang Rui 2008-07-17 20:15:12 UTC
I just want to get some comments from Mattia, to know if the backlight support for SZ61MN will go to sony-laptop driver.
Comment 6 Mattia Dongili 2008-07-19 01:43:09 UTC

As far as I know the sz61 has 2 bios versions, one for winXP one for Vista.
In the XP version the DSDT exposes the 2 methods uset to set and get the brightness (SBRT and GBRT).
Unfortunately some extra magic seems to be required as calling those doesn't produce the expected behaviour. If some willingful user can trace what else is required I'll be happy to implement it in sony-laptop. (BTW: all my efforts at tracing acpi and ioport calls in windows regularly resulted in the os dying so I can't really advise on hoe to do it)

For the Vista version there are no such methods.

honestly, if there was a standars compliant way of changing the brightness on vaios i'd definitely go for that.

-- mattia
Comment 7 Zhang Rui 2008-07-20 18:43:20 UTC
Okay, I'll take this bug, and push Sebastian to try the IGD feature once the patches are upstream. :)
Comment 8 Sebastian Pohl 2008-08-07 05:58:42 UTC
Is there anything i can do right now?
Comment 9 Zhang Rui 2008-08-07 18:16:53 UTC
well, the OpRegion patch is still not upstream yet.
would you please give this patch a try?
Comment 10 Zhang Rui 2008-10-31 00:12:48 UTC
hah, IGD OpRegion patches are shipped in 2.6.28-rc
please give them a try.
Comment 11 Sebastian Pohl 2008-10-31 02:19:28 UTC
Its somehow solved now, but it has some strange behaviour. If i stay with this 'xrandr --output LVDS --set BACKLIGHT_CONTROL native' as before, the backlights starts changing its values automatically, slowly decreasing to around 10% then going up again and so on... Changing it to 'xrandr --output LVDS --set BACKLIGHT_CONTROL combined' made the gnome-brighntess applet work, now i can change brighntess with the function keys. Without the xrandr command i cant change brighntess... Its somehow strange.
Comment 12 Zhang Rui 2008-11-02 18:50:35 UTC
why do you need to change the BACKLIGHT_CONTROL mode?
what's the default BACKLIGHT_CONTROL mode?
hmm, it should be "kernel" by default.
Does this "kernel" mode work for you now?
Comment 13 Sebastian Pohl 2008-11-02 23:56:05 UTC
No, "kernel" does not work. Only mode working is "combined". When i switch to kernel mode i cant change brightness.
Comment 14 Zhang Rui 2008-11-03 00:19:03 UTC
can the backlight sysfs I/F (/sys/class/backlight/acpi_videoX/) work for you now?
please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the hotkeys and attach the test result.
Comment 15 Sebastian Pohl 2008-11-03 03:40:48 UTC
The backlight sysfs does not work. "echo 5 > /sys/class/backlight/acpi_video0/backlight" does not work.

I attached the output of grep. Its only one file because before/after pressing makes no change (checked with "diff before_button after_button").
Comment 16 Sebastian Pohl 2008-11-03 03:43:24 UTC
Created attachment 18617 [details]
Output of grep . /sys/firmware/acpi/interrupts/*

Only one file because before/after pressing the hotkeys made no change.
Comment 17 Zhang Rui 2008-11-03 17:41:29 UTC
Created attachment 18645 [details]
customized DSDT

Well, the _BCM method on this IGD OpRegion BIOS still doesn't work.
please rebuild the kernel with this customized DSDT first.
then boot the kernel with "acpi.debug_level=0x03",
poke the backlight sysfs I/F and attach the dmesg output.
Comment 18 Zhang Rui 2008-11-25 19:22:30 UTC
ping sebastian
Comment 19 Sebastian Pohl 2008-11-27 00:32:45 UTC
Sorry for the delay, had too much to do in the last weeks.

It may be terribly stupid but i dont know if im doing the DSDT stuff right...

I followed this howto http://wiki.archlinux.org/index.php/DSDT . 

But then the bootprocess fails with an error like "unable to create rootfs by uuid" and a bunch of acpi errors about some devices that are not found.

So i dont know if i had to compile the hex file you uploaded first or just rename it to .dsdt file or if something is wrong.

In short:

- Do i have to compile the hex file you provided?
- Is the howto in the link above correct?
- What else could be wrong?

Thank you!
Comment 20 Zhang Rui 2008-11-27 17:58:19 UTC
(In reply to comment #19)
> In short:
> - Do i have to compile the hex file you provided?

> - Is the howto in the link above correct?
hmm, it's out of date.
please try this "official" one. :p

> - What else could be wrong?
did you update the kernel?
If yes, please make sure the kernel can boot without the customized DSDT.
Comment 21 Sebastian Pohl 2008-11-28 01:56:43 UTC
Created attachment 19063 [details]
Sort of screenshot showing the errors during boot process

I managed to get the dsdt file into my initrd and its shown during the bootprocess. But as far as i can tell from the messages on the screen something goes wrong. It cant load the whole device stuff leaving me with no devices for the rootfs. I attached a picture of the messages, bad quality caused by cell phone camera but i think its decipherable.
Comment 22 Zhang Rui 2008-11-30 22:30:21 UTC
Created attachment 19086 [details]
customized DSDT

please try this one. :)
Comment 23 Sebastian Pohl 2008-12-01 17:02:38 UTC
Im sorry to say this gives me the exact same errors. :/
Comment 24 Zhang Rui 2008-12-01 17:57:51 UTC
could you please try to built the customized DSDT into kernel instead of initrd?

    * Index
    * PowerTOP
    * Tickless Idle
    * Power Policy Manager
    * Applications Power Management
    * Processor Power Management
    * Power and Performance Measurement
    * BLTK
    * Linux ACPI
          o Introduction
          o Patch Flow
          o Get Latest Source Code
          o Applying Patches
          o Submitting Patches
          o Validation
          o Debug
          o Overriding a DSDT
          o Reference
          o Mailing Lists
          o Bugzilla
          o Utilities
          o FAQ
          o Download
    * ACPICA
    * Power QoS
    * Device and Bus Power Management
    * Display and Graphics Power Saving

Linux ACPI
Overriding a DSDT
Why override a DSDT?

The DSDT (Differentiated System Description Table) is the primary AML table in the BIOS. Per the description of acpidump, the DSDT can be extracted from the machine, the ASL modified, and a new AML DSDT can be compiled. The sections below show two ways to tell Linux to use this modified DSDT instead of the version that came with the BIOS.

Note that overriding the DSDT is a debugging technique only. It is not a viable way to run a production system, as no vendor would support a system when the customer has modified the system firmware, and no Linux Distributor could possibly support modified system firmware either.

In the early days of Linux/ACPI, DSDT modifications were common to work around both BIOS bugs and Linux bugs. However, the stated goal of the Linux/ACPI project today is that Linux should run on un-modified firmware. Thus, the DSDT database at the old http://acpi.sourceforge.net web site is now largely a historical artifact.
Where do I get iasl for dis-assembling and compiling tables?

iASL is part of the ACPICA release,
Note that "iasl -d" can now not only dis-assemble a DSDT and SSDT, but also most other ACPI table images.
What if I also want to override the SSDTs?

If you need to modify the code present in an SSDT, then combine all of the SSDTs into a DSDT override, modify it as necessary, and boot with "acpi_no_auto_ssdt" to prevent Linux from automatically loading the SSDTs listed in the RSDT/XSDT.
Is it important if my DSDT doesn't re-compile

Not necessarily. Many static ASL bugs that are rejected by iASL have workarounds present in the Linux kernel. This is because even if you might be able to modify and override your DSDT, most users with a system like yours cannot.

Of course you need to get the DSDT to re-compile if you want to run your modifications.
How to print to the Linux console from AML

When CONFIG_ACPI_DEBUG=y and when acpi.debug_level & 0x8, ASL stores to the special object "Debug" will come out in the dmesg. eg

Store("hello world!", Debug)

Store(Local0, Debug)

[ACPI Debug] String: [0x0C] "hello world!"

[ACPI Debug] Integer: 0x00000042
How to Build a custom DSDT into the kernel
1. download the DSDT.hx in comment #22

2. Put it where the kernel build can include it:

      $ cp DSDT.hex $SRC/include/

3. Add this to the kernel .config:


4. Make the kernel and off you go!

      You should see in dmesg:
      Table [DSDT] replaced by host OS
Comment 25 Zhang Rui 2008-12-09 23:37:24 UTC
I can reproduce this problem on a Sony VGN Z540.

here is the AML code path when invoking _BCM method,

                Store ("Arg0", Debug)
                Store (Arg0, Debug)
                Store ("Arg1", Debug)
                Store (Arg1, Debug)

                Store (Arg1, BCLP)
                Or (BCLP, 0x80000000, BCLP)
                Store (0x02, ASLC)

IMO, this is a IGD OpRegion problem.
when I run echo {0,4,8} > /sys/class/backlight/acpi_video0/brightness,
I got this in dmesg

[  875.931991] [ACPI Debug]  String [0x04] "Arg0"
[  875.933758] [ACPI Debug]  Integer 0x00000001
[  875.933826] [ACPI Debug]  String [0x04] "Arg1"
[  875.933891] [ACPI Debug]  Integer 0x00000008

[  880.088142] [ACPI Debug]  String [0x04] "Arg0"
[  880.089780] [ACPI Debug]  Integer 0x00000001
[  880.089845] [ACPI Debug]  String [0x04] "Arg1"
[  880.089908] [ACPI Debug]  Integer 0x0000002A

[  884.249103] [ACPI Debug]  String [0x04] "Arg0"
[  884.249170] [ACPI Debug]  Integer 0x00000001
[  884.249230] [ACPI Debug]  String [0x04] "Arg1"
[  884.249289] [ACPI Debug]  Integer 0x000000FF

it seems that the AML code has sent a notification to the graphics driver, but the graphics driver doesn't change the backlight correctly. right?
cc Matthew and Jesse.
Comment 26 Sebastian Pohl 2008-12-10 09:01:09 UTC

i managed to build the kernel with the DSDT File. And i have this line in dmesg:

ACPI: Table DSDT replaced by host OS

But when echoing values to the backlight brightness file nothing appears in the dmesg output. 

Would it help if i give you root access via ssh to my machine for a few hours?
Comment 27 Zhang Rui 2008-12-10 19:46:55 UTC
you need to set CONFIG_ACPI_DEBUG
and boot with acpi.debug_level=0x03
Comment 28 Sebastian Pohl 2008-12-11 02:54:42 UTC
I have set the boot option but i forgot to enable the debugging :) Sry, will try that as soon as possible!
Comment 29 Sebastian Pohl 2008-12-16 05:57:13 UTC
Created attachment 19325 [details]
dmesg with new kernel and acpi debug

I made a new kernel with all the necessary options but i cant find something similar to your stuff.
Comment 30 Zhang Rui 2008-12-16 17:16:51 UTC
please attach the content of /sys/module/acpi/parameters/{debug_level, debug_layer}
Comment 31 Zhang Rui 2008-12-16 17:19:19 UTC
matthew and jesse,
this seems to be a IGD OpRegion problem. please refer to comment #25.
can you help debug this issue?
Comment 32 Sebastian Pohl 2008-12-18 05:24:28 UTC
Created attachment 19353 [details]
debug layer file

The content of the debug layer file.
Comment 33 Sebastian Pohl 2008-12-18 05:25:15 UTC
Created attachment 19354 [details]
acpi debug level file

Content of the acpi debug level file.
Comment 34 Sebastian Pohl 2008-12-18 05:27:39 UTC
Created attachment 19355 [details]
Kernel config File

This is the kernel config file i used to compile my kernel. I enabled the ACPI Debug stuff but as i noticed in the debug files above it is not really set.
Comment 35 Zhang Rui 2008-12-18 17:07:04 UTC
Created attachment 19365 [details]
customized DSDT

please try this DSDT instead.
please attach the dmesg after boot.
and then run dmesg -c
make sure /sys/module/acpi/parameters/debug_level is 0x03
echo ... > /sys/class/backlight/acpi_video0/brightness
and attach the dmesg output again.
Comment 36 Sebastian Pohl 2009-01-06 11:54:41 UTC
Created attachment 19678 [details]
output dmesg -c before echoing to the backlight class

Piped dmesg -c to a file before i did something else.
Comment 37 Sebastian Pohl 2009-01-06 11:55:42 UTC
Created attachment 19679 [details]
output dmesg after echoing to the backlight class

After echoing some values (1, 2 ,4 ..) to the sys backlight class i piped dmesg to a file again.
Comment 38 Zhang Rui 2009-01-06 18:02:08 UTC
could you please attach the dmesg output like the ones in comment #36 and #37, but without the customized DSDT?