On a Sony VAIO VPCYA1V9E laptop, the LCD backlight brightness set with xrandr --set does not affect the actual backlight. Linux 3.1.0 offers both /sys/class/backlight/acpi_video0 and /sys/class/backlight/intel_backlight. Of these, only intel_backlight actually works, but the xorg intel driver chooses to use acpi_video0.
Chipset: lspci shows device 8086:0046 with subsystem 104d:907c
System architecture: x86_64
xf86-video-intel version: 2.17.0 (Debian xserver-xorg-video-intel 2:2.17.0-1)
xserver version: X.Org X Server 1.11.2.902 (1.11.3 RC 2) (Debian xserver-xorg-core 2:1.11.2.902-1)
mesa version: 2.1 Mesa 7.11.2 (Debian libgl1-mesa-dri 7.11.2-1)
libdrm version: 2.4.29 (Debian libdrm2 2.4.29-1)
More details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741
Please make the intel driver use /sys/class/backlight/intel_backlight on this laptop model. I am not sure what is the best way to recognize the model, but I made a patch that checks the PCI subsystem ID, and it works in my computer at least.

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"

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.

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.

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.