Bug 1144866

Summary: Backlight keys not working - ASUS N550JV
Product: [Fedora] Fedora Reporter: torvum
Component: kernelAssignee: Hans de Goede <hdegoede>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 22CC: 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 Flags
output of dmesg
none
output of acpidump none

Description torvum 2014-09-21 16:55:58 UTC
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):
3.16.2-200.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Own a ASUS N550JV
2. Boot Fedora

Actual results:
Keys are ineffectual.

Expected results:
Keys adjust backlight brightness.

Comment 1 Hans de Goede 2014-10-01 12:09:13 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

Comment 2 torvum 2014-10-01 17:56:30 UTC
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.

Comment 3 Hans de Goede 2014-10-02 13:06:08 UTC
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 ?

Comment 4 Josh Boyer 2014-10-02 13:18:32 UTC
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.

Comment 5 torvum 2014-10-02 14:35:41 UTC
Created attachment 943387 [details]
output of dmesg

Comment 6 torvum 2014-10-02 14:46:13 UTC
Created attachment 943405 [details]
output of acpidump

Comment 7 torvum 2014-10-02 14:49:09 UTC
@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

Comment 8 Hans de Goede 2014-10-02 15:02:53 UTC
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.

Comment 9 torvum 2014-10-02 21:41:56 UTC
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.

Comment 10 Josh Boyer 2014-10-03 00:49:43 UTC
(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?

Comment 11 torvum 2014-10-03 02:53:00 UTC
@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.

Comment 12 Hans de Goede 2014-10-03 07:43:21 UTC
(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

Comment 13 Hans de Goede 2014-10-03 07:51:06 UTC
(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.

Comment 14 Josh Boyer 2014-10-03 12:21:37 UTC
(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.

Comment 15 torvum 2014-10-03 14:07:05 UTC
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!

Comment 16 Hans de Goede 2014-10-11 13:38:14 UTC
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

Comment 17 Hans de Goede 2014-10-12 10:36:59 UTC
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).

Comment 18 Travis James 2014-11-08 19:22:12 UTC
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.

Comment 19 Hans de Goede 2014-11-10 08:48:58 UTC
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

Comment 20 Travis James 2014-11-23 21:58:30 UTC
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.

Comment 21 Hans de Goede 2014-11-24 08:17:14 UTC
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

Comment 22 Travis James 2014-11-25 17:38:06 UTC
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.

Comment 23 Hans de Goede 2014-11-26 08:32:01 UTC
(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.

Comment 24 Fedora Kernel Team 2015-02-24 16:22:53 UTC
*********** 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.

Comment 25 Fedora Kernel Team 2015-04-28 18:23:53 UTC
*********** 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.

Comment 26 Michael Bayer 2015-11-02 23:55:54 UTC
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 ?

Comment 27 Josh Boyer 2015-11-03 00:24:33 UTC
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.

Comment 28 Hans de Goede 2015-11-03 08:27:14 UTC
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

Comment 29 Josh Boyer 2015-11-03 13:53:20 UTC
Closing this one out again.  Please file the new bug with the info Hans requested.

Comment 30 Michael Bayer 2015-11-04 05:08:00 UTC
filed at bz#1277785