[Asus X200MA] Brightness keys don't work.

Bug #1651629 reported by Matthew Brooks
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Fn + F5 or F6 is supposed to lower or raise the brightness respectively. By default, nothing happens when pushing the buttons.Editing the grub config to add "acpi_osi=" to the kernel command line seems to make the buttons get recognized, and the brightness popup displays, but the actual brightness doesn't change.

WORKAROUND: Pipe a number into "/sys/class/backlight/intel_backlight/brightness", or use the brightness slider that shows up in the drop-down from the Gnome status bar.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: linux-image-4.8.0-32-generic 4.8.0-32.34
ProcVersionSignature: Ubuntu 4.8.0-32.34-generic 4.8.11
Uname: Linux 4.8.0-32-generic x86_64
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: alicethegorgon 1381 F.... pulseaudio
CurrentDesktop: GNOME
Date: Tue Dec 20 20:53:38 2016
HibernationDevice: RESUME=UUID=563d2c5e-63fe-4f34-b709-343b0d736c48
InstallationDate: Installed on 2016-12-21 (0 days ago)
InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Release amd64 (20161012.1)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
 Bus 001 Device 003: ID 0bda:5605 Realtek Semiconductor Corp.
 Bus 001 Device 002: ID 0457:1029 Silicon Integrated Systems Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: ASUSTeK COMPUTER INC. X200MA
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-32-generic.efi.signed root=UUID=2ead8d38-6489-4a46-848c-77ea3d7e2ef8 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.8.0-32-generic N/A
 linux-backports-modules-4.8.0-32-generic N/A
 linux-firmware 1.161.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/11/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: X200MA.502
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: X200MA
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX200MA.502:bd09/11/2014:svnASUSTeKCOMPUTERINC.:pnX200MA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX200MA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: X200MA
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

Revision history for this message
Matthew Brooks (vectormatt) wrote :
Revision history for this message
penalvch (penalvch) wrote :

Matthew Brooks, thank you for reporting this and helping make Ubuntu better.

In order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

It is most helpful that after testing of the latest upstream kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.

tags: added: bios-outdated-506
Changed in linux (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
description: updated
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-4.9
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
penalvch (penalvch)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Matthew Brooks (vectormatt) wrote :

Sorry about that, I thought I was already on 506 for some reason.

I updated to 506, and tested with the 4.9 kernel, and the issue still persists.

The output from the commands was:

X200MA.506
04/15/2015

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: latest-bios-506
removed: bios-outdated-506
Revision history for this message
penalvch (penalvch) wrote :

Matthew Brooks, to clarify, does using both of the following kernel parameters provide a WORKAROUND:
acpi_os_name=Linux acpi_osi=

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Matthew Brooks (vectormatt) wrote :

That does not make the brightness keys work, unfortunately.

Using those causes the keys to be recognized by the system, and the popup showing the brightness level will come up and indicate that the brightness is being changed, but the actual screen brightness doesn't get changed.

Using those parameters also makes the Gnome brightness slider stop changing the brightness.

Piping a number to the /sys/class/backlight/intel_backlight/brightness file still actually changes the brightness when using those parameters, the same as it does without them.

Revision history for this message
Matthew Brooks (vectormatt) wrote :

Since I forgot to add this before posting, I should specify that I made sure to test those parameters with the mainline 4.9 kernel, and not just the standard Ubuntu one.

Both gave the same results.

Revision history for this message
penalvch (penalvch) wrote :

Matthew Brooks, could you please advise if a WORKAROUND exists via https://wiki.ubuntu.com/Kernel/Debugging/Backlight ?

summary: - [Asus X200M] Brightness keys don't work.
+ [Asus X200MA] Brightness keys don't work.
Revision history for this message
Matthew Brooks (vectormatt) wrote :

Booting with "acpi_backlight=vendor", the brightness keys do nothing, and the gnome brightness slider breaks.

The /sys/class/backlight/intel_backlight/brightness file still works.
I don't know if it's important, but the "max_brightness" is 7812, which might be an unusual range. Setting brightness to 8, as recommended by the workaround steps, makes the screen way too dark to see anything. I usually have it at about 4000 or so.

Anyway, I'm attaching the "vendorbacklight" and "lslabacklight" files that where generated, and I'm going to test the atkbd.softraw-0 parameter next. I'll report back with it's results.

Revision history for this message
Matthew Brooks (vectormatt) wrote :
Revision history for this message
Matthew Brooks (vectormatt) wrote :

With just "video.use_bios_initial_backlight=0", the brightness keys do nothing, and the gnome brightness slider works.

With just "acpi_osi=", the brightness keys are recognized, and the brightness meter changes, but the actual screen brightness doesn't change at all. The gnome brightness slider also doesn't change the brightness when using this parameter.

With just "atkbd.softraw=0", "showkey -s" produces no output when pressing the backlight keys.

Revision history for this message
Matthew Brooks (vectormatt) wrote :

Using "acpi_backlight=vendor" and also creating the "80-backlight.conf" file with the contents shown on that page, results in the brightness keys still doing nothing, and the gnome brightness slider not working.

The /sys/class/backlight/intel_backlight/brightness file still works fine though.

I think that's everything in the workaround section there. But let me know if there's anything else I need to check or anything.

Revision history for this message
penalvch (penalvch) wrote :

Matthew Brooks, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate mailing list (TO Rafael J. Wysocki and Len Brown CC linux-acpi)?

Please provide a direct URL to your post to the mailing list when it becomes available so that it may be tracked.

Thank you for your help.

Changed in linux (Ubuntu):
status: Incomplete → Triaged
Revision history for this message
Matthew Brooks (vectormatt) wrote :

Okay, I've sent the report. I'll keep an eye on the mailing list archives and post a link when it's added there.

Revision history for this message
Matthew Brooks (vectormatt) wrote :

Okay, the archive has it, and it's here:
https://www.spinics.net/lists/linux-acpi/msg71030.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.