Hi, This is my first time filing a kernel bug, so I may have gotten a few things wrong. My problem is as follows: When I switch to a tty from my graphical environment (tty7 -> tty1), the brightness resets to maximum. However when I switch back to the graphical environment (tty1 -> tty7), the brightness returns to the level it was before, but the graphical environment is frozen for a few seconds. I use LXDM display manager and Xfce graphical environment. The reason I think its a kernel bug is because I dont have it when using the 3.10 kernel. Here are some outputs: $ uname -a Linux manjaro 3.14.28-1-MANJARO #1 SMP PREEMPT Fri Jan 9 00:09:19 CET 2015 x86_64 GNU/Linux $ tree /sys/class/backlight/ /sys/class/backlight/ └── intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight 1 directory, 0 files inxi output (contains system information) http://paste2.org/nyzW04I5 dmesg.log (there is no change in dmesg output before and after switching) http://paste2.org/wULdjyF7 Xorg.0.log http://paste2.org/ZMnHbEfh lxdm.log http://paste2.org/2POUPyaf lspci -vnn http://paste2.org/JKAUtaMg Here are the patches applied to the kernel https://github.com/manjaro/packages-core/tree/master/linux314 If I have missed something please let me know. Regards, Aaditya
This is on a laptop with only an inbuilt graphics card, Intel HD 4000
Enable debug for backlight module like this: # cd /sys/kernel/debug/dynamic_debug # echo "module backlight +pft" > control Then do the tty switch, see if there is anything appeared in the dmesg log. The log should tell us which process ID is doing the backlight level change. Check with ps -elf to see which command it is.
BTW, since it is a regression, it would be very useful to find out the offending commit with git bisect.
Thx for the help Aaron. After performing the commands you posted, the following appeared in the dmesg log: [ 842.091059] [14849] bl_power_store: backlight: set power to 4 [ 842.091080] [14849] brightness_store: backlight: set brightness to 0 [ 842.358150] [14849] brightness_store: backlight: set brightness to 327 [ 844.860448] [14849] brightness_store: backlight: set brightness to 327 [ 844.860585] [14849] bl_power_store: backlight: set power to 0 For ps -elf I guess the following is what you mean: 4 R root 14849 14843 1 80 0 - 98107 - 14:09 tty7 00:01:35 /usr/bin/Xorg.bin :0 vt07 -nolisten tcp -novtswitch I am not sure if I am skilled enough to do a git bisect (never done one before).
Hi, Some more info on this: The reason I had suspected that this was regression was that I am using kernel 3.14.24 on Slackware where I do not have this issue. So I decided to compile 3.14.24 on this system (Manjaro) using [1], rebooted, and the bug was present there as well; so it may be a kernel + userspace issue. [1]: https://github.com/manjaro/packages-core/archive/c62a6498951fb5626fbc0badd560406388dff542.zip
Yes, it does seem to be related to userspace, especially Xorg, since the brightness level change request is sent from Xorg when you switch from X to virtual console. Add Jani, who may have some idea what happened here.
I tried kernel 3.18 as part of another bug report I filed [1], so it may have been solved I guess. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=91771
Some more updates: This issue occured on Slackware as well when I upgraded Xorg from 1.14.3 to 1.15.2, and I also tried Ubuntu 14.04.2 which uses Xorg server >= 15.0, so I believe it is caused due to some change in Xorg. On Slackware the kernel I am using is 3.18.9, while in Ubuntu it was 3.16.x. I will try filing a bug with the Xorg guys about this.
Seems to be fixed now. https://bugs.freedesktop.org/show_bug.cgi?id=89973#c1
Thanks for the report and the follow-up. Please reopen if the problem persists.