kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #124352
[Bug 1348890] Re: Asus UX32LN: Brightness keys Fn+F5 and Fn+F6 don't generate evdev event
Launchpad has imported 13 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=81762.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2014-07-25T20:25:37+00:00 Jwboyer-7 wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/0
------------------------------------------------------------------------
On 2014-07-29T14:26:57+00:00 Jwboyer-7 wrote:
Is there anything else I can provide to help this bug along?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/3
------------------------------------------------------------------------
On 2014-09-09T14:21:49+00:00 Jani-nikula wrote:
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.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/16
------------------------------------------------------------------------
On 2014-09-09T19:02:22+00:00 Jwboyer-7 wrote:
Created attachment 105999
/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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/17
------------------------------------------------------------------------
On 2014-09-10T11:51:30+00:00 Jani-nikula wrote:
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@xxxxxxxxx>
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/18
------------------------------------------------------------------------
On 2014-09-10T12:06:11+00:00 Jwboyer-7 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/19
------------------------------------------------------------------------
On 2014-11-02T15:37:47+00:00 Ondřej Surý wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/23
------------------------------------------------------------------------
On 2014-11-02T15:57:41+00:00 Ondřej Surý wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/24
------------------------------------------------------------------------
On 2014-11-08T19:32:06+00:00 Tjames6858 wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/25
------------------------------------------------------------------------
On 2014-11-09T04:21:02+00:00 Tjames6858 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/26
------------------------------------------------------------------------
On 2014-11-10T11:04:30+00:00 Jani-nikula wrote:
Aaron might be interested in comment #8 and comment #9.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/27
------------------------------------------------------------------------
On 2015-02-17T15:23:23+00:00 Lx2 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/28
------------------------------------------------------------------------
On 2015-02-17T18:24:12+00:00 Lx2 wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890/comments/29
** Changed in: linux
Status: Unknown => Confirmed
** Changed in: linux
Importance: Unknown => Wishlist
** Bug watch added: Linux Kernel Bug Tracker #15054
http://bugzilla.kernel.org/show_bug.cgi?id=15054
** Bug watch added: Red Hat Bugzilla #1144866
https://bugzilla.redhat.com/show_bug.cgi?id=1144866
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1348890
Title:
Asus UX32LN: Brightness keys Fn+F5 and Fn+F6 don't generate evdev
event
Status in The Linux Kernel:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
Hello Community,
It seems brightness keys don't work with latest Ubuntu 14.04 LTS for
laptop Asus Zenbook UX32LN.
sudo dmidecode -s bios-version
UX32LN.203
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1348890/+subscriptions
