Fn + F[89] does not work for controlling brightness on Clevo laptops (B7130, W150HRM)

Bug #806032 reported by Peter Wu
48
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
linux (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Precise by Anthony Wong
Nominated for Quantal by Anthony Wong

Bug Description

I cannot modify the brightness level through Fn + F[89] keys even if I can control it through `/sys/class/backlight/acpi_video0` or the Power management applet in KDE.

I followed the instructions on https://wiki.ubuntu.com/Hotkeys/Troubleshooting without luck
I've already tried `xev`, `udevadm monitor`, looking in dmesg and /var/log/kern.log, using /lib/udev/keymap for monitoring keyboard input.

Per suggestion by apw in #ubuntu-kernel, I installed input-utils and ran `sudo lsinput` to get a list of devices. On each device, I did `sudo input-events -t 10 $number` to watch for events. Each time I pressed a regular key ("c"), another Fn key (Fn + F6 / Volume Up) and Fn + F[89] (brightness up/down). I didn't get any output for the Fn + F[89] events.

Link to user guides (which includes images): http://www.clevo.com.tw/en/e-services/download/USRManualOut.asp?model=B7130

IRC log:
http://irclogs.ubuntu.com/2011/07/05/%23ubuntu-kernel.html#t15:02

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: linux-image-2.6.38-8-generic 2.6.38-8.42
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: VT1812 Analog [VT1812 Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: peter 21076 F.... pulseaudio
 /dev/snd/pcmC0D0p: peter 21076 F...m pulseaudio
CRDA: Error: [Errno 2] Bestand of map bestaat niet
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfd800000 irq 50'
   Mixer name : 'Intel IbexPeak HDMI'
   Components : 'HDA:11060448,15587130,00100000 HDA:80862804,15587130,00100000'
   Controls : 29
   Simple ctrls : 14
Date: Tue Jul 5 17:55:27 2011
InstallationMedia: Kubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426.3)
MachineType: CLEVO CO. B7130
ProcEnviron:
 LANGUAGE=nl_NL
 PATH=(custom, user)
 LANG=nl_NL.UTF-8
 LC_MESSAGES=nl_NL.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-2.6.38-8-generic root=/dev/mapper/sda2_crypt ro splash vt.handoff=7 break=modules,premount,mount
RelatedPackageVersions:
 linux-restricted-modules-2.6.38-8-generic N/A
 linux-backports-modules-2.6.38-8-generic N/A
 linux-firmware 1.52
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/27/2010
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 6.00
dmi.board.asset.tag: Tag 12345
dmi.board.name: B7130
dmi.board.vendor: CLEVO CO.
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd08/27/2010:svnCLEVOCO.:pnB7130:pvrNotApplicable:rvnCLEVOCO.:rnB7130:rvrNotApplicable:cvnNoEnclosure:ct9:cvrN/A:
dmi.product.name: B7130
dmi.product.version: Not Applicable
dmi.sys.vendor: CLEVO CO.

Revision history for this message
Peter Wu (lekensteyn) wrote :
Revision history for this message
Peter Wu (lekensteyn) wrote :
description: updated
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Peter Wu (lekensteyn)
summary: - Fn + F[89] does not work for controlling brightness
+ Fn + F[89] does not work for controlling brightness on Clevo laptops
+ (B7130, W150HRM)
Revision history for this message
Melroy van den Berg (melroyvandenberg) wrote :

It effects me too, please take this bug seriously. Thanks.

Revision history for this message
In , Peter Wu (lekensteyn) wrote :

Created attachment 56399
acpidump of Clevo B7130

According to Section 3.1.6 on page 40 of the ACPI Integrated Graphics OpRegion Specification from http://intellinuxgraphics.org/ACPI_IGD_OpRegion_%20Spec.pdf, the driver is supposed to set the CADL field during boot and on every mode set process. An excerpt from the spec:

============================================================
Description
This field indicates which display devices (monitors) are currently
active. A maximum of eight monitors are assumed active on a given
platform. The IDs should be the same as the enumerated monitor or
connector IDs. The graphics driver determines active monitors
during mode set times and during boot.

Driver Access
Writes: The graphics driver writes to this field on every mode set
process and during boot.
Reads: The graphics driver can read this field to update NADL.
============================================================

The struct member "cadl" from drivers/gpu/drm/i915/intel_opregion.c is read/written nowhere. This has as implication that the field is left uninitialized and and code that relies on that field cannot work.

So far, the affected hardware I know of are the Clevo B7130 and Clevo H150HRM. The brightness hotkeys emit an ACPI event for the Embedded Controller that checks whether an monitor is connected or not. A part of method _Q11:
============================================================
If (LEqual (^^^GFX0.CDDS (0x0410), 0x1F)) {
    If (LEqual (OEM2, Zero)) {
        If (^^^^WMI.HKDR) {
            Store (0xE0, ^^^^WMI.EVNT)
            Notify (WMI, 0xD0)
        }
    } Else {
        Notify (^^^GFX0.LCD0, 0x87)
    }
}
============================================================

The CDDS functions checks the fields of CADL, CAL2, ..., CAL8 and returns 0x1F if an active display equals its first argument:
============================================================
Method (CDDS, 1, NotSerialized) {
    Store (And (Arg0, 0x0F0F), Local0)
    If (LEqual (Zero, Local0)) {
        Return (0x1D)
    }
    If (LEqual (And (CADL, 0x0F0F), Local0)) {
        Return (0x1F)
    }
============================================================

This bug also makes the return value of ACPI method _DCS useless.

Revision history for this message
In , Peter Wu (lekensteyn) wrote :

Distribution: Kubuntu 11.10 AMD64
Kernel: 3.2.2 (from kernel.org)
Hardware: Intel i5 460M with HD graphics (+nvidia GT 425M, not important here)

When writing the output of the \_SB.PCI0.GFX0.LCD0._ADR value to the DIDL field, brightness keys works.

Revision history for this message
In , Peter Wu (lekensteyn) wrote :

More machine information for an earlier bugreport related to brightness via hotkeys is available at: https://bugs.launchpad.net/linux/+bug/806032

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Peter Wu (lekensteyn) wrote :

From the previous findings, I've cooked a shellscript that uses acpi_call to determine the address and ID to write. It relies on the property that the DSDT of Clevo B7130 and Clevo W150HRM declare the base address in the \ASLB field. I've seen other machines hardcoding this value in their DSDT. In that case, look for the field that is possibly named IGDM and copy the address from the placeholder as shown below:

OperationRegion (IGDM, SystemMemory, ADDRESSHERE, 0x2000)

The DSDT can be retrieved using:
sudo apt-get install acpidump iasl
cd $(mktemp -d)
sudo acpidump > acpidump.txt
acpixtract acpidump.txt
iasl -d *.dat
grep IGDM DSDT.dat

Make the attachment executable and execute it with root:
chmod +x cadl_hack_brightness
sudo ./cadl_hack_brightness

Revision history for this message
Peter Wu (lekensteyn) wrote :

The attached upstart script contains the script from the earlier post, but fixes an issue in validating the _ADR result (which would result in writing a 0 to the field, which was the default value)

Install it with:
sudo install -m 644 cadl-brightness.conf /etc/init
sudo start cadl-brightness

The next boot, the hack will automatically be loaded. Removing the hack is as easy as:

sudo rm /etc/init/cadl-brightness.conf

Revision history for this message
In , Mau (mavoga) wrote :

Created attachment 61006
Clevo W150HRM acpidump

Clevo W150HRM is equally affected: attaching acpidump (BIOS v1.09)

Revision history for this message
Eric Appleman (erappleman) wrote :

Adding acpi_osi= to the Grub line in /etc/default/grub enables the hotkeys.

Revision history for this message
Eric Appleman (erappleman) wrote :

err GRUB_CMDLINE_LINUX_DEFAULT

Revision history for this message
Peter Wu (lekensteyn) wrote :

Hmm, I can't see why setting an empty ACPI OSI string has effect. acpi_osi="Windows 2006" or later enables some additional code that should make the brightness settings work providing that CDDS has been initialized correctly.

Revision history for this message
Eric Appleman (erappleman) wrote :

When using the script, button presses will bring up the brightness meter. The grub setting does not.

Revision history for this message
Eric Appleman (erappleman) wrote :

With respect to a "Windows 2006" string, I have no idea how to escape that properly.

Revision history for this message
Peter Wu (lekensteyn) wrote :

I only get the brightness meter if I hold the brightness keys for a longer time, i.e. not when I press it once to increment/decrement it by one. What do you mean by escape?

Revision history for this message
Eric Appleman (erappleman) wrote :

Escape as in use a proper string that grub will recognize.

Revision history for this message
Peter Wu (lekensteyn) wrote :

The grub option is supposed to be acpi_osi="Windows 2006". The /etc/default/grub file is sourced so you need to use \" in there. (this is not necessary if you pass it as boot param by holding shift before boot).

Revision history for this message
Eric Appleman (erappleman) wrote :

Ah, I see what's going on now.

An empty OSI string will load the brightness controls in what seems to be a hardware (embedded controller?) mode, bypassing any hotkey detection from the distro.

Revision history for this message
In , Peter Wu (lekensteyn) wrote :

"Temporary" patch has been accepted, patch + acknowledgement:
http://lists.freedesktop.org/archives/dri-devel/2012-June/024488.html
http://lists.freedesktop.org/archives/dri-devel/2012-June/024529.html

Therefore I am marking this bug as resolved.

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

Merged to dinq as:

commit 3e52259264832dc8c8b94c91561f072ab1d192d8
Author: Lekensteyn <email address hidden>
Date: Tue Jun 26 00:36:24 2012 +0200

    i915: initialize CADL in opregion

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

Reopening because the patch had to be dropped - it caused regressions. The issues are now root-caused (it simply brought a pre-existing bug to light), but we first need to fix these bugs before I can merge the cadl patch again.

Please do not close this bug before the cadl patch has landed in drm-intel-next - I'll likely lose track of things otherwise ;-)

Revision history for this message
In , Peter Wu (lekensteyn) wrote :

Okay, I'll let you handle the lock then :)
For the interested, a discussion is going on here: http://lists.freedesktop.org/archives/dri-devel/2012-June/024661.html

Have you already found out the root cause?

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

On Fri, Jun 29, 2012 at 5:08 PM, <email address hidden> wrote:
> Have you already found out the root cause?

Yep, see Message-ID: <email address hidden> on
dri-devel and http://cgit.freedesktop.org/~danvet/drm/log/?h=cpu_edp-abomination
for the totally hackish patches ...

Revision history for this message
In , Anthony Wong (anthonywong) wrote :

Created attachment 64320
acpidump of Asus X401A

Hi Peter,

Your patch works great on the Asus X401A here, which also has the same problem, i.e. CADL is queried when brightness keys are pressed. Its CDDS method also looks almost the same as the one of Clevo B7130. I have uploaded the acpidump of the Asus X401A, so you can check if your patch can apply equally well to this machine. Thanks!

Revision history for this message
In , XiongZhang (xiong-y-zhang) wrote :

In the patch code, it treat CADL and DIDL as the same, but from spec, they are different: DIDL is Supported Display Devices ID List and CADL is Currently Attached Display Devices List.So only these IDs in DIDL with connect status can add to CADL, not all IDS in DIDL.

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

On Tue, Jul 24, 2012 at 10:19 AM, <email address hidden> wrote:
> --- Comment #10 from XiongZhang <email address hidden> 2012-07-24 08:19:58 UTC ---
> In the patch code, it treat CADL and DIDL as the same, but from spec, they are
> different: DIDL is Supported Display Devices ID List and CADL is Currently
> Attached Display Devices List.So only these IDs in DIDL with connect status can
> add to CADL, not all IDS in DIDL.

I know (I even suggested this approach), but this one here gets the
job done, so I plan to merge it until something more accurate shows
up. If something more accurate is required even.

Revision history for this message
Colby Butler (popejamal) wrote :

This bug also affects the Sager NP9170 (CLEVO P170EM).

Revision history for this message
Colby Butler (popejamal) wrote :

I had to make a change:

The DSDT can be retrieved using:
sudo apt-get install acpidump iasl
cd $(mktemp -d)
sudo acpidump > acpidump.txt
acpixtract acpidump.txt
iasl -d *.dat
grep IGDM DSDT.dsl

.dsl, not .dat. For me the .dat file was a binary file.

Regardless, I can't get this to work onmy P170EM.

Revision history for this message
Peter Wu (lekensteyn) wrote :

Yea, typo in my comment, it should indeed be grepping the .dsl file, not the .dat one. Anyway, please attach your acpidump.txt, otherwise it is hard to tell what the cause is.

Revision history for this message
Colby Butler (popejamal) wrote :

OS: Mint Maya (Based on 12.04)
Machine: Sager NP9170 (Clevo P170EM)
Brightness Down: Fn + F8 key
Brightness Up: Fn + F9 key

Output from grep mentioned above:

$ grep IGDM DSDT.dsl
            OperationRegion (IGDM, SystemMemory, ASLB, 0x2000)
            Field (IGDM, AnyAcc, NoLock, Preserve)

I applied the .conf file above with the commands specified, rebooted and the brightness keys still didn't work. Please let me know if there is any more information I can provide.

Revision history for this message
Peter Wu (lekensteyn) wrote :

I haven't looked at your acpidump yet, but have you installed acpi_call from the bumblebee/stable PPA (or build it manually using the instructions on https://github.com/Bumblebee-Project/acpi_call)

Revision history for this message
Colby Butler (popejamal) wrote :

Performing:

sudo apt-get install acpi-call-tools acpi-call-source

was the missing link. Once installed and rebooted, the brightness keys are now working. I'm not certain whether or not installing the source was necessary.

Thank you very much!

tags: added: blocks-hwcert-enablement
Revision history for this message
Colin Law (colin-law) wrote :

I have this problem with a PC Specialist Genesys IV which is based on a Clevo laptop. The mother board is reported as
baseboard-manufacturer: CLEVO CO.
baseboard-product-name: W240EU/W250EUQ/W270EUQ
baseboard-version : V3.0

The script in #7 gives
            OperationRegion (IGDM, SystemMemory, ASLB, 0x2000)
            Field (IGDM, AnyAcc, NoLock, Preserve)
which, if I understand correctly means that the cadl_hack_brightness script should work as is. However when I run it I get

dd: writing `/dev/mem': Bad address

and when I add debug to show $addr it is 3660685688

Running Ubuntu 12.10 alpha with unity if that is of any relevance.
Any help would be much appreciated.

Revision history for this message
Colin Law (colin-law) wrote :

I see that on boot, in syslog I am getting

Aug 5 17:55:07 tigger kernel: [ 10.278917] ACPI Warning: 0x00000460-0x0000047f SystemIO conflicts with Region \PMIO 1 (20120320/utaddress-251)
Aug 5 17:55:07 tigger kernel: [ 10.278922] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Aug 5 17:55:07 tigger kernel: [ 10.278926] ACPI Warning: 0x00000428-0x0000042f SystemIO conflicts with Region \PMIO 1 (20120320/utaddress-251)
Aug 5 17:55:07 tigger kernel: [ 10.278929] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Aug 5 17:55:07 tigger kernel: [ 10.278931] ACPI Warning: 0x00000500-0x0000053f SystemIO conflicts with Region \GPIO 1 (20120320/utaddress-251)
Aug 5 17:55:07 tigger kernel: [ 10.278934] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
Aug 5 17:55:07 tigger kernel: [ 11.919860] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
Aug 5 17:55:07 tigger kernel: [ 14.579414] ACPI Error: [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS (20120320/dswload2-316)
Aug 5 17:55:07 tigger kernel: [ 14.579419] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20120320/psloop-231)
Aug 5 17:55:07 tigger kernel: [ 14.579422] ACPI Error: Method parse/execution failed [\_SB_.AC__.ADJP] (Node f382d120), AE_ALREADY_EXISTS (20120320/psparse-536)
Aug 5 17:55:07 tigger kernel: [ 14.579427] ACPI Error: Method parse/execution failed [\_SB_.AC__._PSR] (Node f382d0f0), AE_ALREADY_EXISTS (20120320/psparse-536)
Aug 5 17:55:07 tigger kernel: [ 14.579432] ACPI Exception: AE_ALREADY_EXISTS, Error reading AC Adapter state (20120320/ac-118)
Aug 5 17:55:07 tigger kernel: [ 14.580020] ACPI: Marking method ADJP as Serialized because of AE_ALREADY_EXISTS error
Aug 5 17:55:07 tigger kernel: [ 14.580726] ACPI: Marking method _PSR as Serialized because of AE_ALREADY_EXISTS error

Could that be of any relevance to this problem?

Revision history for this message
Peter Wu (lekensteyn) wrote :

Can you test an older kernel? E.g. 3.2 from Ubuntu 12.04 or 3.0 from Ubuntu 11.10.

Revision history for this message
Colin Law (colin-law) wrote :

I have succeeded (with some trepidation) in installing and booting from kernel 3.2.0.27-43 (in Quantal). Most of the boot errors have gone, just leaving:

Aug 6 09:12:03 tigger kernel: [ 3.071520] ACPI Error: [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS (20110623/dswload2-316)
Aug 6 09:12:03 tigger kernel: [ 3.071525] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20110623/psloop-231)
Aug 6 09:12:03 tigger kernel: [ 3.071528] ACPI Error: Method parse/execution failed [\_SB_.AC__.ADJP] (Node f742d120), AE_ALREADY_EXISTS (20110623/psparse-536)
Aug 6 09:12:03 tigger kernel: [ 3.071533] ACPI Error: Method parse/execution failed [\_SB_.AC__._PSR] (Node f742d0f0), AE_ALREADY_EXISTS (20110623/psparse-536)
Aug 6 09:12:03 tigger kernel: [ 3.071538] ACPI Exception: AE_ALREADY_EXISTS, Error reading AC Adapter state (20110623/ac-118)
Aug 6 09:12:03 tigger kernel: [ 3.093674] ACPI: Marking method ADJP as Serialized because of AE_ALREADY_EXISTS error
Aug 6 09:12:03 tigger kernel: [ 3.109426] ACPI: Marking method _PSR as Serialized because of AE_ALREADY_EXISTS error

However running cadl_brightness_hack I still get
dd: writing `/dev/mem': Bad address
with $addr 3660685688

Revision history for this message
Melroy van den Berg (melroyvandenberg) wrote :

Nice to see that the bug is/will be resolved.

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Colin Law (colin-law) wrote :

Lekensteyn are you able to confirm whether my problem (comment #25) is part of this same issue or is whether it is a different bug? Your help is very much appreciated.

Revision history for this message
Peter Wu (lekensteyn) wrote :

I don't know why you would get that error. Can you modprobe acpi-call and run:

c(){ echo "$1" | sudo tee /proc/acpi/call >/dev/null && sudo cat /proc/acpi/call;echo;}

c '\ASLB'
c '\_SB_.PCI0.GFX0.CAL1'

Please post the output of the last two commands (the first command just defines a helper function).
For me, the first one outputs 0xb378f018. In my DSDT, CAL1 is named "CADL" (though CALn with 2 <= n <= 8 has the same name as yours) and shows 0x100.

On my laptop, the CADL (CAD1) field appears as: /proc/iomem: b376f000-b379efff : ACPI Non-volatile Storage

Note that these initial scripts have been tested on an Oneiric machine (I cannot remember whether this was with the xorg-edgers/ppa repository enabled or not), later tests have been done on a vanilla kernel from kernel.org with a custom config.

Revision history for this message
Colin Law (colin-law) wrote :

$ c '\ASLB'
0xda31a018

$ c '\_SB_.PCI0.GFX0.CAL1'
0x0

The other CALn also show 0x0

If you think it worthwhile I could boot of an Oneiric live CD and try it.

Revision history for this message
Peter Wu (lekensteyn) wrote :

The output is as expected (CALn is 0 because it did not get initialized). Yes, please try Oneiric 64-bit.

Revision history for this message
Colin Law (colin-law) wrote :

I tried Oneiric 32 bit live CD (as that is what I have available) but I do not get a working system. The CD is good so there must be something in the laptop it does not like. Precise 32 bit runs ok but when I try the scripts and the experiment in comment 39 I get exactly the same as on Quantal.

I suspect that Oneiric 64 would have the same problems as 32 bit but I can download it and try if that is the best thing to do.

Revision history for this message
Peter Wu (lekensteyn) wrote :

What does your /proc/iomem show? If Oneiric fails, try building a vanilla kernel (maybe the Ubuntu mainline kernels works too).

If that still does not work, or if you want to try something else, apply the patch from freedesktop.org (see above) and build the i915 kernel module.

Revision history for this message
Colin Law (colin-law) wrote :

/proc/iomem is below.

I will give the Oneiric kernel a go in Quantal (32 bit).
I think building a kernel may be a bit beyond my capabilities, or at least would involve me in a lot of research to get to the point where it is within my capabilities, so hopefully that can be avoided.
Thanks again for your ongoing help.

$ sudo cat /proc/iomem
00000000-0000ffff : reserved
00010000-0009d7ff : System RAM
0009d800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : Video RAM area
000c0000-000cedff : Video ROM
000cf000-000cffff : Adapter ROM
000d0000-000d3fff : PCI Bus 0000:00
000d4000-000d7fff : PCI Bus 0000:00
000d8000-000dbfff : PCI Bus 0000:00
000dc000-000dffff : PCI Bus 0000:00
000e0000-000fffff : reserved
  000e0000-000e3fff : PCI Bus 0000:00
  000e4000-000e7fff : PCI Bus 0000:00
  000f0000-000fffff : System ROM
00100000-1fffffff : System RAM
  01000000-015cf817 : Kernel code
  015cf818-018ad2bf : Kernel data
  0196f000-01a48fff : Kernel bss
20000000-201fffff : reserved
  20000000-201fffff : pnp 00:0d
20200000-40003fff : System RAM
40004000-40004fff : reserved
  40004000-40004fff : pnp 00:0d
40005000-d9d84fff : System RAM
d9d85000-da214fff : reserved
da215000-da215fff : ACPI Tables
da216000-da32bfff : ACPI Non-volatile Storage
da32c000-da723fff : reserved
da724000-da724fff : System RAM
da725000-da767fff : ACPI Non-volatile Storage
da768000-dadd5fff : System RAM
dadd6000-daff2fff : reserved
daff3000-daffffff : System RAM
db000000-db7fffff : RAM buffer
db800000-df9fffff : reserved
dfa00000-feafffff : PCI Bus 0000:00
  dfa00000-dfa00fff : pnp 00:0c
  e0000000-efffffff : 0000:00:02.0
  f0000000-f00fffff : PCI Bus 0000:03
    f0000000-f0003fff : 0000:03:00.2
      f0000000-f0003fff : r8169
    f0004000-f0004fff : 0000:03:00.2
      f0004000-f0004fff : r8169
  f7800000-f7bfffff : 0000:00:02.0
  f7c00000-f7cfffff : PCI Bus 0000:03
    f7c00000-f7c0ffff : 0000:03:00.0
  f7d00000-f7dfffff : PCI Bus 0000:02
    f7d00000-f7d01fff : 0000:02:00.0
      f7d00000-f7d01fff : iwlwifi
  f7e00000-f7e0ffff : 0000:00:14.0
    f7e00000-f7e0ffff : xhci_hcd
  f7e10000-f7e13fff : 0000:00:1b.0
    f7e10000-f7e13fff : ICH HD audio
  f7e15000-f7e150ff : 0000:00:1f.3
  f7e16000-f7e167ff : 0000:00:1f.2
    f7e16000-f7e167ff : ahci
  f7e17000-f7e173ff : 0000:00:1d.0
    f7e17000-f7e173ff : ehci_hcd
  f7e18000-f7e183ff : 0000:00:1a.0
    f7e18000-f7e183ff : ehci_hcd
  f7e1a000-f7e1a00f : 0000:00:16.0
    f7e1a000-f7e1a00f : mei
  f8000000-fbffffff : PCI MMCONFIG 0000 [bus 00-3f]
    f8000000-fbffffff : reserved
      f8000000-fbffffff : pnp 00:0c
fec00000-fec00fff : reserved
  fec00000-fec003ff : IOAPIC 0
fed00000-fed03fff : reserved
  fed00000-fed003ff : HPET 0
fed10000-fed17fff : pnp 00:0c
fed18000-fed18fff : pnp 00:0c
fed19000-fed19fff : pnp 00:0c
fed1c000-fed1ffff : reserved
  fed1c000-fed1ffff : pnp 00:0c
fed20000-fed3ffff : pnp 00:0c
fed40000-fed44fff : pnp 00:01
fed45000-fed8ffff : pnp 00:0c
fed90000-fed93fff : pnp 00:0c
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
ff000000-ffffffff : reserved
  ff000000-ffffffff : pnp 00:0c
100000000-11f5fffff : System RAM
11f600000-11fffffff : RAM buffer

Revision history for this message
Colin Law (colin-law) wrote :

I managed to boot off the Oneiric live CD (32 bit), kernel 3.0.0-12-generic. Everything exactly as before (cadl_hack_brightness error and the outputs in comment 40.

Revision history for this message
Colin Law (colin-law) wrote :

Right, now we are getting somewhere. I booted off the Oneiric desktop 64 bit live CD and now cadl_hack_brightness works correctly, the Fn keys show the brightness bar and change the brightness. Kernel 3.0.0-12-generic.
And
$ c '\ASLB'
0xda31a018
$ c '\_SB_.PCI0.GFX0.CAL1'
0x410

So it works on 3.0.0-12 64 bit Oneiric but not 32 bit. Does that mean that it is not my laptop which is different but it is the fact that I am using the 32 bit kernel?
I suppose I had better try Quantal 64 bit, or does that knowledge already give you something to go on?

Revision history for this message
Peter Wu (lekensteyn) wrote :

If 64-bit works, use that since it is the future. I do not know why 32-bit would not work. I guess it is an issue in the /dev/mem interface.

Revision history for this message
Colin Law (colin-law) wrote :

64 bit is not an option for me at the moment. I have now confirmed the workaround works on Quantal 64 bit and having looked at the script again I understand your comment about /dev/mem being the problem, I initially assumed it was the address that was at fault. I will file a bug against /dev/mem.
Thanks for the help.

Revision history for this message
Colin Law (colin-law) wrote :

I have reported the /dev/mem write problem on 32 bit kernel in bug #1037094

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

*** Bug 52042 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Anonymous-dodgeit (anonymous-dodgeit) wrote :

Created attachment 66537
acpidump of Asus UX32VD

Revision history for this message
In , Anonymous-dodgeit (anonymous-dodgeit) wrote :

Aahh, at last I found this entry. I was debugging the dsdt from my Asus UX32VD and I came to pretty much similar result.
The DID2 field is never initialized, which lets CDDS(DID2) return 0x1d and makes _DCS useless. _DCS is used in _Q0E and _Q0F.
The lines in question:
============================================================
Store (And (Arg0, 0x0F0F), Local0)
                    If (LEqual (Zero, Local0))
                    {
                        Return (0x1D)
                    }
============================================================
used by Q0F:

============================================================
If (LNotEqual (^^^GFX0.LCDD._DCS (), 0x1F))
                    {
                        Return (One)
                    }
============================================================

Since _DCS returns 0x1d, _Q0E and _Q0F returns silently one, instead of continuing until the Notify event is invoked.
Q0E/0F looks similar to your Q11, although _Q0E/F is a little bit more complicated, but the overall structure is the same.

Revision history for this message
In , Anonymous-dodgeit (anonymous-dodgeit) wrote :

Ooops, wasn't the did2 field. It was exactly the same as the others. Uninitialized cadl. Tried the patch. Works for the UX32VD.

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

Patch merged (again) to drm-intel-next-queued:

commit 036223401d50594c35fc5f7eafdbd2ddbe3ec921
Author: Lekensteyn <email address hidden>
Date: Tue Jun 26 00:36:24 2012 +0200

    i915: initialize CADL in opregion

Changed in linux:
status: Confirmed → Fix Released
Revision history for this message
Colin Law (colin-law) wrote :

Does anyone know which version of the kernel this fix should appear in? I am still seeing it in Quantal Beta. (3.5.0-17)

Revision history for this message
Peter Wu (lekensteyn) wrote :

It'll end up in 3.7.

penalvch (penalvch)
tags: added: needs-upstream-testing
Revision history for this message
AceLan Kao (acelankao) wrote :

https://bugassistant.libreoffice.org/show_bug.cgi?id=43577
The CADL patch introduced another black screen issue and is not really fixed until now.

Revision history for this message
Peter Wu (lekensteyn) wrote :

AceLan, the patch first entered in the 3.6 series, the bug you linked is much older.

Daniel Vetter first mentioned the patch in https://bugs.freedesktop.org/show_bug.cgi?id=43577#c9, but there are no reports thereafter that claim that it causes black screens (these issues existed before the patch).

Revision history for this message
Colin Law (colin-law) wrote :

I can confirm that the brightness fn keys are now working for me in Raring daily build as of 7th Jan 2013 (and possibly earlier).

Revision history for this message
AceLan Kao (acelankao) wrote :

We need to figure out what commits are needed to fix the black screen, so that we can submit CADL SRU with those patches.
The kernel team don't like the regression even if the bug is pre-existing and reveled by CADL patch.

Revision history for this message
Anthony Wong (anthonywong) wrote :

Fixed per comment #59 and upstream bug has been resolved.

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Egbert van der Wal (eggie) wrote :

I'm not sure if this is still / again the same problem, but I have a very similar issue on a recently bought Clevo P650RA laptop, running Ubuntu Xenial / 16.04 and the similar bug search when reporting a new bug led me to this issue.

The brightness keys do not work; setting the brightness manually through /sys/class/backlight/intel_backlight works fine.

Probably related: in the BIOS I can select either MSHYBRID or DISCRETE for the GPU, meaning either Optimus-like-technology or DISCRETE only. When using DISCRETE, the brightness keys do work. However, in that case I'm forced to use the Nouveau driver since the nvidia driver will not work anymore. And the nouveau driver makes this laptop crash after a short while, so it's not really a viable alternative.

When running in MSHYBRID, maybe there are more possible connected devices making this bug appear?

There's also some ACPI Warnings in DMESG that may be related. I'll attach the output of dmesg to this message.

Please let me know if I should report a new bug rather than necroposting in this old bug that appears to be resolved long ago. I'd be happy to provide more information if you point me in the right direction for obtaining that information.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.