| View previous topic :: View next topic |
| Author |
Message |
Zvonimir
n00b
Joined: 26 Jul 2013
Posts: 6
|
 Posted: Thu Oct 03, 2013 4:47 pm Post subject: Peculiar brightness behaviour after kernel upgrade [SOLVED] |
 |
|
Hello!
I am starting to explore Gentoo. Recently, after upgrading my kernel from the 3.3.8 version to the 3.10.7 one, I came across a problem with brightness during boot. My Gentoo system runs on Acer Aspire One D270, with Intel Atom N2600 processor and integrated Intel GMA 3600 graphics processing unit. I am using Fluxbox as window manager and SLiM as login manager.
Right after I press the power button, the brightness value resets to maximum 100. So I created the (executable) file named "brightness.start" (containing the command 'setpci -s "00:02.0" F4.B=5') in /etc/local.d/, to automatically lower the brightness during boot.
In the 3.3.8-kernel the brightness did indeed reduce from maximum value 100 to value 5. And this value always stayed unchanged after the login.
In the 3.10.7-kernel, however, the value drops from 100 to 5 after initscript "local" initializes (just like in the 3.3.8 kernel), but right before the SLiM login screen appears, the brightness value changes back to maximal 100. At that point, there is no visible output on my screen, so I don't know what resets the brightness value back to maximum.
I checked the SLiM config file, but didn't find anything that could (in my opinion) influence the brightness value.
Does anybody have an idea what could it be and how could I fix this inconvenience? Could it be that the newer kernel version controls my monitor brightness differently? I searched this forum and some other places for a solution that could help me, but to no avail.
Any suggestions (regarding the solution to the problem or about additional information I should give to clarify my problem) are very welcome and appreciated.
Last edited by Zvonimir on Sat Oct 05, 2013 2:15 pm; edited 1 time in total |
|
| Back to top |
|
 |
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Fri Oct 04, 2013 11:10 pm Post subject: |
|
|
| Maybe the kernel has gained support for your backlight in the meantime? If CONFIG_ACPI_VIDEO and CONFIG_BACKLIGHT_CLASS_DEVICE are enabled in the kernel, check if you can control the backlight via /sys/class/backlight/. |
|
| Back to top |
|
|
Zvonimir
n00b
Joined: 26 Jul 2013
Posts: 6
|
| Posted: Sat Oct 05, 2013 8:56 am Post subject: |
|
|
Thank you for your reply chithanh.
| chithanh wrote: | | Maybe the kernel has gained support for your backlight in the meantime? |
This certainly appears to be true. Do you know maybe how I could check this?
As one rather simple example, in the previous kernel version, I manually linked the "Fn+Left" and "Fn+Right" button combinations to a script that increases/decreases backlight (because there was no combination I could press on the keyboard to do that). The new kernel sets this up by default (so I had to remove my key bindings, to avoid redundancy which caused some strange effects). So, in short, something is definitely different in the way the two kernel versions control my backlight (and keyboard).
| chithanh wrote: | | If CONFIG_ACPI_VIDEO and CONFIG_BACKLIGHT_CLASS_DEVICE are enabled in the kernel, check if you can control the backlight via /sys/class/backlight/. |
CONFIG_ACPI_VIDEO and CONFIG_BACKLIGHT_CLASS_DEVICE are enabled in both kernel versions, and also in both, I can control the backlight by, for example, typing 'echo 5 > /sys/class/backlight/psb-bl/brightness' as root.
To track down the reason for the automatic increase of backlight value just before the SLiM login window, I also checked the initscripts I have enabled, but didn't find anything that I would recognize as a backlight controling parameter. Since I lack experience with Gentoo, I would like to ask you, whether some of the initscripts from the list might be responsible for the backlight intensity increase (acpid and xdm look like suspects to me, but like I said, I didn't find anything).
| Code: |
# rc-update show
acpid | default
alsasound | boot
bootmisc | boot
devfs | sysinit
dmesg | sysinit
fsck | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
local | boot
localmount | boot
modules | boot
mount-ro | shutdown
mtab | boot
net.lo | boot
net.wlan0 | default
netmount | default
procfs | boot
root | boot
savecache | shutdown
swap | boot
swapfiles | boot
sysctl | boot
sysfs | sysinit
syslog-ng | default
termencoding | boot
tmpfiles.setup | boot
udev | sysinit
udev-mount | sysinit
urandom | boot
xdm | default
|
|
|
| Back to top |
|
|
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Sat Oct 05, 2013 10:07 am Post subject: |
|
|
I could be that the kernel stores the backlight state somewhere and starting X triggers a write of that state to the PCI register.
Does the change in brightness also happen if you don't use setpci but /sys/class/backlight instead to set the initial brightness? |
|
| Back to top |
|
|
Zvonimir
n00b
Joined: 26 Jul 2013
Posts: 6
|
| Posted: Sat Oct 05, 2013 2:10 pm Post subject: |
|
|
| chithanh wrote: | | I could be that the kernel stores the backlight state somewhere and starting X triggers a write of that state to the PCI register. |
Exactly.
| chithanh wrote: | | Does the change in brightness also happen if you don't use setpci but /sys/class/backlight instead to set the initial brightness? |
In order to automatically lower backlight during boot time, I created the file /etc/local.d/brightness.start following instructions from http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4 and put the following line in this file
| Code: | | setpci -s "00:02.0" F4.B=5 |
Following your advice, I replaced that line with
| Code: | | echo 5 > /sys/class/backlight/psb-bl/brightness |
and the backlight value lowered to 5 as planned and didn't change afterwards during boot. The problem is solved.
I guess the problem occurred due exactly to the thing you pointed out above. Namely, setpci changes backlight, but doesn't change the value in /sys/class/backlight/psb-bl/brightness (i.e. this value stays maximal) and when X loads, it looks in /sys/class/backlight/psb-bl/brightness for backlight value and brings it back to maximum (so it seems). Somehow, setpci -s "00:02.0" F4.B=5 and /sys/class/backlight/psb-bl/brightness do not depend on each other, but control the same thing. Gives me something to read about.
chithanh, thank you very much for your help! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
