Bug 11095

Created attachment 16834 [details]
acpidump made with pmtools

As adviced by the linux-acpi mailing list i attached the acpidump.

There is a working work-around ( :) ) here:
https://bugs.launchpad.net/ubuntu/+source/xbacklight/+bug/173652

Is this sufficient as a solution or can this still be a bug?

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

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

I just want to get some comments from Mattia, to know if the backlight support for SZ61MN will go to sony-laptop driver.

Zhang,

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

Okay, I'll take this bug, and push Sebastian to try the IGD feature once the patches are upstream. :)

Is there anything i can do right now?

well, the OpRegion patch is still not upstream yet.
would you please give this patch a try?
http://marc.info/?l=linux-acpi&m=121796145711797&w=2

hah, IGD OpRegion patches are shipped in 2.6.28-rc
please give them a try.

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.

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?

No, "kernel" does not work. Only mode working is "combined". When i switch to kernel mode i cant change brightness.

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.

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

Created attachment 18617 [details]
Output of grep . /sys/firmware/acpi/interrupts/*

Only one file because before/after pressing the hotkeys made no change.

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.

ping sebastian

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!

(In reply to comment #19)
> In short:
> 
> - Do i have to compile the hex file you provided?
no.

> - Is the howto in the link above correct?
hmm, it's out of date.
please try this "official" one. :p
http://www.lesswatts.org/projects/acpi/overridingDSDT.php

> - What else could be wrong?
did you update the kernel?
If yes, please make sure the kernel can boot without the customized DSDT.

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.

Created attachment 19086 [details]
customized DSDT

please try this one. :)

Im sorry to say this gives me the exact same errors. :/

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
line
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,
http://acpica.org.
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:

      CONFIG_STANDALONE=n
      CONFIG_ACPI_CUSTOM_DSDT=y
      CONFIG_ACPI_CUSTOM_DSDT_FILE="DSDT.hex"

4. Make the kernel and off you go!

      You should see in dmesg:
      Table [DSDT] replaced by host OS

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

Hi,

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?

you need to set CONFIG_ACPI_DEBUG
and boot with acpi.debug_level=0x03

I have set the boot option but i forgot to enable the debugging :) Sry, will try that as soon as possible!

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.

please attach the content of /sys/module/acpi/parameters/{debug_level, debug_layer}

matthew and jesse,
this seems to be a IGD OpRegion problem. please refer to comment #25.
can you help debug this issue?

Created attachment 19353 [details]
debug layer file

The content of the debug layer file.

Created attachment 19354 [details]
acpi debug level file

Content of the acpi debug level file.

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.

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.

Created attachment 19678 [details]
output dmesg -c before echoing to the backlight class

Piped dmesg -c to a file before i did something else.

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.

could you please attach the dmesg output like the ones in comment #36 and #37, but without the customized DSDT?