Created attachment 1089365 [details] dmesg log Description of problem: Backlight keys (fn + f5, fn + f6) are ineffectual, i.e. they don't work to adjust the brightness of the screen backlight. Version-Release number of selected component (if applicable): kernel-4.2.3-200.fc22.x86_64 How reproducible: 100% Steps to Reproduce: 1. Own a ASUS Zenbook UX305FA 2. Boot Fedora 22 Actual results: Keys are ineffectual. Expected results: Keys adjust backlight brightness. notes: 1. per the blog post at http://hansdegoede.livejournal.com/13889.html - the brightness *is* adjustable via both the Gnome slider in the upper right as well as by echoing a value directly into the /sys/class/backlight/intel_backlight/brightness file. 2. per the same blog post, no events of any kind are intercepted by all 13 settings available for the evemu script. 3. dmesg.log and dmi.log are attached.
Created attachment 1089366 [details] dmi.log
see bz#1144866 for related info
Hi, Hmm, bummer this looks indeed like it may have the same root cause as bug 1144866. More details on the likely culprit of this here: http://blog.yjwong.name/fixing-display-backlight-hotkeys-on-asus-n550jk/ I've send a mail to one of the main acpi-video driver devs asking for help on this. I'll let you know when he gets back to me. Or maybe he will just comment here in bugzilla himself. Regards, Hans
yup, i think there's a general theme w/ asus and linux here from all my searching (lots of issues w/ asus brightness keys everywhere). But my camera, microphone, audio, and everything else all worked perfectly out of the box (a far cry from when we had to be modprobe experts in the 90's for such things) so I know we'll get these brightness keys working at some point!
upstream LK bug
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
upstream kernel bug still persists.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 24 has now been rebased to 4.7.4-200.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25. If you experience different issues, please open a new bug report for those.
booted with kernel-4.7.4-200.fc24.x86_64 issue persists
Maybe a duplicated bug of https://bugzilla.redhat.com/show_bug.cgi?id=1391309 ?
There are 2 patches in drm-intel-next now, which should fix this. Unfortunately creating a rpm from a random git kernel tree is not so easy, so I would like to ask you to manually build the kernel yourself, by following these instructions: sudo dnf install -y git gcc make git clone git://anongit.freedesktop.org/drm-intel cd drm-intel wget https://fedorapeople.org/~jwrdegoede/config-4.9.0-rc5 mv config-4.9.0-rc5 .config make oldconfig <the make oldconfig may ask some questions, simply hit enter to choose the defaults> make -j4 bzImage && make -j4 modules && sudo make modules_install && sudo make install <this is going to take a while, say approx. an hour or so> And now you can reboot, note grub will default to your latest normally installed kernel, to pick this one you need to explictly select it. And then see if the brightness keys now work Thanks & Regards, Hans
Hans, I think I've managed to navigate the kernel build process, but the run-time results were not perfect. When using either of the brightness function keys, the brightness "slider" becomes visible in the upper right, but no slider movement happens is forthcoming, regardless of which key is pressed. This is some progress, because with the stock kernel, no brightness slider appears at all. Also, the following start-up error is listed in the dmesg output: [ 3.292639] [drm] Initialized i915 1.6.0 20161121 for 0000:00:02.0 on minor 0 [ 3.293559] ------------[ cut here ]------------ [ 3.293615] WARNING: CPU: 0 PID: 112 at drivers/gpu/drm/i915/intel_dp.c:4023 intel_dp_check_link_status+0x1d7/0x 200 [i915] [ 3.293621] WARN_ON_ONCE(!intel_dp->lane_count) [ 3.293623] Modules linked in: [ 3.293628] i915 i2c_algo_bit drm_kms_helper drm crc32c_intel serio_raw i2c_hid video fjes nf_conntrack_pptp nf _conntrack_proto_gre nf_conntrack [ 3.293642] CPU: 0 PID: 112 Comm: kworker/u8:2 Not tainted 4.9.0-rc4+ #1 [ 3.293646] Hardware name: ASUSTeK COMPUTER INC. UX305CA/UX305CA, BIOS UX305CA.201 09/11/2015 [ 3.293654] Workqueue: events_unbound async_run_entry_fn [ 3.293658] ffffbf680103bbc8 ffffffffb43eebdd ffffbf680103bc18 0000000000000000 [ 3.293665] ffffbf680103bc08 ffffffffb40a16fb 00000fb70103bc40 ffff9a529c5c90f0 [ 3.293672] 0000000000000001 ffff9a529c9c8000 ffff9a529c9c8258 ffff9a529c5c9000 [ 3.293679] Call Trace: [ 3.293686] [<ffffffffb43eebdd>] dump_stack+0x63/0x86 [ 3.293690] [<ffffffffb40a16fb>] __warn+0xcb/0xf0 [ 3.293695] [<ffffffffb40a177f>] warn_slowpath_fmt+0x5f/0x80 [ 3.293704] [<ffffffffc03d6467>] ? drm_dp_dpcd_read+0x57/0x70 [drm_kms_helper] [ 3.293744] [<ffffffffc049de17>] intel_dp_check_link_status+0x1d7/0x200 [i915] [ 3.293779] [<ffffffffc04a4149>] intel_dp_detect+0x6a9/0xa50 [i915] [ 3.293784] [<ffffffffb40d00cb>] ? build_sched_domains+0x2db/0xb40 [ 3.293792] [<ffffffffc03d715f>] drm_helper_probe_single_connector_modes+0x3ff/0x4f0 [drm_kms_helper] [ 3.293800] [<ffffffffb44eb6a3>] ? n_tty_receive_buf_common+0x133/0xd80 [ 3.293804] [<ffffffffb40cdc7a>] ? wake_up_new_task+0x14a/0x1f0 [ 3.293811] [<ffffffffc03e5ece>] drm_fb_helper_initial_config+0xae/0x420 [drm_kms_helper] [ 3.293818] [<ffffffffb4025728>] ? __switch_to+0x2a8/0x5c0 [ 3.293852] [<ffffffffc04946f8>] intel_fbdev_initial_config+0x18/0x30 [i915] [ 3.293857] [<ffffffffb40c4859>] async_run_entry_fn+0x39/0x140 [ 3.293862] [<ffffffffb40bb734>] process_one_work+0x184/0x430 [ 3.293866] [<ffffffffb40bba2e>] worker_thread+0x4e/0x490 [ 3.293870] [<ffffffffb40bb9e0>] ? process_one_work+0x430/0x430 [ 3.293875] [<ffffffffb40c1439>] kthread+0xd9/0xf0 [ 3.293880] [<ffffffffb40c1360>] ? kthread_park+0x60/0x60 [ 3.293884] [<ffffffffb40c1360>] ? kthread_park+0x60/0x60 [ 3.293889] [<ffffffffb4817395>] ret_from_fork+0x25/0x30 [ 3.293893] ---[ end trace a81467d1c5803481 ]--- [ 3.295986] fbcon: inteldrmfb (fb0) is primary device [ 3.827070] clocksource: Switched to clocksource tsc
Hi, Thank you for testing. Does adjusting the backlight with the slider in the gnome3 system menu work (the top right menu which allows you to control networking, log-out, etc) ? If the slider does not work, what does "ls /sys/class/backlight" give as output ? and can you try booting with acpi_backlight=native on the kernel cmdline and if that does not fix things, with acpi_backlight=video (instead of native) ? The oops seems unrelated to the brightness issues. These things are somewhat expected when running a development branch, hopefully it will get fixed soon-ish. Regards, Hans
Hans, the xfce4 power manager successfully controls the backlight in both the stock kernel and the custom-built kernel. I booted with both of the acpi_backlight options you suggested, and I didn't notice any difference in behavior. Having tested it a few times now, I can be a bit more specific: the "graphic overlay" that pops up with the function keys does correctly indicate the current brightness setting of the backlight. However, it doesn't budge with subsequent pressings of the brightness function keys. It just fades away after 5-10 seconds.
Hi, Ok, cna you see what key-presses the brightness keys are generating? Please do "sudo dnf install evemu" and then "sudo evemu-record" you will then get a list of input devices, with one or two "Video Bus" input devices, select the first one, and then press they brightness up / down hotkeys and copy and paste the output here please ? If you've 2 entries and the first one does not produce any output, try the second one please. Regards, Hans
Hans, Here is the output from evemu-record after entering 4, corresponding to the choice of /dev/input/event4. My test input was fn-f5 (brightness down) followed by fn=f6 (brightness up), which I then repeated a few seconds later. The brightness overlay behavior was unchanged, popping up at the start, but not changing thereafter. --- Select the device event number [0-14]: 4 # EVEMU 1.3 # Kernel: 4.9.0-rc4+ # DMI: dmi:bvnAmericanMegatrendsInc.:bvrUX305CA.201:bd09/11/2015:svnASUSTeKCOMPUTERINC.:pnUX305CA:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX305CA:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: # Input device name: "Video Bus" # Input device ID: bus 0x19 vendor 0000 product 0x06 version 0000 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event type 1 (EV_KEY) # Event code 224 (KEY_BRIGHTNESSDOWN) # Event code 225 (KEY_BRIGHTNESSUP) # Event code 227 (KEY_SWITCHVIDEOMODE) # Event code 241 (KEY_VIDEO_NEXT) # Event code 242 (KEY_VIDEO_PREV) # Event code 243 (KEY_BRIGHTNESS_CYCLE) # Event code 244 (KEY_BRIGHTNESS_AUTO) # Event code 245 (KEY_DISPLAY_OFF) # Properties: N: Video Bus I: 0019 0000 0006 0000 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 0b 00 3e 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ E: 0.000001 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.000062 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.000062 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 1.403183 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 1.403183 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +1403ms E: 1.403222 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 1.403222 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 11.152175 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 11.152175 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +9749ms E: 11.152220 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 11.152220 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 11.710571 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 11.710571 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +558ms E: 11.710618 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 11.710618 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
Hi, So the evemu output looks perfectly fine, so it seems that the new kernel is doing everything right, but for some reason xfce is misbehaving ? Can you try if any other devices in the evemu-record list also produce output when you press the brightness keys ? Likely candidates are: all video busses, any asus or wmi devices and the "at translated set 2 keyboard". Maybe one of these is now also generating presses, which negate the other presses ? Also if possible it would be nice if you could give gnome3 a try with the new kernel ... And I would still like to see "ls /sys/class/backlight" output please. Regards, Hans
Hans, I tried all the other possible inputs to evemu-record, and none of them listed any reaction from the brightness keys, only Video Bus worked, as shown above. I managed to get the gnome3 environment installed, and the brightness keys worked perfectly, although the graphic overlay was different. The output of "ls /sys/class/backlight" was just "intel_backlight". Rather than leave you with such a short asnwer, here is the "ls -l" output for that directory: lrwxrwxrwx. 1 root root 0 Dec 7 16:32 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight Following that link brings one to a directory that has various files, such as "brightness", which actually controls the brightness when an ASCII integer is written to it. I agree with your hunch that xfce is misbehaving.
(In reply to Stan King from comment #18) > I managed to get the gnome3 environment installed, and the brightness keys > worked perfectly, although the graphic overlay was different. Yes, the keypress handling and overlay drawing is done by the desktop environment, which is why it looks (and sometimes behaves) different. > I agree with your hunch that xfce is misbehaving. Yes, all your testing shows the new kernel is doing just fine, and the gnome3 testing seems to confirm this. So that means that from a kernel pov this bug is fixed by the fixes queued up in intel-drm-next, which should hit 4.10 (to be released aprox 3 months from now). Lets keep this bug open until kernel 4.10 becomes available for Fedora and then re-test and close it if the keys generate the proper keypresses. As for the XFCE issue, I suggest that you file a new bug for that against xfce (not sure which xfce component).
Yes, the difference seems to be that the stock kernel does not produce the evemu-record output for the brightness keys, but the test kernel does. By the way, can you offer a suggestion on how to cleanly remove the test kernel when I'm finished with it?
(In reply to Stan King from comment #20) > By the way, can you offer a suggestion on how to cleanly remove the test > kernel when I'm finished with it? Hmm, good question, to remove the test kernel, boot it and do: "uname -r" And write down the output of that, lets call it $UNAMER, then boot into a normal kernel (you could do this under the test kernel, but then you should reboot afterwards, otherwise e.g. plugging in a new usb device might not work) : sudo rm /boot/*$UNAMER* sudo rm -r lib/modules/$UNAMER Then edit your bootloader config, either /etc/grub2-efi.cfg (if you're using EFI) or /etc/grub2.cfg, look for $UNAMER and remove the config block for that kernel, blocks start with a menuentry line and end with a line with just "}" at the beginning of the line.
Hans, thanks for the tip. And I'll look around the xfce "space" to see about reporting it there, if someone doesn't beat me to it.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
As a "post-mortem", using 4.10.12-200.fc25.x86_64, all I had to do was go into the settings editor, and check the box beside "handle brightness keys", and it worked! I wonder why that option wasn't already checked.