I recently received an ASUS UX301 laptop. After installing Fedora 21 and then using a git kernel (v3.16-rc5-152-g59ca9ee42838) things worked well except the brightness keys. (The keys didn't work in the 3.11.10 kernel, or any other kernel I tried either.) After some debugging, I figured out the ACPI events for the keys are never actually being sent to the kernel at all. Matthew Garrett and I poked at this over the course of a few days and found a few things. 1) _DOD is returning 16 devices. The last device has a device_id of 0x400 and appears to be the device being used. 2) intel_didl_outputs is only looping through and setting up 8 devices in didl. intel_setup_cadls is looping through and blindly assigning the id from didl[i] to cadl[i] even though the active device might not be in the first 8 devices. This probably works on most machines because DIDL is only 8 in length. 3) The AML from this machine is a bit odd, in that it references methods from the LCDD device, which tries to figure out which active device to return in it's CDDS method. Since the active device in question isn't listed in any of the CADL entries, the AML method fails and no events are sent to the kernel. 4) If I blindly slam the returned device_id (0x400) into cadl[0], the brightness keys work as expected with the backlight being adjusted and the OSD in GNOME popping up. Clearly that isn't a solution, but it does lead to some hints as to what the problem is. The acpidump output for the machine can be found here: https://jwboyer.fedorapeople.org/pub/acpi.dump
Is there anything else I can provide to help this bug along?
Josh, sorry for the delay. Please try the opregion-didl branch from my repo at http://cgit.freedesktop.org/~jani/drm/log/?h=opregion-didl and attach /sys/kernel/debug/dri/0/i915_opregion. It's still a work-in-progress but should at least go through more devices. Are you sure _DOD is returning 16 devices, and the one being used is last? Even with the extended didl in my branch it's up to 15 devices. With debug log level, do you see "More than 8 outputs detected via ACPI" or "More than 8 outputs in connector list" in dmesg? (Or s/8/15/ with my patches.)
Created attachment 105999 [details] /sys/kernel/debug/dri/0/i915_opregion Hi Jani, Attached is the i915_opregion file you requested using a kernel built from your opregion-didl branch. I'm not sure if you were expecting it to fix the brightness keys or not, but it doesn't. The slider in GNOME still works. Yes, DOD is returning more than 15 devices: [ 2.229265] i915 0000:00:02.0: More than 15 outputs detected via ACPI In the ssdt7.dsl file, the firmware enumerates devices DD0-DDF and then an additional device LCDD. The LCDD device is what seems to be associated with the function keys via the EC according to ACPI. It gets a device ID of 0x400.
Josh, thanks for the info. I had a good look at this, and unfortunately it looks a bit difficult to fix this in a sane way without regressing commit 3143751ff51a163b77f7efd389043e038f3e008e Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Mar 29 15:12:16 2010 +0800 drm/i915: set DIDL using the ACPI video output device _ADR method return. and https://bugzilla.kernel.org/show_bug.cgi?id=15054 at the same time. Without that commit, we'd have more of a free hand in picking the device IDs for DIDL, and in particular making a sane mapping from our connectors, so we could update CPDL and CADL as well. Lowering the priority for now.
Yes, when I looked at it I came to a similar conclusion. From my understanding, what would need to be done is essentially having i915 keep a mapping of it's connectors to the ACPI device id's that are returned via the _ADR method. The only way I know how to do that is to decode them according to the opregion spec, but it does seem to be possible. Once that mapping is created, i915 could set CADL whenever the display switches to a new connector. The shortcut is to just quirk this somehow, but that doesn't sound like a good overall solution.
I have an ASUS UX301LAA notebook running 3.16.5 (and 3.17) kernel and the backlight keys also doesn't work for me. But - it looks like there might be some clash between backlight providers, there are two providers: acpi_nb_wmi (type:platform) and intel_backlight (type:raw) # ls -ld /sys/class/backlight/* lrwxrwxrwx. 1 root root 0 Nov 2 15:12 /sys/class/backlight/asus-nb-wmi -> ../../devices/platform/asus-nb-wmi/backlight/asus-nb-wmi lrwxrwxrwx. 1 root root 0 Nov 2 15:12 /sys/class/backlight/intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight Manipulating brightness manually in intel_backlight in fact does change the brightness and I can modify brightness with hacked gsd-backlight-helper that prefers type=raw instead of type=platform using the slider controls in gnome-shell. I can confirm that keyboard (Fn-F5 and Fn-F6) does not work and they also don't generated any events in xev (keyboard brightness keys do). There was an Ubuntu patch that added enable_backlight=0 option to the module, so it can be disabled, but alas it doesn't apply on 3.16 anymore. I think it might be usefull to have such option to at least test whether disabling intel_backlight and letting asus_nb_wmi handle the backlight helps. Not sure whether this is bug in i915 or asus_nb_wmi though (or both). Not sure whether this was helpful, but at least you have one more person to help with debugging.
(In reply to Ondrej Sury from comment #6) > I have an ASUS UX301LAA notebook running 3.16.5 (and 3.17) kernel and the > backlight keys also doesn't work for me. > > But - it looks like there might be some clash between backlight providers, > there are two providers: acpi_nb_wmi (type:platform) and intel_backlight > (type:raw) Just realized that I had "acpi_osi=Linux acpi_backlight=vendor", without it there's just intel_backlight. But the Fn-keys don't work.
(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. 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.
I'll update this bugzilla thread since it seems to be the most recently updated. I went ahead and recompiled the v3.17.2 kernel with acpi debugging messages and set the following values for acpi.debug_layer and acpi.debug_level: acpi.debug_layer: 0x10 (ACPI_NAMESPACE) acpi.debug_level: 0x200 (ACPI_LV_EXEC) and the values I got out of doing that when first holding down the Fn key, and then pressing Fn+F5 4 times and then Fn+F6 4 times, and then releasing the Fn key are: kern :warn : [ +1.608662] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.261245] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037287] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037325] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037946] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.036701] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037328] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037335] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037332] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.038215] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037337] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.036424] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037342] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037254] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037327] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037359] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037338] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037326] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.005329] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0E] at AML address ffffc90000034377 length DD kern :warn : [ +0.638591] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0E] at AML address ffffc90000034377 length DD kern :warn : [ +0.458512] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0E] at AML address ffffc90000034377 length DD kern :warn : [ +0.389131] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0E] at AML address ffffc90000034377 length DD kern :warn : [ +1.275360] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0F] at AML address ffffc9000003445d length D4 kern :warn : [ +0.286998] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0F] at AML address ffffc9000003445d length D4 kern :warn : [ +0.293291] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0F] at AML address ffffc9000003445d length D4 kern :warn : [ +0.329615] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0F] at AML address ffffc9000003445d length D4 kern :warn : [ +0.842362] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD4] at AML address ffffc90000034b03 length 19 By contrast, here is what it looks like when I press down the Fn key for a short period of time, then press F3 (to do Fn+F3, or "decrease keyboard brightness) 4 times and then do Fn+F4 ("increase keyboard brightness") and then release the Fn key: kern :warn : [ +3.079854] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.261215] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037314] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037375] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.037325] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD3] at AML address ffffc90000034afc length FFFFFFFF kern :warn : [ +0.021356] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0C] at AML address ffffc90000034300 length E kern :warn : [ +0.000082] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd8] (rel) "_WED" kern :warn : [ +0.000005] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.002358] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64a50] (rel) "WMNB" kern :warn : [ +0.000012] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD.WMNB] at AML address ffffc9000002d84d length 122A kern :warn : [ +0.000021] nsobject-0155 ns_attach_object : Installing ffff8800d087d558 into Node ffff8802131be410 [IIA0] kern :warn : [ +0.000017] nsobject-0155 ns_attach_object : Installing ffff880213287af8 into Node ffff8802131be3c0 [IIA1] kern :warn : [ +0.253535] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0C] at AML address ffffc90000034300 length E kern :warn : [ +0.000148] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000010] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.282423] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0C] at AML address ffffc90000034300 length E kern :warn : [ +0.000082] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000006] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.271846] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0C] at AML address ffffc90000034300 length E kern :warn : [ +0.000082] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000005] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.703702] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0D] at AML address ffffc90000034316 length E kern :warn : [ +0.000159] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64f48] (rel) "_WED" kern :warn : [ +0.000011] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.002852] nsutils-0324 ns_build_internal_name: Returning [ffff88002e235c60] (rel) "WMNB" kern :warn : [ +0.000020] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD.WMNB] at AML address ffffc9000002d84d length 122A kern :warn : [ +0.000037] nsobject-0155 ns_attach_object : Installing ffff88002e056e10 into Node ffff88002df3d578 [IIA0] kern :warn : [ +0.000030] nsobject-0155 ns_attach_object : Installing ffff88002e056ee8 into Node ffff88002df3d550 [IIA1] kern :warn : [ +0.279460] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0D] at AML address ffffc90000034316 length E kern :warn : [ +0.000084] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000005] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.001597] nsutils-0324 ns_build_internal_name: Returning [ffff880210e28400] (rel) "WMNB" kern :warn : [ +0.000010] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD.WMNB] at AML address ffffc9000002d84d length 122A kern :warn : [ +0.000019] nsobject-0155 ns_attach_object : Installing ffff8802036d4630 into Node ffff8800cc9d43e8 [IIA0] kern :warn : [ +0.000017] nsobject-0155 ns_attach_object : Installing ffff88021327a750 into Node ffff8800cc9d43c0 [IIA1] kern :warn : [ +0.285259] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0D] at AML address ffffc90000034316 length E kern :warn : [ +0.000082] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000006] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.001368] nsutils-0324 ns_build_internal_name: Returning [ffff880210e28400] (rel) "WMNB" kern :warn : [ +0.000008] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD.WMNB] at AML address ffffc9000002d84d length 122A kern :warn : [ +0.000019] nsobject-0155 ns_attach_object : Installing ffff88021327a948 into Node ffff8800cc9d43c0 [IIA0] kern :warn : [ +0.000015] nsobject-0155 ns_attach_object : Installing ffff88021327aab0 into Node ffff8800cc9d43e8 [IIA1] kern :warn : [ +0.265102] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._Q0D] at AML address ffffc90000034316 length E kern :warn : [ +0.000080] nsutils-0324 ns_build_internal_name: Returning [ffff880200d64cd0] (rel) "_WED" kern :warn : [ +0.000006] nseval-0228 ns_evaluate : **** Execute method [\_SB_.ATKD._WED] at AML address ffffc9000002ea7f length C kern :warn : [ +0.351702] nseval-0228 ns_evaluate : **** Execute method [\_SB_.PCI0.LPCB.EC0_._QD4] at AML address ffffc90000034b03 length 19 I still have no great understanding about how the AML system works, but at least Ive got ACPI namespace paths out of it. looks like I'm getting namespace paths and everything out of the embedded controller.
Aaron might be interested in comment #8 and comment #9.
I've been referenced to this bug by Aaron after reporting my findings on non-working Fn+F5/F6 with ASUS UX32LN ultrabook in #92391. Looks like my situation is somewhat similar to what Josh got on his UX301 which isn't surprising keeping in mind the same manufacturer and pretty similar hardware configs of these ultrabooks. What I have on my UX32LN is uninitialized CADL region and uninitialized SANV.DIDX which is expected to contain ID of eDP panel which is in turn expected to conform to pattern ((ID & 0x0F00) == 0x400). Reading SSDT code it seems that firmware expects didl to contain max 15 entries (_DOD method does not contain logic to return more active devices) which might be a problem in my case which leads to uninitialized CADL - as far as I understand correctly current version of i915 drm in the mainline kernel does not enumerate more than 8 DIDL entries. I would like to check if my problem could be fixed by using Jani's opregion-didl branch but it seems it had diverged into two separate refs: didl and didl-3.18. Which one should I use to compile a testing kernel? What Kconfigs are essential to be enabled/disabled for testing purposes and providing valuable debug output? Thanks in advance for your help.
A not-so-small followup. Here are dumps of areas of interest from IGDM and SANV after a fresh bootup of debian 3.18-1~exp1 kernel: IGDM.DIDL: root@lx2netbook:~# { dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x120 )) count=32 bs=1; dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x1C4 )) count=28 bs=1 ; } 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 00000100 00000002 00000300 00000301 00000302 00000303 00000304 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 IGDM.CADL: root@lx2netbook:~# { dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x160 )) count=32 bs=1;} 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 00000100 00000002 00000300 00000301 00000302 00000303 00000304 00000008 SANV.DIDX: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 315)) count=4 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 80010410 SANV.EDPV: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 310)) count=1 2>-| hexdump -v -e ' 16/1 "%.2X " "\n" ' 02 SANV.NDID: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 232)) count=1 2>-| hexdump -v -e ' 16/1 "%.2X " "\n" ' 08 SANV.DID1 .. SANV.DID8: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 233)) count=32 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 80000002 80000100 80000300 80000301 80000302 80000303 80000304 80000008 SANV.DID9 .. SANV.DIDB: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 16)) count=12 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 00000000 00000000 00000000 SANV.DIDC .. SANV.DIDF: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 101)) count=16 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 00000000 00000000 00000000 00000000 Looks like DIDX and EDPV were somehow initialized (maybe by EFI firmware prior to kernel bootup?) and EDPV value of 2 suggests that it was initialized in DD02._ADR method. It is not exactly clear why DIDX became 0x80010410. For the case when EDPV equals to 2 it should be that SANV.DIDX==SANV.DID2 (initialized in DD02._ADR). SANV.DID2 gets initialized in GFX0._DOD like DID2=SDDL(IGDM.DIDL). Method SDDL transforms DIDL like this: (DIDL & 0x0F0F) | 0x80000000. So it is unclear why is bit 4 is high in the first byte of DID2. The same stands for lowest bit of the third byte. Maybe it is controlled elsewhere either by the ACPI or by the gfx driver or by the hardware. What seems obvious is that IGDM.DIDL had changed at some point after EDPV and DIDX got initialized. Then the CADL had been "reinitialized" with a new values from the DIDL and the GFX0._DOD method had been invoked resulting in re-population of SANV.DID1..SANV.DIDF. This findings are consistent through a number of different kernel versions, namely (debian kernels): 3.13.5-1, 3.14.15-2, 3.17-1~exp1 and 3.18-1~exp1. With old and dusty 3.2.32-1 the behavior is different: a) i915 fails to load with "[drmi:i915_init] *ERROR* drm/i915 can't work without intel_agp module!" message. This results in lack of kernel modesetting and X falling back to vesa driver. b) Pressing Fn+F5/F6 at text console results in ACPI related messages in dmesg like: Feb 17 20:26:08 lx2netbook kernel: [ 342.302819] ACPI Error: Result stack is empty! State=ffff880224697400 (20110623/dswstate-98) Feb 17 20:26:08 lx2netbook kernel: [ 342.302996] ACPI Exception: AE_AML_NO_RETURN_VALUE, Missing or null operand (20110623/dsutils-646) Feb 17 20:26:08 lx2netbook kernel: [ 342.303169] ACPI Exception: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20110623/dsutils-763) Feb 17 20:26:08 lx2netbook kernel: [ 342.303342] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff8802260d8880), AE_AML_NO_RETURN_VALUE (20110623/psparse-536) Feb 17 20:26:08 lx2netbook kernel: [ 342.303607] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff88022609e920), AE_AML_NO_RETURN_VALUE (20110623/psparse-536) Feb 17 20:26:08 lx2netbook kernel: [ 342.303872] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff88022609e8d0), AE_AML_NO_RETURN_VALUE (20110623/psparse-536) c) CADL/DIDL are totally empty, i.e. are filled with zeroes. Meanwhile DIDX stays at 0x80010410, EDPV equals to 2 and SANV.DIDx are initialized to some interesting numbers: root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 233)) count=32 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" ' 80010100 80010410 80016330 80017331 80017342 80016353 80017354 00000000 I have no idea what is the source for these and how to interpret then properly. Hope these findings would help people with more knowledge to track down the issue and fix it. I'm still open for trying some experimental kernel builds and am looking for guidance on this matter.
This issue is reproducible also on Asus Zenbook UX303LA with Broadwell: # dmidecode -s bios-version UX303LAB.207 Pressing Fn+F5/F6 seems to emit EC Query 0x0e/0x0f, but the backlight intensity does not change and no key press is emitted using the input subsystem.
Exactly the same problem on an ASUS UX305F. Must be quite a lot of these laptops out there now.... # dmidecode -s bios-version UX305FA.211
FYI, there have been some patches on the list: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105351.html but testing still showed some issues which was acknowledged later: https://lists.freedesktop.org/archives/intel-gfx/2016-October/110244.html
These patches are in 4.10 and fix the Asus X441NV brightness keys. :) drm/i915: make i915 the source of acpi device ids for _DOD drm/i915/opregion: fill in the CADL from connector list, not DIDL drm/i915/opregion: put internal panels to the front of CADL
Nice work Jani, I'm glad you did this.
(In reply to Aaron Lu from comment #17) > Nice work Jani, I'm glad you did this. Thanks Aaron! There's still one patch left that updates CADL dynamically based on active encoders, but unfortunately that regresses. :( I haven't had the time or motivation to look into that because the patches merged so far fix most if not all issues.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.