Bug 1144866
Summary: | Backlight keys not working - ASUS N550JV | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | torvum | ||||||
Component: | kernel | Assignee: | Hans de Goede <hdegoede> | ||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 22 | CC: | gansalmon, hdegoede, itamar, jonathan, kernel-maint, madhu.chinakonda, mbayer, mchehab, Tjames6858, torvum | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-11-03 13:53:20 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
torvum
2014-09-21 16:55:58 UTC
Hi, Can you please walk through the debugging instructions here: http://hansdegoede.livejournal.com/13889.html And provide all the data requested there here ? Thanks, Hans Hi. I installed evemu and went ahead with the steps. After running it as root I was given the following list: /dev/input/event0: Lid Switch /dev/input/event1: Sleep Button /dev/input/event2: Power Button /dev/input/event3: AT Translated Set 2 keyboard /dev/input/event4: Asus WMI hotkeys /dev/input/event5: Logitech USB Receiver /dev/input/event6: Logitech USB Receiver /dev/input/event7: ETPS/2 Elantech Touchpad /dev/input/event8: Logitech USB Receiver /dev/input/event9: Logitech USB Receiver /dev/input/event10: USB2.0 UVC HD Webcam /dev/input/event11: HDA Intel PCH Mic /dev/input/event12: HDA Intel PCH Headphone I tried both the AT Translated Set 2 keyboard and the Asus WMI hotkeys, but neither of them generated any events when I tried fn+f5 or fn+f6 in contradistinction to the other fn+(f1-f4 and f7-f12) key combinationed which did register events. I hope that helps. Hmm, so you're not getting any key press events it seems. Some more questions: 1) Can you control the brightness with the slider in the gnome3 system-menu (upper right corner menu) ? 2) What is the output of: "ls /sys/class/backlight" 3) What is the output of: "lsmod" 4) Can you please do directly after boot: "dmesg > dmesg.log" and then attach the generated log file here ? Please attach the output of acpidump as well. You may be hitting an issue I have on a different ASUS laptop where the firmware never actually reports anything to the kernel because the firmware is newer than what the kernel can handle. Created attachment 943387 [details]
output of dmesg
Created attachment 943405 [details]
output of acpidump
@Hans de Goede: 1.) I don't see any brightness slider except for my keyboard brightness. 2.) The output of "ls /sys/class/backlight" is nothing. 3.) Output of lsmod follows. 4.) I've attached the output of dmesg. @Josh Boyer: I've also attached the output of acpidump OUTPUT of lsmod: Module Size Used by rfcomm 69427 12 ip6t_rpfilter 12546 1 ip6t_REJECT 12939 2 xt_conntrack 12760 9 bnep 19624 2 ebtable_nat 12807 0 ebtable_broute 12731 0 bridge 116006 1 ebtable_broute stp 12868 1 bridge llc 13941 2 stp,bridge ebtable_filter 12827 0 ebtables 30758 3 ebtable_broute,ebtable_nat,ebtable_filter ip6table_nat 12974 1 nf_conntrack_ipv6 18738 6 nf_defrag_ipv6 34712 1 nf_conntrack_ipv6 nf_nat_ipv6 13213 1 ip6table_nat ip6table_mangle 12700 1 ip6table_security 12710 1 ip6table_raw 12683 1 ip6table_filter 12815 1 ip6_tables 26809 5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw iptable_nat 12970 1 nf_conntrack_ipv4 14656 5 nf_defrag_ipv4 12702 1 nf_conntrack_ipv4 nf_nat_ipv4 13199 1 iptable_nat nf_nat 25178 4 nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat nf_conntrack 99420 8 nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 iptable_mangle 12695 1 iptable_security 12705 1 iptable_raw 12678 1 bbswitch 13943 0 vfat 17411 1 fat 65059 1 vfat fuse 91446 5 rtsx_usb_sdmmc 27742 0 rtsx_usb_ms 18651 0 mmc_core 121087 1 rtsx_usb_sdmmc memstick 16199 1 rtsx_usb_ms rtsx_usb 20250 2 rtsx_usb_sdmmc,rtsx_usb_ms snd_hda_codec_realtek 72791 1 snd_hda_codec_generic 67662 1 snd_hda_codec_realtek snd_hda_intel 30379 4 snd_hda_controller 30139 1 snd_hda_intel snd_hda_codec 131298 4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller arc4 12608 2 ath9k 136757 0 ath9k_common 24449 1 ath9k ath9k_hw 435606 2 ath9k_common,ath9k ath 28211 3 ath9k_common,ath9k,ath9k_hw mac80211 623787 1 ath9k uvcvideo 81022 0 videobuf2_vmalloc 13163 1 uvcvideo videobuf2_memops 13161 1 videobuf2_vmalloc videobuf2_core 57175 1 uvcvideo v4l2_common 14542 1 videobuf2_core videodev 147660 3 uvcvideo,v4l2_common,videobuf2_core x86_pkg_temp_thermal 14205 0 coretemp 13441 0 kvm_intel 147547 0 kvm 452677 1 kvm_intel crct10dif_pclmul 14307 0 crc32_pclmul 13133 0 crc32c_intel 22094 0 ghash_clmulni_intel 13230 0 media 20846 2 uvcvideo,videodev iTCO_wdt 13480 0 iTCO_vendor_support 13419 1 iTCO_wdt snd_hwdep 17650 1 snd_hda_codec cfg80211 500115 4 ath,ath9k_common,ath9k,mac80211 nouveau 1222531 0 serio_raw 13434 0 snd_seq 62266 0 snd_seq_device 14136 1 snd_seq snd_pcm 104333 3 snd_hda_codec,snd_hda_intel,snd_hda_controller ttm 80772 1 nouveau lpc_ich 21093 0 mfd_core 13182 2 lpc_ich,rtsx_usb mei_me 19568 0 mei 86597 1 mei_me snd_timer 28778 2 snd_pcm,snd_seq snd 75905 17 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device soundcore 14491 2 snd,snd_hda_codec microcode 44710 0 i2c_i801 18146 0 ath3k 13331 0 btusb 32448 0 joydev 17344 0 bluetooth 433970 33 bnep,ath3k,btusb,rfcomm shpchp 37047 0 binfmt_misc 17431 1 i915 904304 3 i2c_algo_bit 13257 2 i915,nouveau drm_kms_helper 58041 2 i915,nouveau drm 291361 4 ttm,i915,drm_kms_helper,nouveau r8169 71694 0 mii 13527 1 r8169 i2c_core 55486 8 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,v4l2_common,nouveau,videodev mxm_wmi 12865 1 nouveau asus_nb_wmi 16990 0 asus_wmi 23974 1 asus_nb_wmi rfkill 21979 7 cfg80211,bluetooth,asus_wmi sparse_keymap 13584 1 asus_wmi wmi 18820 3 mxm_wmi,nouveau,asus_wmi video 19777 3 i915,nouveau,asus_wmi Hi, I see the following on your kernel commandline, are you using the nvidia binary driver ? nouveau.modeset=0 rd.driver.blacklist=nouveau Can you try booting with these options removed from the kernel commandline ? Something else which stands out, and which may be cause of the problem here is that you don't seem to have an acpi-video-bus (e.g. it is missing in the evemu-record output). I think this may be caused by your machine having an intel-opregion for the i915, while not having any display pipelines hooked op on the i915. If you have experience building your own kernels can you try editing: drivers/gpu/drm/i915/i915_dma.c Around line 1795 you should see the following there: if (INTEL_INFO(dev)->num_pipes) { /* Must be done after probing outputs */ intel_opregion_init(dev); acpi_video_register(); } Try changing this to: if (INTEL_INFO(dev)->num_pipes) { /* Must be done after probing outputs */ intel_opregion_init(dev); } acpi_video_register(); So basically call the acpi_video_register(); unconditionally. If you've no experience in building kernels, let me know and I'll do a scratch build with this change in for you. Thanks for the timely responses Hans! I have absolutely no experience editing kernels. I've only been using Linux for a year and I'm only a novice programmer with no C language experience. I wouldn't mind giving it a shot, though. Are there any resources you can suggest I read for a quick intro so that I can make this change myself? I'm really not sure if I'm using the nvidia binary driver. I'm running bumblebee (since I have hybrid graphics, i.e. 2 video cards) and I'm pretty sure I installed some special nvidia drivers that work congruently with bumblebee, although those could be regular'ol drivers for all I know. I followed these instructions: https://fedoraproject.org/wiki/Bumblebee and I guess the drivers came with the packages mentioned within. (In reply to torvum from comment #6) > Created attachment 943405 [details] > output of acpidump Your APCI tables are very similar to the ones found on the ASUS UX301 laptops. I would not be surprised if your machine hits this bug: https://bugs.freedesktop.org/show_bug.cgi?id=81762 One other question: if you use the brightness slider in GNOME, does it adjust the brightness? @Josh: Don't have a brightness slider as far as I can tell. And thanks for the link to that other bug, but any/all of the information there is a bit lost on me—I'm not that technically savy. Reading that was like eating alphabet soup. (In reply to Josh Boyer from comment #10) > (In reply to torvum from comment #6) > > Created attachment 943405 [details] > > output of acpidump > > Your APCI tables are very similar to the ones found on the ASUS UX301 > laptops. I would not be surprised if your machine hits this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=81762 Hmm interesting. Josh is the ux301 you've a hybrid graphics model too ? And if you do evemu-record, is there an "acpi video bus" input device listed there ? If not an you try a kernel with the change I suggested in comment 8? My theory is that on these hybrid models there may be no valid connectors on the intel iGPU, but despite that the BIOS does have an Intel opregion, which causes drivers/acpi/video.c to skip acpi_video_register, to give the intel driver a chance to initialize first. But in the case where the Intel iGPU has no connectors, the intel driver will never call acpi_video_register() causing the kernel to never start listening to the ACPI video bus. > One other question: if you use the brightness slider in GNOME, does it > adjust the brightness? No, besides not getting key events, torvum also does not get any backlight devices under /sys/class/backlight, that may be related to your bug: https://bugs.freedesktop.org/show_bug.cgi?id=81762 And/or it may be related to him using nouveau.nomodeset=1 (In reply to torvum from comment #9) > Thanks for the timely responses Hans! I have absolutely no experience > editing kernels. I've only been using Linux for a year and I'm only a novice > programmer with no C language experience. I wouldn't mind giving it a shot, > though. Are there any resources you can suggest I read for a quick intro so > that I can make this change myself? > > I'm really not sure if I'm using the nvidia binary driver. I'm running > bumblebee (since I have hybrid graphics, i.e. 2 video cards) and I'm pretty > sure I installed some special nvidia drivers that work congruently with > bumblebee, although those could be regular'ol drivers for all I know. I > followed these instructions: https://fedoraproject.org/wiki/Bumblebee and I > guess the drivers came with the packages mentioned within. Ugh, I'm afraid that using bumblebee is very much going into unsupported territory, and uninstalling it to get back to a pristine state is also going to be quite hard. One option would be a clean re-install, but that is a lot of work, and may not help. So first lets wait and see what Josh has to say, as he seems to have a better understanding of the specific problems with your model laptop then I do. (In reply to Hans de Goede from comment #12) > (In reply to Josh Boyer from comment #10) > > (In reply to torvum from comment #6) > > > Created attachment 943405 [details] > > > output of acpidump > > > > Your APCI tables are very similar to the ones found on the ASUS UX301 > > laptops. I would not be surprised if your machine hits this bug: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=81762 > > Hmm interesting. > > Josh is the ux301 you've a hybrid graphics model too ? No. > And if you do > evemu-record, is there an > "acpi video bus" input device listed there ? Yes. > If not an you try a kernel > with the change I suggested in > comment 8? I can try this at some point, but I don't think it's going to matter. In my specific case I'm fairly sure I know what the issue is. > My theory is that on these hybrid models there may be no valid connectors on > the intel iGPU, but despite that the BIOS does have an Intel opregion, which > causes drivers/acpi/video.c to skip acpi_video_register, to give the intel > driver a chance to initialize first. But in the case where the Intel iGPU > has no connectors, the intel driver will never call acpi_video_register() > causing the kernel to never start listening to the ACPI video bus. Yeah, that theory doesn't sound bad. Just not applicable to my specific machine. So yay, we have two ASUS laptops with terrible firmwrae/gpu setups :). > > One other question: if you use the brightness slider in GNOME, does it > > adjust the brightness? > > No, besides not getting key events, torvum also does not get any backlight > devices under /sys/class/backlight, that may be related to your bug: > https://bugs.freedesktop.org/show_bug.cgi?id=81762 > > And/or it may be related to him using nouveau.nomodeset=1 Yeah, my machine has a backlight device and the slider works, just not the function keys. So I guess my theory was wrong. Well, I can probably do a fresh install of Fedora sometime in the next few weeks. Is there anything else we can try in the meantime? And while I have you, are there any plans to support nVidia Optimus technology in the future? I'm not sure I'm asking the right person here, so my apologies if not. Oh, and if I DO do a clean OS install, does that mean I'm going to be running off my nVidia all the time (and draining max power) or does that mean I'll be running off my intel graphics card (and draining no power but getting no hardware acceleration)? Thanks! Hi, I've started a scratchbuild with a kernel with some debugging + a quick hack to try and get the acpi video bus to register, you can find this scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7832541 Note this is still building atm. Can you please download the kernel-3.16.5-....x86_64.rpm file, and then install it with: sudo rpm -ivh kernel-3.16.5-....x86_64.rpm And boot into it without specifying any special kernel commandline parameters. Then first of all do: dmesg > dmesg.log And attach the generated dmesg.log file here. Then please run evemu-record as root again: sudo evemu-record And see if there is a "Video Bus" input device listed now, if there is select it, and then press the brightness keys on the laptop keyboard and see if they generate events now. Please let me know if the keys work with this scratch build. Thanks, Hans Ugh, that scratchbuild has failed because the release field was too long, here is a new build I've just started: https://koji.fedoraproject.org/koji/taskinfo?taskID=7839906 Please follow the previous testing instructions using this build (once it has finished building). 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. Hi Travis, That is very interesting information! Can you please send a mail with this to the linux-acpi <linux-acpi.org> mailinglist, with me in the CC. There should be people there who can help you further. Note no need to subscribe, just also CC yourself and then you should get all replies. Thanks & Regards, Hans I have finally made the brightness keys to work. turns out is is an aml issue that is identical to this problem: http://blog.yjwong.name/fixing-display-backlight-hotkeys-on-asus-n550jk/ (funny how i perform all of the research and work and random debugging over the course of weeks and then finally run into this article that demostrates everything i eventually learned about.) making the necessary changes, compiling the asl into aml, and concatenating the cpio archive onto the initramfs results in a system where the brightness keys will change brightness and display the appropriate graphical indicators for changing screen brightness. Hi Travis, (In reply to Travis James from comment #20) > I have finally made the brightness keys to work. turns out is is an aml > issue that is identical to this problem: > http://blog.yjwong.name/fixing-display-backlight-hotkeys-on-asus-n550jk/ > (funny how i perform all of the research and work and random debugging over > the course of weeks and then finally run into this article that demostrates > everything i eventually learned about.) > making the necessary changes, compiling the asl into aml, and concatenating > the cpio archive onto the initramfs results in a system where the brightness > keys will change brightness and display the appropriate graphical indicators > for changing screen brightness. Hmm, since you we're getting events with the broken / original aml, I wonder if there is a way to make the kernel simply work with the broken aml ? e.g. some extra code somewhere (only activated on these models) which turns those events into keypresses ? The reason why I'm asking is because we never ship aml updates (too dangerous because they are very model specific), and it would be nice to have a fix which make things work ootb for other users. If you think you can cook up a kernel side fix to make things work with the original aml please do, if not please close this bug. Thanks & Regards, Hans I'm afraid I'm not familiar enough with the acpi code to know exactly how to do that, but I have been looking at the way gpe handlers are registered, and it looks like a function callback can be used instead of executing the aml. specifically, acpi_ec_run checks for that function, and if it isn't there, then it executes the aml code. I'm away from my laptop and notes right now but I think that it might be possible to register 0x0E and 0x0F handlers that do essentially what the aml does, minus the faulty check. Either that, or there might be a way to change the value being checked to prevent it from being faulty in the first place, and not mess around with adding custom handlers in the first place. I'll look into this later tonight. (In reply to Travis James from comment #22) > I'm afraid I'm not familiar enough with the acpi code to know exactly how to > do that, but I have been looking at the way gpe handlers are registered, and > it looks like a function callback can be used instead of executing the aml. > specifically, acpi_ec_run checks for that function, and if it isn't there, > then it executes the aml code. I'm away from my laptop and notes right now > but I think that it might be possible to register 0x0E and 0x0F handlers > that do essentially what the aml does, minus the faulty check. Either that, > or there might be a way to change the value being checked to prevent it from > being faulty in the first place, and not mess around with adding custom > handlers in the first place. I'll look into this later tonight. Cool, thanks for looking into this. *********** 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 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. 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 21, and are still experiencing this issue, please change the version to Fedora 21. 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 over 4 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. hi there- this bug still exists. I just bought an Asus Zenbook on which I am running Fedora 22. You can see detailed discussions of the nature of this bug on the Ubuntu tracker at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890 and LK at https://bugzilla.kernel.org/show_bug.cgi?id=92391. It's a bug. I work for Red Hat, and I have the hardware right here. What information do you need ? Is the Zenbook literally the same machine type and model as the original report? If not, please open a new bug because hardware varies generation to generation as does firmware for both the platform and the devices. Hi, (In reply to Josh Boyer from comment #27) > Is the Zenbook literally the same machine type and model as the original > report? If not, please open a new bug because hardware varies generation to > generation as does firmware for both the platform and the devices. Nope, very likely not. As Josh said please open a new bug report, for this new bug report: 1) Make sure you've a 4.2 kernel (the latest) and then: 2) Walk through: http://hansdegoede.livejournal.com/13889.html Note the "video.use_native_backlight=1" kernel cmdline option is gone with the 4.2 kernel, if the problem is backlight control (and not the hotkeys not generating keypresses) please try all 3 of: "acpi_backlight=native", "acpi_backlight=video", "acpi_backlight=vendor" Thanks & Regards, Hans Closing this one out again. Please file the new bug with the info Hans requested. filed at bz#1277785 |