Created attachment 55605 [details] [review]
If PCI subsystem matches VAIO VPCYA1V9E, try intel_backlight first

Created attachment 55606 [details]
Xorg.0.log, after applying attachment 55605 [details] [review]

Created attachment 55607 [details]
contents of all files under /sys/class/backlight

Created attachment 56261 [details]
contents of all files under /sys/class/backlight and /sys/class/dmi/id, after rebooting with acpi_backlight=vendor

Created attachment 56262 [details]
Xorg.0.log, without attachment 55605 [details] [review], with acpi_backlight=vendor

Created attachment 56263 [details]
xrandr --props, without attachment 55605 [details] [review], with acpi_backlight=vendor

Booting Linux 3.1.0 with acpi_backlight=vendor makes it omit /sys/class/backlight/acpi_video0 and instead provide /sys/class/backlight/sony.  As I reported in the Debug bug, /sys/class/backlight/sony/brightness is constantly -1.  The intel driver chooses to use that anyway, and ignores /sys/class/backlight/intel_backlight.

So... if you don't want to add the PCI subsystem check, perhaps you could instead add a brightness==-1 check.  That would be less convenient for users though because it would require the users to figure out they need to add the acpi_backlight=vendor parameter.

I also attached the files from /sys/class/dmi/id.  If you are afraid the PCI subsystem check can trigger on some computers where acpi_video0 works better than intel_backlight, you could perhaps check some of the DMI ID files instead.  The combination (sys_vendor, product_name, product_version, bios_vendor, bios_version) should have very little risk of false positives.  This would be more complex to implement than the PCI subsystem check, though.

I disassembled the ACPI DSDT (not attached) and don't see anything obviously wrong in the _BCL, _BCM, and _BQC methods.  _BCM seems to write the brightness level to the embedded controller all right; I guess the controller just doesn't do anything with the value.  These methods actually exist in two devices (\_SB.PCI0.GFX0.DD02 and \_SB.PCI0.P0P2.PEGP.LCD) but both sets are equivalent.

I'm expecting the same bug on my samsung NP-NC215-A01RU.
So checking only the vendor isn't a right way.
I believe that the best solution is to probe acpi_backlight only if other interfaces are broken.

Maybe I should open another bug or because it seems to be a cross-vendor problem it's better to rename this?

In reply to comment #7:

> I believe that the best solution is to probe acpi_backlight
> only if other interfaces are broken.

http://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight
says firmware interfaces should be preferred to raw interfaces if
they are for the same device, in order to reduce the risk of
confusion if the hardware alters the brightness too.  Because
acpi_video0 is a firmware interface and intel_backlight is a raw
interface, I think the xorg intel video driver should keep using
acpi_video0 by default.  Exceptions should be made for computers
on which these interfaces do not actually control the same
device, or where acpi_video0 does not work for some other reason.
The blacklist could initially be in the xorg intel driver.
Later, it could be moved to libbacklight or even to Linux.

> Maybe I should open another bug or because it seems to be a
> cross-vendor problem it's better to rename this?

I would prefer a separate bug, so that I'm free to close this one
if it becomes fixed by changes in Linux.  I don't know what the
maintainers prefer.  If you do rename this one, please consider
also renaming my attachments to make it clear which machine they
are from.

Hi,

If it doesn't work by adding some things like "acpi_backlight=vendor", "acpi_osi=linux" to the kernel parameters just like me, you can try the way below.

I think I found a easy and least effect to the existed things' way for adjusting intel_backlight using udev rules.
I noticed "change" action of "backlight" subsystem when I press Fn + PgUp/PgDn on my lenovo G360 + 3.2 Kernel notebook. So I wrote a rules of "/etc/udev/rules.d/99-writeintelbacklight.rules" as below:

    ACTION=="change", SUBSYSTEM=="backlight", RUN+="/usr/sbin/writeintelbacklight.sh"

A shell: "/usr/sbin/writeintelbacklight.sh"

    #!/bin/bash
    
    intelmaxbrightness=`cat /sys/class/backlight/intel_backlight/max_brightness`
    acpimaxbrightness=`cat /sys/class/backlight/acpi_video0/max_brightness`
    scale=`expr $intelmaxbrightness / $acpimaxbrightness`
    acpibrightness=`cat /sys/class/backlight/acpi_video0/brightness`
    newintelbrightness=`expr $acpibrightness \* $scale`
    curintelbrightness=`cat /sys/class/backlight/intel_backlight/actual_brightness`
    if [ "$newintelbrightness" -ne "$curintelbrightness" ]
    then
      echo $newintelbrightness > /sys/class/backlight/intel_backlight/brightness
    fi
    exit 0

Of course, you need do a "sudo chmod +x /usr/sbin/writeintelbacklight.sh"

Added "acpi_backlight=vendor acpi_osi=linux video.brightness_switch_enabled=1" into grub boot kernel parameters, "Fn + Up/Down" to change brigtness works on my G360. It's no need to write a Udev rules like above.

I tried the suggested Linux kernel parameters
"acpi_backlight=vendor acpi_osi=linux video.brightness_switch_enabled=1"
with Debian linux-image-3.2.0-2-amd64 (apparently derived from Linux 3.2.19)
and xserver-xorg-video-intel 2:2.19.0-1 on Sony VAIO VPCYA1V9E, to no avail.
The brightness key combos (Fn+F5 and Fn+F6) change the brightness
neither in the console nor in X, and "xrandr --props | grep -i
backlight" shows:

	BACKLIGHT: none(0) (format 0 items 0) ????
	Backlight: none(0) (format 0 items 0) ????

so it is not at all possible to change the brightness via X.
I get /sys/class/backlight/{sony,intel_backlight}/.  In sony,
max_brightness is 7, brightness can be changed but does not
affect the backlight, and actual_brightness is constantly -1.
In intel_backlight, max_brightness is 4882 like before, and
brightness can be changed and affects the backlight; but X does
not use it.

video.brightness_switch_enabled=1 appears to be the default anyway:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=a576575617d733f88960b849869fec4eb413f75d;hb=HEAD#l72

What can I do to help make the brightness control via RANDR work
by default on Sony VAIO VPCYA1V9E?  In case you are concerned
that the PCI subsystem check could trigger on too many models,
should I change the patch so it checks the DMI strings as well?

It appears from comment 9 that Linux 3.2 on lenovo G360 defaults to providing both /sys/class/backlight/intel_backlight and /sys/class/backlight/acpi_video0, only intel_backlight affects the actual display, and X uses acpi_video0.  As the situation is similar to what I have on Sony VAIO VPCYA1V9E, I'd like to extend the patch in attachment 55605 [details] [review] to recognize lenovo G360 as well. Even if Linux kernel parameters can work around the problem on lenovo G360, I think it will be more convenient for users if backlight control just works by default.

Can you please provide the following information on lenovo G360, so that I can make the driver reliably recognize it:

- PCI vendor ID (I presume it's 0x8086), device ID, revision, subsystem vendor ID, and subsystem device ID for the VGA compatible controller
- /sys/class/dmi/id/sys_vendor
- /sys/class/dmi/id/product_name
- /sys/class/dmi/id/product_version
- other /sys/class/dmi/id/* files if revealing them won't violate your privacy

Although I'll probably make the driver check only a few of those, it'll be good to have the full information here in the bug (and perhaps in source-code comments), to make it easy to tighten the checks later if the driver ends up using intel_backlight on any machine where acpi_video0 works fine.

It seems these two kernel parameters "acpi_osi=linux video.brightness_switch_enabled=1" has no affect on my brightness of backlight. I find the brightness adjusting can work when I add just only one kernel parameter "acpi_backlight=vendor" now. 

I have tried three kernel parameters combinations:
1, "acpi_osi=Linux acpi_backlight=vendor nomodeset", come from: Unable to change brightness in a Lenovo laptop http://askubuntu.com/questions/57236/unable-to-change-brightness-in-a-lenovo-laptop
2, "acpi_backlight=vendor acpi_osi=linux video.brightness_switch_enabled=1", come from: Bug 753012 - Backlight control does not work in Fedora 16 and Fedora 17. https://bugzilla.redhat.com/show_bug.cgi?id=753012
3, "acpi_backlight=vendor"

But, I found these adding kernel parameters methods can't work reliably, they will be invalid occasionly these days. I confirmed comination 1 above can't work about 4 times. Combination 2 or 3 can't work 1 or 2 times? I can't remember clearly. I will keep comination 3 ("acpi_backlight=vendor") now and see if it will be invalid one day.

Show the "dmi" information below:

me@debian:/sys/class/dmi/id$ for file in *; do if [ -f "$file" -a -r "$file" ]; then echo $file: `cat $file` ; fi; done
bios_date: 10/27/2011
bios_vendor: LENOVO
bios_version: 61CN06WW
board_asset_tag:
board_name: LL1
board_vendor: Lenovo
board_version: Rev 1.0
chassis_asset_tag: No Asset Tag
chassis_type: 10
chassis_vendor: Lenovo
chassis_version: Rev 1.0
modalias: dmi:bvnLENOVO:bvr61CN06WW:bd10/27/2011:svnLENOVO:pnG360:pvrRev1.0:rvnLenovo:rnLL1:rvrRev1.0:cvnLenovo:ct10:cvrRev1.0:
product_name: G360
product_version: Rev 1.0
sys_vendor: LENOVO
uevent: MODALIAS=dmi:bvnLENOVO:bvr61CN06WW:bd10/27/2011:svnLENOVO:pnG360:pvrRev1.0:rvnLenovo:rnLL1:rvrRev1.0:cvnLenovo:ct10:cvrRev1.0:

My notebook comes with OEM Windows 7 Home Editition, it has two video cards which called "NVIDIA Optimus technology". But only Intel card affect backlight. 

I "sudo modprobe nvidia" and "sudo lspci -v" show the information below:

me@debian:/sys/class/dmi/id$ sudo lspci -v
...(omit)

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 3920
	Flags: bus master, fast devsel, latency 0, IRQ 42
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 1800 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

...(omit)

01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce 310M] (rev a2) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 3968
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at ac000000 (32-bit, non-prefetchable) [size=16M]
	Memory at b0000000 (64-bit, prefetchable) [size=256M]
	Memory at ae000000 (64-bit, prefetchable) [size=32M]
	I/O ports at 2000 [size=128]
	[virtual] Expansion ROM at ad000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [b4] Vendor Specific Information: Len=14 <?>
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Kernel driver in use: nvidia

...(omit)

Good luck, I confirmed that adding only one kernel parameter "acpi_backlight=vendor" the brightness adjusting will still stop work occasionly at several minutes ago.
I execute "sudo udevadm monitor", when press brightness adjusting key(Fn + Up/Down), it shows:
KERNEL[1340112432.273868] change   /devices/platform/ideapad/backlight/ideapad (backlight)
UDEV  [1340112432.274325] change   /devices/platform/ideapad/backlight/ideapad (backlight)
KERNEL[1340112432.336575] change   /devices/platform/ideapad/backlight/ideapad (backlight)
UDEV  [1340112432.337083] change   /devices/platform/ideapad/backlight/ideapad (backlight)
Both the content of "/sys/class/backlight/ideapad/brightness" and "/sys/class/backlight/intel_backlight/brightness" are unchanged. 

After I reboot my notebook again, the backlight brightness adjusting by press Fn + Up/Down works again. "sudo udevadm monitor" shows:
KERNEL[1340113538.708113] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight (backlight)
UDEV  [1340113538.708561] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight (backlight)
KERNEL[1340113538.770948] change   /devices/platform/ideapad/backlight/ideapad (backlight)
UDEV  [1340113538.771384] change   /devices/platform/ideapad/backlight/ideapad (backlight)
The content of "/sys/class/backlight/ideapad/brightness" is unchanged while the content of "/sys/class/backlight/intel_backlight/brightness" is changed when I press brightness adjusting keys.

Before I add "acpi_backlight=vendor", there are two folders under "/sys/class/backlight", they are "acpi_video0" and "intel_backlight"; After add "acpi_backlight=vendor", "acpi_video0" disappeared, it becomes "ideapad".

My OS is Debian squeeze with backports kernel, "uname -a" shows "Linux debian 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012 x86_64 GNU/Linux
"

"sudo modprobe nvidia" and "sudo lspci -n -v" shows VGA information:
 
00:02.0 0300: 8086:0046 (rev 18) (prog-if 00 [VGA controller])
	Subsystem: 17aa:3920
	Flags: bus master, fast devsel, latency 0, IRQ 42
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 1800 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

01:00.0 0300: 10de:0a70 (rev a2) (prog-if 00 [VGA controller])
	Subsystem: 17aa:3968
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at ac000000 (32-bit, non-prefetchable) [size=16M]
	Memory at b0000000 (64-bit, prefetchable) [size=256M]
	Memory at ae000000 (64-bit, prefetchable) [size=32M]
	I/O ports at 2000 [size=128]
	[virtual] Expansion ROM at ad000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [b4] Vendor Specific Information: Len=14 <?>
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Kernel driver in use: nvidia

Debian package "xserver-xorg-video-intel" version: 2:2.13.0-6
Debian package "xserver-xorg" version: 1:7.5+8+squeeze1
Debian package "libgl1-mesa-dri" version: 7.10.3-4~bpo60+1
Debian package "libdrm2" version: 2.4.26-1~bpo60+1

All the packages are outdated. I don't know if it is helpful for the question.

Created attachment 63948 [details] [review]
If PCI subsystem and DMI IDs match VAIO VPCYA1V9E or LENOVO G360, try intel_backlight first

Differences from the previous version (attachment 55605 [details] [review]):
- This patch is against the xorg intel driver v2.19.0.
- Also compares sys_vendor, product_name, and product_version from DMI.
  This should minimize the risk of false positives, but the code
  necessarily becomes more complex, with a higher risk of bugs
  and coding-style violations.
- Also recognizes LENOVO G360 as reported by Dashing Meng in comment 13.

Tested on VAIO VPCYA1V9E with Debian xserver-xorg 1:7.6+13 and linux-image-3.2.0-2-amd64 3.2.20-1.

This bug was moved from xorg Driver/intel to DRI DRM/Intel.  Does that mean it should be fixed in the Linux kernel, rather than in user space?  I did not find any related discussion in the intel-gfx mailing list archives.

X does little more than request the kernel to change the backlight. Whether or not that happens is up to the ACPI gods with a smattering of bugs in i915.ko, but the kernel driver is a step closer.

This bug here is a bit confusing, but it sounds like the backlight control exposed by the kernel is working properly (at least on recent enough kernels). Hence closing as fixed.

xrandr --set still does not affect the backlight hardware, with Debian xserver-xorg-video-intel 2:2.19.0-5 and upstream Linux v3.6-rc3 on Sony VAIO VPCYA1V9E.  Applying the patch in https://bugzilla.kernel.org/show_bug.cgi?id=43168#c15 does not help.  The later patch in https://bugzilla.kernel.org/show_bug.cgi?id=43168#c23 was already applied.  I did not test with ea9f8856bd6 reverted, because it does not revert cleanly from v3.6-rc3.

I believe the bug is in firmware or hardware: ACPI DSDT claims it can change the brightness, but it doesn't really work, even though the values set in this way can be read back.  I have not found a BIOS update from Sony (http://www.sony.fi/support/fi/product/VPCYA1V9E_B/updates), and I don't know if I'd even be able to install one without Windows.  So, I would appreciate a workaround in Linux or X.  Attachment 63948 [details] is such a workaround for X, but you say you'd rather have this done in Linux.

* You marked this bug as fixed.  Can you please tell me where to find a version on Linux that includes the fix?
* If there is no such fix yet, should I report this problem somewhere else?
* Attachment 63948 [details] does solve the problem on my machine.  Do you think it could have unwanted side effects on other machines?  If not, I'd like to convince the Debian maintainer to apply it until there is a fix in Linux.

I upgraded Linux to 3.6.0, which was released a month after comment 18 and should be recent enough.  With that and Debian xserver-xorg-video-intel 2:2.19.0-5, I still cannot control the brightness via RANDR.  The symptoms are as I originally reported.  Hence reopening.

The problem is that both the userspace intel driver and the kernel driver work as advertised. The issue at hand is that your acpi driver gets in the way (since we assign it higher priority than the intel native backlight driver only used as a last-resort fallback driver). But the acpi driver doesn't work at all.

You need to file this against the backlight driver of your platform (either acpi or some platform-specific thing) in the kernel bugzilla at bugs.kernel.org. Thanks anyway for reporting this issue here.