Bug 196703

Summary:	Brightness up/down keys generate two events instead of one
Product:	ACPI	Reporter:	Artem S. Tashkinov (aros)
Component:	Power-Video	Assignee:	Zhang Rui (rui.zhang)
Status:	RESOLVED DOCUMENTED
Severity:	normal	CC:	dmitry.torokhov, jwrdegoede, lenb, rui.zhang
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.12	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	acpidump test2 with the brightness up and brightness down keys pressed once test 2 again brightness.sh

Description Artem S. Tashkinov 2017-08-18 15:49:04 UTC

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.

Comment 1 Artem S. Tashkinov 2017-08-19 20:26:59 UTC

$ 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)

Comment 2 Artem S. Tashkinov 2017-08-19 20:38:50 UTC

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.

Comment 3 Artem S. Tashkinov 2017-08-19 20:46:50 UTC

Just in case https://bugs.freedesktop.org/show_bug.cgi?id=102309

Comment 4 Hans de Goede 2017-08-20 09:02:52 UTC

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

Comment 5 Artem S. Tashkinov 2017-08-20 14:37:19 UTC

> 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.

Comment 6 Zhang Rui 2017-08-28 01:47:00 UTC

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.

Comment 7 Artem S. Tashkinov 2017-08-28 10:03:55 UTC

> 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

Comment 8 Artem S. Tashkinov 2017-08-28 10:06:44 UTC

Created attachment 258135 [details]
acpidump

Comment 9 Zhang Rui 2017-08-29 08:42:31 UTC

(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?

Comment 10 Artem S. Tashkinov 2017-08-29 08:50:35 UTC

(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".

Comment 11 Hans de Goede 2017-08-29 09:09:12 UTC

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.

Comment 12 Zhang Rui 2017-08-29 09:36:37 UTC

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?

Comment 13 Artem S. Tashkinov 2017-08-29 19:29:16 UTC

(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.

Comment 14 Lv Zheng 2017-09-04 08:02:07 UTC

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

Comment 15 Lv Zheng 2017-09-04 08:10:26 UTC

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).

Comment 16 Lv Zheng 2017-09-04 08:28:34 UTC

> 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.

Comment 17 Lv Zheng 2017-09-20 00:31:13 UTC

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

Comment 18 Zhang Rui 2017-09-20 01:44:40 UTC

(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.

Comment 19 Lv Zheng 2017-09-20 01:48:06 UTC

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?

Comment 20 Lv Zheng 2017-09-20 01:49:37 UTC

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

Comment 21 Lv Zheng 2017-09-20 01:52:35 UTC

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.

Comment 22 Lv Zheng 2017-09-29 02:52:44 UTC

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

Comment 23 Artem S. Tashkinov 2017-09-29 08:59:34 UTC

(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.

Comment 24 Artem S. Tashkinov 2017-09-29 09:10:36 UTC

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.

Comment 25 Lv Zheng 2017-10-12 02:39:45 UTC

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.

Comment 26 Zhang Rui 2018-04-02 01:20:25 UTC

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.

Comment 27 Artem S. Tashkinov 2018-05-29 10:28:16 UTC

Created attachment 276253 [details]
test2 with the brightness up and brightness down keys pressed once

Comment 28 Artem S. Tashkinov 2018-05-29 10:33:47 UTC

Created attachment 276255 [details]
test 2 again

Comment 29 Artem S. Tashkinov 2018-05-29 11:58:43 UTC

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 )

Comment 30 Zhang Rui 2018-06-25 07:14:25 UTC

[  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.

Comment 31 Artem S. Tashkinov 2018-06-25 12:22:38 UTC

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.

Comment 32 Zhang Rui 2018-06-26 01:37:09 UTC

(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.

Comment 33 Zhang Rui 2018-08-28 07:50:31 UTC

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.

Comment 34 Artem S. Tashkinov 2018-08-28 17:24:46 UTC

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.

Comment 35 Zhang Rui 2018-12-27 14:40:46 UTC

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.