Created attachment 911143 [details] dmesg.log Description of problem: LCD backlight can be adjusted with slider if interface intel_backlight is used only. The backlight can not be adjusted with the function function keys. Version-Release number of selected component (if applicable): Fedora release 20 (Heisenbug) kernel 3.15.0-1.fc21.x86_64 xorg-x11-drv-intel.x86_64 2.21.15-7.fc20 How reproducible: see http://hansdegoede.livejournal.com/13889.html Steps to Reproduce: see http://hansdegoede.livejournal.com/13889.html Actual results: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet # evemu-record Available devices: /dev/input/event0: Power Button: nothing /dev/input/event1: Lid Switch: nothing /dev/input/event2: Sleep Button: nothing /dev/input/event3: Power Button: nothing /dev/input/event4: AT Translated Set 2 keyboard: nothing /dev/input/event5: ETPS/2 Elantech Touchpad: error: this device is grabbed and I cannot record events /dev/input/event6: USB OPTICAL MOUSE: nothing /dev/input/event7: Video Bus: nothing /dev/input/event8: USB2.0 HD UVC WebCam: nothing /dev/input/event9: HDA Intel PCH HDMI/DP,pcm=3: nothing /dev/input/event10: HDA Intel PCH Headphone: nothing /dev/input/event11: Asus WMI hotkeys: nothing /dev/input/event12: IR-receiver inside an USB DVB receiver: nothing "nothing": There where no events detected. Booting with different parameters: * BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet # ls /sys/class/backlight acpi_video0 intel_backlight * video.use_native_backlight=1 * BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet video.use_native_backlight=1 # ls /sys/class/backlight intel_backlight * acpi_backlight=vendor * BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet acpi_backlight=vendor # ls /sys/class/backlight asus-nb-wmi intel_backlight * acpi_osi="!Windows 2012" * BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet "acpi_osi=!Windows\x202012" # ls /sys/class/backlight acpi_video0 intel_backlight * acpi_osi="!Windows 2009" * BOOT_IMAGE=/boot/vmlinuz-3.15.0-1.fc21.x86_64 root=UUID=2ccbe1d6-e74f-4330-9f2b-db9b421d3e28 ro vconsole.font=latarcyrheb-sun16 rhgb quiet "acpi_osi=!Windows\x202009" # ls /sys/class/backlight acpi_video0 intel_backlight With parameter video.use_native_backlight=1 intel_backlight is the only interface and adjusting the backlight with the slider works. So I add dmesg.log. dmi.log is: /sys/class/dmi/id/bios_date:01/21/2014 /sys/class/dmi/id/bios_vendor:American Megatrends Inc. /sys/class/dmi/id/bios_version:X200MA.302 /sys/class/dmi/id/board_asset_tag:ATN12345678901234567 /sys/class/dmi/id/board_name:X200MA /sys/class/dmi/id/board_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/board_version:1.0 /sys/class/dmi/id/chassis_asset_tag:No Asset Tag /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:ASUSTeK COMPUTER INC. /sys/class/dmi/id/chassis_version:1.0 /sys/class/dmi/id/product_name:X200MA /sys/class/dmi/id/product_version:1.0 /sys/class/dmi/id/sys_vendor:ASUSTeK COMPUTER INC. The function keys have no affect with all of these tries. Expected results: Adjusting the backlight should be working with slider and keys without additional boot parameters. Additional info:
Can you try switching to a text console (ctrl + alt + f2) login and then do: showkey -s And press the brightness up / down key combos ? If this causes something to be printed please write it down and report back here.
Nothing is printed with kernel 3.14 or 3.15.
(In reply to fcbug from comment #2) > Nothing is printed with kernel 3.14 or 3.15. I'm afraid I'm all out of idea to fix this then. It is probably a good idea to keep this bug open, but don't expect much progress on it.
(I have copied my post from https://bugzilla.redhat.com/show_bug.cgi?id=1144866, this seems to be a related bug, let me know if this isn't customary) Hello, I currently own an Asus Q302la, which seems to have an identical setup to the other Asus laptops that I have seen reported on various redhat,kernel,and freedesktop bugzilla bugs. its Fn+F5 and Fn+F6 keys are not registering events when viewed through input-tools or evemu-record despite various other asus-wmi key-keycombos showing up and do not seem to be affected by any permutation of the boot options: video.use_native_backlight=1, acpi_backlight=vendor, acpi_osi="!Windows 2012", and acpi_osi="!Windows 2009". no scan codes come up with "echo 1> /sys/modules/i8042/parameters/debug" either. other bugs on this laptop that make me feel as though this is the same hardware configuration are that it has the Focaltech touchpad (FLT0102) that is still being worked on for multitouch support and is stubbornly registering in PS/2 emulation mode, its intel 7270 wireless ac card was on an unkown pci id (recently patched in linux-stable), its "G-sensor" isn't registering, and the ambient light sensor isn't being detected (though its showing up as an ASL device with an HID of ACPI0008, which doesn't seem to be recognized by the kernel yet), which seems to match up with most of the other recent asus laptop bugs. I've taken it upon myself to use this laptop as an opportunity to break further into kernel development and troubleshooting and have been reading through the source, tinkering around with kprobes, ftrace+friends, and dyndebug. I am using the mainline linux-stable kernel 3.17.2 compiled from the git v3.17.2 tag on a Ubuntu 14.10 installation (Sorry, I know this is the Redhat bugzilla, but it doesn't seem like I'm getting different results and feel like it would be useful to know this isn't specifically a Fedora/Centos/RedHat issue) Ive made some progress on the Fn+F5 and Fn+F6 backlight keys: it turns out that the ACPI Embedded Controller code is seeing the backlight key combos, but it doesn't seem like its being passed on further in the kernel. I'm still learning about how the ACPI subsystem works, and I feel like later on I'll be better equipped to say definitively where exactly these events are being discarded. I enabled dynamic debug on the embedded controller with: echo "file drivers/acpi/ec.c +p" > /sys/kernel/debug/dynamic_debug/control I notice that for Fn+F5 (decrease brightness), this prints out on dmesg: kern :debug : [ +0.233305] ACPI : EC: ===== IRQ ===== kern :debug : [ +0.000006] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000004] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000001] ACPI : EC: push gpe query to the queue kern :debug : [ +0.000039] ACPI : EC: ===== TASK ===== kern :debug : [ +0.000003] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000007] ACPI : EC: EC_SC(W) = 0x84 kern :debug : [ +0.000787] ACPI : EC: ===== TASK ===== kern :debug : [ +0.000005] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000075] ACPI : EC: ===== IRQ ===== kern :debug : [ +0.000005] ACPI : EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1 kern :debug : [ +0.000004] ACPI : EC: EC_DATA(R) = 0x0e kern :debug : [ +0.000000] ACPI : EC: hardware QR_EC completion kern :debug : [ +0.000005] ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000009] ACPI : EC: push query execution (0x e) on queue kern :debug : [ +0.000002] ACPI : EC: start query execution kern :debug : [ +0.000199] ACPI : EC: stop query execution and for Fn+F6 (increase brightness), this prints out on dmesg: ===== IRQ ===== kern :debug : [ +0.000012] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000007] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000002] ACPI : EC: push gpe query to the queue kern :debug : [ +0.000058] ACPI : EC: ===== TASK ===== kern :debug : [ +0.000017] ACPI : EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000005] ACPI : EC: EC_SC(W) = 0x84 kern :debug : [ +0.000853] ACPI : EC: ===== IRQ ===== kern :debug : [ +0.000012] ACPI : EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1 kern :debug : [ +0.000006] ACPI : EC: EC_DATA(R) = 0x0f kern :debug : [ +0.000002] ACPI : EC: hardware QR_EC completion kern :debug : [ +0.000013] ACPI : EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 kern :debug : [ +0.000024] ACPI : EC: push query execution (0x f) on queue kern :debug : [ +0.000008] ACPI : EC: start query execution kern :debug : [ +0.000502] ACPI : EC: stop query execution From what I gather from this, it looks like Fn+F5 is registering as EC_DATA = 0x0e and Fn+F6 is registering as EC_DATA = 0x0f. I hope this helps out, I'm still learning all of this stuff, and feel like _something_ being detected in response to these keys being pressed would be useful data. Let me know if there is anything else I can try out, as I said, I'm trying to learn more about kernel development and would be open to do any kind of sophisticated task to help out.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Travis James from comment #4) > I hope this helps out, I'm still learning all of this stuff, and feel like > _something_ being detected in response to these keys being pressed would be > useful data. Let me know if there is anything else I can try out, as I said, > I'm trying to learn more about kernel development and would be open to do > any kind of sophisticated task to help out. I think it would be a good idea to post a mail with the above findings to the platform-driver-x86.org list, hopefully someone there will be able to help you debug this further and/or to modify/write a driver for these model laptops.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.