It's probably an issue with my keyboard firmware or ACPI - I don't know. Anyways the problem is that brightness up and down keys generate two events instead of one: # libinput debug-events -event2 DEVICE_ADDED Power Button seat0 default group1 cap:k -event5 DEVICE_ADDED Video Bus seat0 default group2 cap:k -event1 DEVICE_ADDED Power Button seat0 default group3 cap:k -event0 DEVICE_ADDED Lid Switch seat0 default group4 cap:S -event11 DEVICE_ADDED HP Truevision HD seat0 default group5 cap:k -event6 DEVICE_ADDED ELAN Touchscreen Pen seat0 default group6 cap:T size 293x166mm -event7 DEVICE_ADDED ELAN Touchscreen seat0 default group6 cap:t size 302x168mm calib -event9 DEVICE_ADDED Intel Virtual Button driver seat0 default group7 cap:k -event12 DEVICE_ADDED HDA Intel PCH Mic seat0 default group8 cap: -event13 DEVICE_ADDED HDA Intel PCH Headphone seat0 default group8 cap: -event14 DEVICE_ADDED HDA Intel PCH HDMI/DP,pcm=3 seat0 default group8 cap: -event15 DEVICE_ADDED HDA Intel PCH HDMI/DP,pcm=7 seat0 default group8 cap: -event16 DEVICE_ADDED HDA Intel PCH HDMI/DP,pcm=8 seat0 default group8 cap: -event17 DEVICE_ADDED HDA Intel PCH HDMI/DP,pcm=9 seat0 default group8 cap: -event18 DEVICE_ADDED HDA Intel PCH HDMI/DP,pcm=10 seat0 default group8 cap: -event10 DEVICE_ADDED Intel Virtual Button driver seat0 default group9 cap:k -event3 DEVICE_ADDED AT Translated Set 2 keyboard seat0 default group10 cap:k -event4 DEVICE_ADDED SynPS/2 Synaptics TouchPad seat0 default group11 cap:pg size 93x62mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on -event8 DEVICE_ADDED HP Wireless hotkeys seat0 default group12 cap:k -event19 DEVICE_ADDED HP WMI hotkeys seat0 default group13 cap:k -event5 KEYBOARD_KEY +4.35s KEY_BRIGHTNESSDOWN (224) pressed event5 KEYBOARD_KEY +4.35s KEY_BRIGHTNESSDOWN (224) released event5 KEYBOARD_KEY +4.35s KEY_BRIGHTNESSDOWN (224) pressed event5 KEYBOARD_KEY +4.35s KEY_BRIGHTNESSDOWN (224) released # showkey --keycodes kb mode was ?UNKNOWN? [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... keycode 224 press keycode 224 release keycode 224 press keycode 224 release I have also verified this issue after booting straight to /bin/bash - so my desktop environment or/and daemons do no introduce any bugs in keyboard handling. Please let me know what information you need to fix this issue. I have an HP laptop.
$ udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent @@KERNEL[19297.331733] change /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight) UDEV [19297.333908] change /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight) KERNEL[19297.338028] change /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight) UDEV [19297.339621] change /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
Video Bus event source generates this: $ evemu-record /dev/input/event5 # EVEMU 1.3 # Kernel: 4.12.5-300.fc26.x86_64 # DMI: dmi:bvnInsyde:bvrF.21:bd06/13/2017:svnHP:pnHPPavilionx360Convertible:pvrType1ProductConfigId:rvnHP:rn80D1:rvr84.33:cvnHP:ct31:cvrChassisVersion: # Input device name: "Video Bus" # Input device ID: bus 0x19 vendor 0000 product 0x06 version 0000 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 224 (KEY_BRIGHTNESSDOWN) # Event code 225 (KEY_BRIGHTNESSUP) # Event code 227 (KEY_SWITCHVIDEOMODE) # Event code 241 (KEY_VIDEO_NEXT) # Event code 242 (KEY_VIDEO_PREV) # Event code 243 (KEY_BRIGHTNESS_CYCLE) # Event code 244 (KEY_BRIGHTNESS_AUTO) # Event code 245 (KEY_DISPLAY_OFF) # Properties: N: Video Bus I: 0019 0000 0006 0000 P: 00 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 0b 00 3e 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 00 00 00 00 00 00 00 00 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 ################################ # Waiting for events # ################################ E: 0.000001 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.000036 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.000036 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.000052 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.000052 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.000058 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.000058 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 4.922153 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 4.922153 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +4922ms E: 4.922183 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 4.922183 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 4.922199 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 4.922199 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 4.922206 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 4.922206 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms This looks like a bug in the intel video driver.
Just in case https://bugs.freedesktop.org/show_bug.cgi?id=102309
Hi, About the events from the "Video Bus" input device, is that from a single press of both keys ? I'm asking because the log shows 2 presses of each key really close to each other. Normally if you've double brightness hotkey presses they are coming from 2 different sources, e.g. once from the "Video Bus" input device and once from the "AT Translated Set 2 keyboard" Looking at the libinput log I'm also seeing 2 press events from the brightness key on the "Video Bus", so I guess that this really is a case of a single input device generating double press events for a single press? Regards, Hans
> About the events from the "Video Bus" input device, is that from a single > press of both keys ? `evemu-record /dev/input/event5` log above contains two keys pressed: one for brightness down and one for brightness up. > e.g. once from the "Video Bus" input device and once from the "AT Translated > Set 2 keyboard" I've verified that "AT Translated Set 2 keyboard" doesn't generate brightness events (keypresses) at all. > so I guess that this really is a case of a single input device generating > double press events for a single press? I believe so.
please attach the acpidump output. please attach the output of "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the key. please check if there is any difference if you boot with module parameter video.report_key_events=0.
> video.report_key_events=0 Disable brightness keys altogether. # grep . /sys/firmware/acpi/interrupts/* /sys/firmware/acpi/interrupts/error: 0 /sys/firmware/acpi/interrupts/ff_gbl_lock: 0 EN enabled unmasked /sys/firmware/acpi/interrupts/ff_pmtimer: 0 STS invalid unmasked /sys/firmware/acpi/interrupts/ff_pwr_btn: 0 EN enabled unmasked /sys/firmware/acpi/interrupts/ff_rt_clk: 0 disabled unmasked /sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe00: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe01: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe02: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe03: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe04: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe05: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe06: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe07: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe08: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe09: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe0F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe10: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe11: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe12: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe13: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe14: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe15: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe16: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe17: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe18: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe19: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe1F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe20: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe21: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe22: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe23: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe24: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe25: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe26: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe27: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe28: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe29: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe2F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe30: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe31: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe32: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe33: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe34: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe35: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe36: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe37: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe38: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe39: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe3F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe40: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe41: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe42: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe43: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe44: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe45: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe46: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe47: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe48: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe49: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe4F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe50: 116 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe51: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe52: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe53: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe54: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe55: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe56: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe57: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe58: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe59: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe5F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe60: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe61: 0 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe62: 0 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe63: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe64: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe65: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe66: 4 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe67: 0 enabled unmasked /sys/firmware/acpi/interrupts/gpe68: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe69: 0 disabled unmasked /sys/firmware/acpi/interrupts/gpe6A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe6B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe6C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe6D: 0 disabled unmasked /sys/firmware/acpi/interrupts/gpe6E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe6F: 0 EN enabled unmasked /sys/firmware/acpi/interrupts/gpe70: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe71: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe72: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe73: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe74: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe75: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe76: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe77: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe78: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe79: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7A: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7B: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7C: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7D: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7E: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe7F: 0 invalid unmasked /sys/firmware/acpi/interrupts/gpe_all: 120 /sys/firmware/acpi/interrupts/sci: 120 /sys/firmware/acpi/interrupts/sci_not: 0 After pressing brightness up once: -/sys/firmware/acpi/interrupts/gpe50: 128 EN enabled unmasked +/sys/firmware/acpi/interrupts/gpe50: 130 EN enabled unmasked -/sys/firmware/acpi/interrupts/gpe_all: 132 -/sys/firmware/acpi/interrupts/sci: 132 +/sys/firmware/acpi/interrupts/gpe_all: 134 +/sys/firmware/acpi/interrupts/sci: 134
Created attachment 258135 [details] acpidump
(In reply to Artem S. Tashkinov from comment #7) > > video.report_key_events=0 > > Disable brightness keys altogether. > so, for a single press, there are two events without the parameter, and none event with the parameter?
(In reply to Zhang Rui from comment #9) > (In reply to Artem S. Tashkinov from comment #7) > > > video.report_key_events=0 > > > > Disable brightness keys altogether. > > > so, for a single press, there are two events without the parameter, and none > event with the parameter? Exactly. Sorry for the mistake - I meant "Disables brightness keys altogether".
So, the only way I can see to fix this is to "debounce" the brightness events. Set an ignore_brightness_events boolean on the 1st event, start a timer to go off in 100ms and clear the bool from the timer handler.
GPE 0x50 seems to be EC event. And we got two EC events for a single key press. I agree the solution could fix the problem. but I'd still like to dig a little further if possible to see why we got two EC events... Artem, what's the model of your laptop?
(In reply to Zhang Rui from comment #12) > Artem, what's the model of your laptop? I'll just link to its website: https://support.hp.com/us-en/product/hp-pavilion-13-s100-x360-convertible-pc/8499316/model/9259076/manuals if you don't mind.
Hi, Rui In theory, we must avoid invoking GPE 0x50 handler twice for no reason. However it looks GPE50 is not handled by ACPI subsystem: Searching Method (_L: 196703\dsdt.dsl (9 hits) Line 4414: Method (_L6D, 0, Serialized) // _Lxx: Level-Triggered GPE Line 15818: Method (_LID, 0, NotSerialized) // _LID: Lid Status Line 19652: Method (_L69, 0, Serialized) // _Lxx: Level-Triggered GPE Line 19694: Method (_L61, 0, NotSerialized) // _Lxx: Level-Triggered GPE Line 20266: Method (_L62, 0, NotSerialized) // _Lxx: Level-Triggered GPE Line 20289: Method (_L66, 0, NotSerialized) // _Lxx: Level-Triggered GPE Line 20297: Method (_L67, 0, NotSerialized) // _Lxx: Level-Triggered GPE Line 20303: Method (_L6F, 0, NotSerialized) // _Lxx: Level-Triggered GPE Line 36568: Method (_LID, 0, NotSerialized) // _LID: Lid Status Searching Method (_E: C:\Users\lvzheng\Desktop\196703\dsdt.dsl (1 hit) Line 20355: Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device How do you know it is an EC GPE? Scope (_SB.PCI0.LPCB) { Device (EC0) { Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */) // _HID: Hardware ID Method (_GPE, 0, NotSerialized) // _GPE: General Purpose Events { Local0 = GGPE (0x02040010) Return (Local0) } Thanks Lv
Could you guys help to confirm: 1. Enable CONFIG_DEBUG_FS=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUGGER=y CONFIG_ACPI_DEBUGGER_USER=m and rebuild the kernel 2. In kernel source tree, build acpidbg utility: # cd tools # make acpi 3. Boot the kernel and do the following command # modprobe acpi_dbg # mount -t debugfs none /sys/kernel/debug # tools/power/acpi/acpidbg -b "ex \_SB.PCI0.LPCB.EC0._GPE" If the result is 0x50, then: 4. Boot the kernel with dyndbg="file drivers/acpi/ec.c +p"; 5. Reproduce the issue and upload the dmesg output here (Please help to mark the dmesg output for where a key press begins and the key press ends).
> Please help to mark the dmesg output for where a key press begins and the key > press ends You can do this for example by: dmesg -c > press.log echo "start pressing xxx" >> press.log do the test dmesg -c >> press.log echo "stop pressing xxx" >> press.log Thanks in advance.
Ping... Is there anyone still working on this issue? Note if the key press is just a result of an AML Notify() call. It is likely that there are wrong AML execution paths (may be BIOS issue or Linux issue) touching the Notify() twice, causing such a duplication. I'm not an expert of video bus EV_KEY / KEY_BRIGHTNESSDOWN. Maybe you can tell me if this is GPE, or EC, or AML notification related. Thanks Lv
(In reply to Lv Zheng from comment #17) > Ping... > Is there anyone still working on this issue? > > Note if the key press is just a result of an AML Notify() call. > It is likely that there are wrong AML execution paths (may be BIOS issue or > Linux issue) touching the Notify() twice, causing such a duplication. > I'm not an expert of video bus EV_KEY / KEY_BRIGHTNESSDOWN. Maybe you can > tell me if this is GPE, or EC, or AML notification related. > please check comment #12.
You mean this because of comment 7? > GPE 0x50 seems to be EC event. TBH, I don't know if it is related. Anytime, if you have AML code executed related to EC opregion accesses, EC GPE# will increase. How do you confirm they are related?
And how do you confirm if GPE50 is an EC GPE? We don't have dmesg output here. From acpidump, we got: Method (_GPE, 0, NotSerialized) // _GPE: General Purpose Events { Local0 = GGPE (0x02040010) Return (Local0) } How do you know GGPE(0x02040010) returns 0x50? Thanks Lv
I think you can remove AC adapter, and monitor your gpe#, surely you'll see several gpe# increased, so how can we relate the increment of a GPE to a brightness key press if we don't know whether there are background GPEs triggered.
Ping, any test feedback for comment 15 and comment 16 that I can obtain? Also, it will be helpful if someone can try this tree which contains all GPE/EC irq losses/duplications fixes as far as I know to confirm it isn't a known issue: https://github.com/zetalog/linux/tree/acpi-ec For this bug, if it is related to GPE duplications, then this commit might be useful: https://github.com/zetalog/linux/commit/9885704ba3b
(In reply to Lv Zheng from comment #22) > Ping, any test feedback for comment 15 and comment 16 that I can obtain? > I've seen both comments and I couldn't understand whose input you were looking for. Mine or anyone's who's subscribed to this bug report? I can probably compile and run a debug kernel on my PC, as well as try the above patches but I'm not much willing to because I'm scared to stress my laptop so much (it has a very feeble fan). If I'm the only one who can help resolve this bug report then I will test everything.
Also, I'd like to know whether this patch is already included in mainline. Too bad Fedora hasn't yet compiled 4.14-rc2 but I can perfectly compile the kernel on my own. In fact on my desktop I've always run the vanilla kernel.
Hi, Artem You seem to be the only reporter owning the affected platform, so please assume the responsibility of helping us to achieve the remote debugging. I asked for 3 validations, let me clarify. Test 1 (you can use recent upstream kernel, you can also use the kernel cloned in test 3): 1. Enable CONFIG_DEBUG_FS=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUGGER=y CONFIG_ACPI_DEBUGGER_USER=m and rebuild the kernel 2. In kernel source tree, build acpidbg utility: # cd tools # make acpi 3. Boot the kernel and do the following command # modprobe acpi_dbg # mount -t debugfs none /sys/kernel/debug # tools/power/acpi/acpidbg -b "ex \_SB.PCI0.LPCB.EC0._GPE" 4. Post the result here The test is to confirm if the key press is related to embedded controller. Test 2 (you can use recent upstream kernel, you can also use the kernel cloned in test 3): 1. Boot the kernel with dyndbg="file drivers/acpi/ec.c +p"; 2. Reproduce the issue and upload the dmesg output here. Please help to mark the dmesg output for where a key press begins and the key press ends, you can do this by: 2.1. dmesg -c > press.log 2.2. echo "start pressing xxx" >> press.log 2.3. do the test to reproduce the issue 2.4. dmesg -c >> press.log 2.5. echo "stop pressing xxx" >> press.log 3. Post the press.log here. The test can help us to know the underlying details of the key press. Test 3 (you should use the kernel I provided): 1. Clone the kernel containing the fixes: # git clone https://github.com/zetalog/linux # cd linux # git checkout acpi-ec 2. Build the kernel and boot it. 3. Try the kernel to see if the problem can be reproduced. 4. Post your observation here. It's OK if it can still be reproduced, the test is just to confirm if this is an ACPI issue. Thanks in advance.
Bug closed as there is no response from the bug reporter. Artem, please feel free to reopen it if you can provide the information required in comment #25.
Created attachment 276253 [details] test2 with the brightness up and brightness down keys pressed once
Created attachment 276255 [details] test 2 again
If Fedora enables ACPI_DEBUGGER_USER and ACPI_DEBUGGER I will post the data for test 1. I've file a bug report against rawhide kernel ( https://bugzilla.redhat.com/show_bug.cgi?id=1583628 )
[ 134.810358] ACPI: EC: Query(0x1c) scheduled [ 134.810363] ACPI: EC: Query(0x1c) started [ 134.811507] ACPI: EC: Query(0x1c) stopped ... [ 136.171346] ACPI: EC: Query(0x1d) scheduled [ 136.171352] ACPI: EC: Query(0x1d) started [ 136.172549] ACPI: EC: Query(0x1d) stopped I don't see duplicate EC query values, but instead, there are two queries, 0x1C and 0x1D. (In reply to Artem S. Tashkinov from comment #27) > Created attachment 276253 [details] > test2 with the brightness up and brightness down keys pressed once So I guess you did the test with one brightness up key press and one brightness down key press, right? If this is true, then the log seems normal to me. I don't see how the input event are generated twice.
Created attachment 276829 [details] brightness.sh (In reply to Zhang Rui from comment #30) > [ 134.810358] ACPI: EC: Query(0x1c) scheduled > [ 134.810363] ACPI: EC: Query(0x1c) started > [ 134.811507] ACPI: EC: Query(0x1c) stopped > ... > [ 136.171346] ACPI: EC: Query(0x1d) scheduled > [ 136.171352] ACPI: EC: Query(0x1d) started > [ 136.172549] ACPI: EC: Query(0x1d) stopped > > I don't see duplicate EC query values, but instead, there are two queries, > 0x1C and 0x1D. > > (In reply to Artem S. Tashkinov from comment #27) > > Created attachment 276253 [details] > > test2 with the brightness up and brightness down keys pressed once > > So I guess you did the test with one brightness up key press and one > brightness down key press, right? > If this is true, then the log seems normal to me. > I don't see how the input event are generated twice. OK, here's my set up. I'm running pretty default Fedora 28 installation with the acpid daemon ( acpid-2.0.29-1.fc28.x86_64 ). At /etc/acpi/actions I have a script brightness.sh which is attached to this bug report. Whenever I click brightness up or down buttons, I see two events being recorded at /tmp/brightness. Perhaps this script is wrong. Perhaps, acpid is malfunctioning, perhaps I don't understand how acpid actions should be written - in short I seek advice.
(In reply to Artem S. Tashkinov from comment #31) > Created attachment 276829 [details] > brightness.sh > > (In reply to Zhang Rui from comment #30) > > [ 134.810358] ACPI: EC: Query(0x1c) scheduled > > [ 134.810363] ACPI: EC: Query(0x1c) started > > [ 134.811507] ACPI: EC: Query(0x1c) stopped > > ... > > [ 136.171346] ACPI: EC: Query(0x1d) scheduled > > [ 136.171352] ACPI: EC: Query(0x1d) started > > [ 136.172549] ACPI: EC: Query(0x1d) stopped > > > > I don't see duplicate EC query values, but instead, there are two queries, > > 0x1C and 0x1D. > > > > (In reply to Artem S. Tashkinov from comment #27) > > > Created attachment 276253 [details] > > > test2 with the brightness up and brightness down keys pressed once > > > > So I guess you did the test with one brightness up key press and one > > brightness down key press, right? > > If this is true, then the log seems normal to me. > > I don't see how the input event are generated twice. > > OK, here's my set up. > > I'm running pretty default Fedora 28 installation with the acpid daemon ( > acpid-2.0.29-1.fc28.x86_64 ). > > At /etc/acpi/actions I have a script brightness.sh which is attached to this > bug report. why you need this script? can the backlight be changed without this script? I suppose you also have a brightness script in /etc/acpi/events/, right? can you please attach it as well. > > Whenever I click brightness up or down buttons, I see two events being > recorded at /tmp/brightness. TBH, I don't see why this brightness change should be handled by acpid, instead, the event should be raised to input layer. > > Perhaps this script is wrong. Perhaps, acpid is malfunctioning, perhaps I > don't understand how acpid actions should be written - in short I seek > advice. I just don't understand why you need acpid actions upon brightness hotkey press.
Bug closed as there is no response from the bug reporter. But please feel free to reopen it if you can answer the questions in comment #32.
I'm sorry I kinda missed your earlier reply. (In reply to Zhang Rui from comment #32) > why you need this script? > can the backlight be changed without this script? No, nothing happens without it. > > I suppose you also have a brightness script in /etc/acpi/events/, right? > can you please attach it as well. Already attached it earlier. brightness.sh (426 bytes, application/x-shellscript) 2018-06-25 12:22 UTC, Artem S. Tashkinov > TBH, I don't see why this brightness change should be handled by acpid, > instead, the event should be raised to input layer. I don't know why my Fedora doesn't do anything about brightness. Perhaps it must be done by some daemon which is not installed by default in XFCE or I haven't installed some XFCE component. > > I just don't understand why you need acpid actions upon brightness hotkey > press. My XFCE environment doesn't respond to these event, so I wrote a script.
well, this seems to be a BIOS issue that two ACPI events for brightness up/down are generated for a single press. For this case, IMO, introducing some ugly code (set a timer to ignore subsequential events) is unlike to get merged into upstream kernel. So ,if we can not get the the BIOS fixed, a better way is to workaround this in your script to ignore the duplicated hotkey event. Thus I'd prefer to close this bug report as I don't think we will do anything in kernel to handle this buggy BIOS. Please feel free to reopen it if you still have any questions.