8086:0416 [Clevo W350ST] brightness keys don't work on Kubuntu

[Surak]

The Fn+F8 and Fn+F9 keys are not working on my Clevo W350ST with Kubuntu Raring to change screen brightness of the internal laptop screen. I installed linux-headers-3.11.0-4, linux-headers-3.11.0-4-generic, linux-image-3.11.0-4-generic and linux-image-extra-3.11.0-4-generic from Saucy packages repository but the problem persists. Edit: Bug persists with v3.13-rc6-trusty.

When trying the following event codes appear correctly:
xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
keycode 36 = (keysym 0xff0d, Return), state = 0x10
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x10
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x10

And changing:
/sys/class/backlight/intel_backlight/brightness

changes the brightness of the screen, but pressing the key combination does not. I believe this happens because the key combination is, in fact, changing the value of:
/sys/class/backlight/acpi_video0/brightness

I have in my package sources:
http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu
http://ppa.launchpad.net/bumblebee/stable/ubuntu

WORKAROUND: acpi_backlight=vendor
(but this breaks autoswitch to external monitor when connecting one to VGA port)

---
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: silvio 2689 F.... pulseaudio
 /dev/snd/pcmC1D0p: silvio 2689 F...m pulseaudio
 /dev/snd/controlC0: silvio 2689 F.... pulseaudio
DistroRelease: Ubuntu 13.04
HibernationDevice: RESUME=UUID=58f7acf2-4914-4b11-a2ac-e641cb4b39fd
InstallationDate: Installed on 2013-08-18 (57 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Notebook W350STQ/W370ST
MarkForUpload: True
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-9-generic root=UUID=f0bca002-701a-49bb-befc-7343bac2e245 ro locale=pt_BR quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.11.0-9.16-generic 3.11.2
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-9-generic N/A
 linux-backports-modules-3.11.0-9-generic N/A
 linux-firmware 1.106
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
Tags: raring
Uname: Linux 3.11.0-9-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lp lpadmin plugdev sambashare sudo vboxusers
dmi.bios.date: 04/11/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4.6.5
dmi.board.asset.tag: Tag 12345
dmi.board.name: W350STQ/W370ST
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: Notebook
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/11/2013:svnNotebook:pnW350STQ/W370ST:pvrNotApplicable:rvnNotebook:rnW350STQ/W370ST:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
dmi.product.name: W350STQ/W370ST
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1218547/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Quinn Balazs (qbalazs)]

Would you mind attaching the resultant log of the following: "udevadm info --export-db > udev-db.txt"

[Surak (smkozasa)]

Thanks for your attention. I've forgotten to mention that Clevo W350ST uses Haswell chipset with embedded Intel HD4000 and Optimus capable GTX 765M. I suppose that's why there are 2 devices under /sys/class/backlight.

I have attached the resulting udev-db.txt.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Roger Samsó (rogersamso)]

Exact same situation. Also with

http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu
http://ppa.launchpad.net/bumblebee/stable/ubuntu

in the sources

[Quinn Balazs (qbalazs)]

Would you mind removing the PPAs, and seeing if this issue is still present? If the issue is resolved after removing the PPAs, you will have to bring this to the attention of the maintainers of those specific PPAs. Due to the fact that PPAs are not from the official repositories, they are not officially supported, and any bugs found are the sole responsibility of the PPA maintainer(s).

Quinn Balazs

[Quinn Balazs (qbalazs)]

This seems to be an issue with bumblebee, that hasn't been brought up with the PPA maintainers yet. See bug #1226317. If the issues are cleared up after removing bumblebee, please mark this report as invalid and bring the issue up with the Bumblebee Project (https://launchpad.net/~bumblebee).

[Surak (smkozasa)]

I did a clean boot with Kubuntu Raring 13.04 64 bits Live DVD. The problem persists exactly the same:

The Fn keys change the value of

/sys/class/backlight/acpi_video0/brightness

but to change laptop internal screen brightness, it should be changing the value of

/sys/class/backlight/acpi_video0/brightness

When I changed this last one, the screen brightness changed accordingly.

So, I believe this is NOT a bumblebee issue and it seems to be happening only with the Haswell chipset, since I have not found any complains from users with older chipsets using bumblebee or not. After all, it still happens with a clean boot from the Live DVD.

Unfortunately, I have no idea what package should be handling this. Maybe KDE itself or LightDM?

Thanks in advance.

[Quinn Balazs (qbalazs)]

Looking back at your last comment, this sounds like the core of the issue is that there are two interfaces present that are trying to control brightness. Could you try booting with the kernel boot parameter of "acpi_backlight=vendor" which should disable acpi_video0 leaving intel_backlight. Does this improve the issue, or cause additional problems? Also, now that I've set a package please run "apport-collect bug#" so that any logs that may be relevant get attached here. If "acpi_backlight=vendor" either doesn't help, or causes weird flickery issues, there are a few other ways to try to cut the number of interfaces down to one.

Quinn Balazs

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

apport information

[Surak (smkozasa)]

I booted with acpi_backlight=vendor and the Fn+F8 and Fn+F9 keys worked as expected to control the internal laptop screen brightness. But there was a side effect: now, plugin the external VGA does not change to external screen automatically anymore. And after manually changing to the external VGA in KDE and removing the VGA cable does not change back to the internal laptop screen automatically. I hope there is a way to keep Fn brightness keys working and the automatic screen selection, simultaneously.

[Quinn Balazs (qbalazs)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Test the 3.9rc8 kernel, not one in the daily directory. Once you have done this, remove the tag "needs-upstream-testing". If this issue exists in the mainline kernel add the tag "kernel-bug-exists-upstream" and if it is fixed, add the tag "kernel-bug-fixed-upstream". If you are simply unable to test the upstream kernel for any reason add the tag "kernel-unable-to-test-upsream". After testing the upstream kernel set the status of this bug back to confirmed. After figuring out if this exists upstream, we will know better where to focus our attempts to get this figured out.

Quinn Balazs

[Quinn Balazs (qbalazs)]

Ack, in actuality you will want to test the latest 3.9 kernel version, not 3.9rc8.

[Surak (smkozasa)]

I accessed

http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D

ordered by date and the most recent raring version is

v3.8.13.10-raring/ 25-Sep-2013 18:57

the most recent saucy version is

v3.11.5-saucy/ 14-Oct-2013 02:52

the most recent 3.9 version is

v3.9.11-saucy/ 21-Jul-2013 00:49

Please, which one(s) should I test? I don't think the latest 3.9.x (saucy) version makes much sense, since there is a much newer 3.11.5 (saucy) version. Or is there a reason to remain in the raring versions? Or is there some reason to remain with 3.9.x versions?

Is it better to try rc versions or non-rc versions? As you mentioned before, there is a 3.12-rc5-saucy, too.

[Quinn Balazs (qbalazs)]

For our purposes, the rc builds should be ignored. Let's test this with v3.8.13.11-raring and v3.11.5-saucy. This should give us a pretty good picture of where (if anywhere) this issue exists upstream. v3.8.13.11-raring is from today, and v3.11.5-saucy is from yesterday.

Sorry about the confusion, it took me a bit to figure out what would be best in this case.

Quinn Balazs

[Surak (smkozasa)]

I was unable to test 3.8.13.11-raring because it won't boot with my LUKS-Crypt Volume, because it does not ask for my passphrase, but tested with 3.8.13.10-raring and the problem happens with it.

I also tested with 3.11.5-saucy and the problem persists, so I updated the tags as oriented.

[Quinn Balazs (qbalazs)]

Thanks for testing those. Since using what was basically the latest upstream kernel didn't help, it sounds like this is something that needs to be addressed upstream. That doesn't mean that we'll stop trying to find a temp solution, just that a fix may originate quicker from upstream. If you would, please open an upstream bug report at https://bugzilla.kernel.org. This will point out your issue to the developers, and may provide a resolution more quickly.

If you feel comfortable opening a bug upstream, it would be helpful if you would post the upstream bug number as a comment here, so that we can link this to the appropriate upstream report. While you are doing that, I'm going to finish looking over the provided logs and should have a few other things that we can try out a bit later today.

Quinn Balazs

[Quinn Balazs (qbalazs)]

The easiest way to file this in the kernel bug tracker is to click the "Also effects project" button and choose "The linux kernel bug filing form". You will need a account, but that is simple enough to set up.

[Quinn Balazs (qbalazs)]

The next step that I'd like to take here is to look at what is in "/sys/class/backlight", both without using the boot param "acpi_backlight=vendor" and with it . To see what we might need to do in order to get one backlight interface working, we need to know what others exist. Without the boot param, I'd expect that we'd see intel_backlight, possibly an nvidia brightness, and acpi_video0. With the boot param, acpi_video0 should be replaced with a vendor specific backlight.

Another quick thing that would be very helpful in guiding us to the root of the problem is to try running the following as root "/bin/echo 0 > /sys/class/backlight/intel_backlight/brightness" this will possibly cause acpi_video0 to function properly, and therefore the brightness keys should also function as expected. If this fixes the issue, it will need to be reentered after a shutdown or a wake from suspend, but I think there is an upstart script somewhere that could be tweaked to do that.

Also, as a last thought for right now, what version of either nouveau or the proprietary nvidia drivers are you using?

[Surak (smkozasa)]

OK, reported this bug to upstream

 bug 63201

https://bugzilla.kernel.org/show_bug.cgi?id=63201

[Richard Hull (rm-hull)]

I have a Clevo W350ST with Ubuntu Saucy, had installed the Bumblebee PPA and experienced the same problem with the brightness keys not working.

However, by removing the bumblebee PPA, purging bumblebee, re-installing it from the Saucy repos, and then adding kernel boot parameters "acpi_backlight=vendor" and "acpi=force", and now the Fn-F8/F8 correctly alter the brightness correctly.

[Surak (smkozasa)]

Hello, Richard Hull, thanks for the info. As in comment #27, at least in my laptop, all I needed to do is to add the "acpi_backlight=vendor" to make Fn brightness keys work, but that made VGA connection and auto screen switch stop working and I use that a lot. BTW, you can probably keep your bumblebee, it does not affect this issue at all.

[Surak (smkozasa)]

Without adding "acpi_backlight=vendor" in the boot parameters:

ls /sys/class/backlight
acpi_video0 intel_backlight

Adding "acpi_backlight=vendor" in the boot parameters:

ls /sys/class/backlight/
intel_backlight

So Fn keys start working with "acpi_backlight=vendor" boot parameter because the keys stop changing /sys/class/backlight/acpi_video0/brightness instead of /sys/class/backlight/intel_backlight/brightness.

[Surak (smkozasa)]

/bin/echo 0 > /sys/class/backlight/intel_backlight/brightness

made the screen completely dark, but the Fn keys did not work. I needed to type a

echo 4000 > /sys/class/backlight/intel_backlight/brightness

to be able to see the screen again.

[Surak (smkozasa)]

I updated to Saucy Salamander 13.10 and the problem persists even with kernel 3.11.0-13-generic #20-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux. Not using Xorg-Edgers PPA, anymore, since I notice nVidia-319 is available, but still using Bumblebee.

[Peter Curtis (pdcurtis)]

I have the same problem on a Clevo W230ST based machine running Saucy 13 10. Exactly the same symtoms and print out of ls /sys/class/backlight both using 3.11 and a 3.8 kernel on a LiveUSB. The keys will reduce the backlight but not increase leaving one completely in the dark. I am running Bumblebee and there is also a problem with bbswitch (an important part of bumblebee) not getting the correct ACPI handles but it seems unrelated to me.

[Surak (smkozasa)]

I burned a disk with the daily live of 2013-12-03 and the bug persists exactly the same. Fn keys change the value of /sys/class/backlight/acpi_video0/brightness. This doesn't change actual screen brightness, that can be changed altering the value of /sys/class/backlight/intel_backlight/brightness.

I will check the latest upstream kernel soon.

[Surak (smkozasa)]

Finally tested upstream kernel. Unfortunatelly, behavior is still exactly as the bug description even with v3.13-rc6-trusty

[penalvch (penalvch)]

Surak, thank you for performing the requested test. Given that Bugzilla is legacy, it would be best to engage the upstream developers via the appropriate mailing list. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel (would send to linux-acpi)?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

[Sergio Callegari (callegar)]

Same issue here with a Schenker S413, identical to clevo W740SU, Sager NP240 and System 76 Galago ultrapro.

Probem is worse than described, though.

If you attach an external monitor and

xrandr --ouptput HDMI2 --auto --output eDP1 --off

(i.e. switch on external monitor, off internal one)

then going back to

xrandr --output eDP1 --auto

leaves the laptop screen at brightness 0 (black). Since the brightness keys are not working, the only way to go back to a usable laptop is to reboot.

The system 76 package in the system76 ppa may have a fix for this, but cannot be setup on machines that do not include the system76 signature in the bios.

[penalvch (penalvch)]

Sergio Callegari, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs