[ASUS-A7K laptop] screen brightness dimmed after kernel update
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xserver-xorg-driver-radeonhd |
Confirmed
|
Medium
|
|||
linux (Ubuntu) |
Incomplete
|
Low
|
Unassigned |
Bug Description
Hello,
Following the update from kernel version 3.13.0-34 to 3.13.0-35-generic the screen brightness got a lot dimmer.
The Fn+F5/F6 control keys still work, in that the display gets dimmer and brighter, but the maximum brightness is too low.
When starting ubuntu using the previous kernel release the display brightness is alright.
I've looked around the web for ways to change the display brightness and I checked that both files "/sys/class/
The release I am running is : Ubuntu 14.04.1 LTS
The XORG package version is : 1:7.7+1ubuntu8
Please feel free to contact me for any further information.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xorg 1:7.7+1ubuntu8
ProcVersionSign
Uname: Linux 3.13.0-35-generic x86_64
.tmp.unity.
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
CompizPlugins: No value set for `/apps/
CompositorRunning: None
CurrentDesktop: GNOME
Date: Sun Aug 31 11:40:07 2014
DistUpgraded: Fresh install
DistroCodename: trusty
DistroVariant: ubuntu
ExtraDebuggingI
GraphicsCard:
Advanced Micro Devices, Inc. [AMD/ATI] RV630/M76 [Mobility Radeon HD 2600] [1002:9581] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:1562]
InstallationDate: Installed on 2014-07-24 (38 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
MachineType: ASUSTeK Computer Inc. A7K
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_
LANG=fr_FR.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/25/2007
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: A7KAS.2
dmi.board.
dmi.board.name: A7K
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: A7K
dmi.product.
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.11.
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.
version.
version.
version.
version.
version.
version.
version.
xserver.bootTime: Sun Aug 31 11:06:06 2014
xserver.configfile: default
xserver.errors:
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.15.1-0ubuntu2
xserver.
Changed in xserver-xorg-driver-radeonhd: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Created attachment 102847
dmesg
I log in as root on a text virtual console.
After about 10 minutes screen blanks.
Surprisingly, pressing a key does *not* unblank the screen!
Machine is still alive (I can ssh into it), and typed keys even reach the console: I can type e.g. "ls -lR /usr" and I see disk indicator blinking, ls process is visible in the ps in ssh session, etc.
This does not happen in X.
This is observed on Lenovo T60, on RHEL7 kernel and also on recent upstream kernel 3.15.5.
Investigation had revealed that VT unblanking code, after all the hard work it done to turn display back on, calls ATOM_LCD_BLOFF (backlight off, numeric value 2) function.
Digging further, I discovered that fb_blank(blank=0) almost at its end calls fb_notifier_ call_chain( FB_EVENT_ BLANK). Which calls backlight. c::fb_notifier_ callback( ), which tries to set brightness via radeon_ atom_backlight_ update_ status( ), which does set_backlight_ level(radeon_ atom_bl_ level() ), but radeon_ atom_bl_ level() is zero (it's an uint8_t, brightness level). So it's essentially atombios_ set_backlight_ level(0) and it switches backlight off.
atombios_
In drivers/ gpu/drm/ radeon/ *, bd->props. brightness, surprisingly, is only set in radeon_ atom_backlight_ init() and radeon_ legacy_ backlight_ init(), all other locations are only reading it. So, if this init code sets it to 0, then VT unblanking code will use this zero value as brightness to restore, causing this bug.
And indeed, that's what happens on the machine exhibiting this bug:
[ 2.301563] radeon_ atom_get_ backlight_ level_from_ reg: RADEON_ BIOS_2_ SCRATCH atom_get_ backlight_ level_from_ reg: bios_2_ scratch: 00000000 atom_backlight_ init: bd->props. brightness= 0 atom_backlight_ update_ status: atombios_set_back
[ 2.301633] radeon_
[ 2.301704] radeon_
[ 2.301780] radeon_
The full dmesg of the RHEL7 boot with many debug printks added is attached. (Sorry, I started debugging it on RHEL7, I believe mainline does not differ significantly).
It shows the following: After "setterm -blank 1 && sleep 60", VT blanking triggers at ~362 seconds, and at ~370 seconds VT is trying to unblank because of keyboard activity. The bug is evident here:
[ 370.852058] fb_blank: fb_notifier_ call_chain( FB_EVENT_ BLANK). .. blanked( blank:0) screen( 0) video/backlight /backlight. c:fb_notifier_ callback: backlight_ update_ status( ) atom_backlight_ update_ status: atombios_ set_backlight_ level() atom_bl_ level: level = bd->props. brightness: 0 set_backlight_ level(level: 0) set_backlight_ level: atom_execute_ table(ATOM_ LCD_BLOFF) ^^^^^^^ ^^^^^^ THIS TURNS OFF DISPLAY ^^^^^^^^^^^^^^^^^ table_locked( index:23, *params: ffff8802) returns 0 video/backlight /backlight. c:fb_notifier_ callback: backlight_ update_ status( )
[ 370.852061] fbcon_event_notify: case FB_EVENT_BLANK: fbcon_fb_
[ 370.852063] fbcon_fb_blanked: do_unblank_
[ 370.852064] do_unblank_screen: entered on cpu 0
[ 370.852066] do_unblank_screen: !console_blanked on cpu 0
[ 370.852068] backlight: drivers/
[ 370.852071] radeon_
[ 370.852072] radeon_
[ 370.852074] atombios_
[ 370.852077] atombios_
^^^^^^^
[ 370.852083] atom_execute_
[ 370.852085] backlight: drivers/
[ 370.852940] fb_blank returns 0
[ 370.852942] fbcon_blan...