You can give yourself the permission to write to /sys/class/backlight/*
, or add a sudo rule to modify the file. That's what I did when I had a computer with an i915 GPU.
For example, add something like the following code to /etc/rc.local
:
chgrp -R backlighters /sys/class/backlight
chmod g+w /sys/class/backlight/*/*
and add yourself to the backlighters
group. If you want to give the permission to the user who's logged in on the console, that's harder, I think you'd have to hook into polkit and even then it's awkward because sysfs doesn't support ACL.
There can be numerous reason why this doesn't work, and they are all to complicated to ask in a comment to the question, so I'll leave this as a resource here - and if none of these work feel free to comment rather than down-voting and I'll remove it (or leave for others who end up here with the same problem but different causes).
The first thing you can try is adding one of these kernel parameters:
acpi_osi=Linux
acpi_osi="!Windows 2012"
acpi_osi=
This is a pretty common issue where the backlight stops working after a suspend (I know this isn't directly related, but might be worth mentioning).
Another issue might be that you're lacking sufficient permission to actually modify the brightness (again, probably not related to OP since the error message is usually different and OP has already tried it). If that's the case, modify the udev-rules by changing/adding this to /etc/udev/rules.d/backlight.rules
:
ACTION=="add", SUBSYSTEM=="backlight", KERNEL=="intel_backlight", RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness"
ACTION=="add", SUBSYSTEM=="backlight", KERNEL=="intel_backlight", RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"
Another, also common issue, is when used in conjunction with multiple graphic cards or hybrid graphics (like the Optimus project).
If so, you can try to add one of the following kernel parameters:
acpi_backlight=video
acpi_backlight=vendor
acpi_backlight=native
acpi_backlight=none # <-- Mainly for AMD/ATI drivers
Finally, what OP might be here for:
Change /etc/X11/xorg.conf.d/20-intel.conf
to reflect:
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "Backlight" "intel_backlight"
EndSection
Odds are xrandr or xbacklight have just got a faulty mapping against /sys/class/backlight/<path>
. Thus, manually setting it to intel_backlight
might solve your issue. All that might be wrong is the Identifier, judging by the question. If it still doesn't work, verify and make sure that the Device-config is actually the one in use, because it really sounds like a mapping issue between xrandr/xbacklight and the path where it thinks it'll find the backlight-directory.
Any of these might give you a clue or hint as to which driver and config is being used:
lspci | grep VGA
lsmod | grep "kms\|drm"
find /dev -group video
cat /proc/cmdline
find /etc/modprobe.d/
cat /etc/modprobe.d/*kms*
glxinfo | grep -i "vendor\|rendering"
grep LoadModule /var/log/Xorg.0.log
egrep -i " connected|card detect|primary dev|Setting driver" /var/log/Xorg.0.log
udevadm info -a -p /sys/class/backlight/intel_backlight/
I hope it's as simple as this; if it's not, again, I'd be happy to change my answer or delete it all together. Just sharing some knowledge gathered while struggling with the same thing. bugs.debian.org issue
Oh, and the kernel parameter nomodeset
tends to interfere with backlight settings. I don't know why. But if whoever ends up here uses it, try to remove that and see if at least the backlight kicks in again.
Best Answer
Arch Linux has the following to say about xbacklight:
The following worked for me on Debian Stretch LXDE.
Checked the backlight directory:
ls /sys/class/backlight
. I happen to haveintel_backlight
.To get the Identifier, I ran
xrandr --verbose
. Mine happened to be0x72
.Checking
/etc/X11/
, I found noxorg.conf
, so I made my own and entered the information I had found:I then rebooted. It worked from there.
Since LXDE runs openbox, I edited
~/.config/openbox/lxde-rc.xml
and inserted the following keybindings: