* [dtor-input:for-linus] BUILD SUCCESS 8b87f67b4c87452e21721887fa8dec1f4c6b2b7c
From: kernel test robot @ 2025-10-09 20:53 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 8b87f67b4c87452e21721887fa8dec1f4c6b2b7c Merge branch 'next' into for-linus
elapsed time: 843m
configs tested: 142
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig clang-22
alpha allyesconfig clang-19
alpha defconfig clang-19
arc allmodconfig clang-19
arc allnoconfig clang-22
arc allyesconfig clang-19
arc axs101_defconfig gcc-15.1.0
arc defconfig clang-19
arm allmodconfig clang-19
arm allnoconfig clang-22
arm allyesconfig clang-19
arm defconfig clang-19
arm imx_v4_v5_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig clang-22
arm64 defconfig clang-19
csky allnoconfig clang-22
csky defconfig clang-19
csky randconfig-001-20251009 clang-16
csky randconfig-002-20251009 clang-16
hexagon allmodconfig clang-19
hexagon allnoconfig clang-22
hexagon allyesconfig clang-19
hexagon defconfig clang-19
hexagon randconfig-001-20251009 clang-16
hexagon randconfig-002-20251009 clang-16
i386 allmodconfig clang-20
i386 allnoconfig clang-20
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20251009 gcc-14
i386 buildonly-randconfig-002-20251009 gcc-14
i386 buildonly-randconfig-003-20251009 gcc-14
i386 buildonly-randconfig-004-20251009 gcc-14
i386 buildonly-randconfig-005-20251009 gcc-14
i386 buildonly-randconfig-006-20251009 gcc-14
i386 defconfig clang-20
i386 randconfig-001-20251010 clang-20
i386 randconfig-002-20251010 clang-20
i386 randconfig-003-20251010 clang-20
i386 randconfig-004-20251010 clang-20
i386 randconfig-005-20251010 clang-20
i386 randconfig-006-20251010 clang-20
i386 randconfig-007-20251010 clang-20
i386 randconfig-011-20251009 clang-20
i386 randconfig-012-20251009 clang-20
i386 randconfig-013-20251009 clang-20
i386 randconfig-014-20251009 clang-20
i386 randconfig-015-20251009 clang-20
i386 randconfig-016-20251009 clang-20
i386 randconfig-017-20251009 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch randconfig-001-20251009 clang-16
loongarch randconfig-002-20251009 clang-16
m68k allmodconfig clang-19
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-19
m68k defconfig clang-19
m68k hp300_defconfig gcc-15.1.0
m68k m5272c3_defconfig gcc-15.1.0
microblaze allmodconfig clang-19
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig clang-19
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
nios2 allnoconfig gcc-15.1.0
nios2 defconfig gcc-15.1.0
nios2 randconfig-001-20251009 clang-16
nios2 randconfig-002-20251009 clang-16
openrisc allnoconfig clang-22
openrisc allyesconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20251009 clang-16
parisc randconfig-002-20251009 clang-16
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allyesconfig gcc-15.1.0
powerpc icon_defconfig gcc-15.1.0
powerpc randconfig-001-20251009 clang-16
powerpc randconfig-002-20251009 clang-16
powerpc randconfig-003-20251009 clang-16
powerpc64 randconfig-002-20251009 clang-16
powerpc64 randconfig-003-20251009 clang-16
riscv allmodconfig gcc-15.1.0
riscv allnoconfig clang-22
riscv allyesconfig gcc-15.1.0
riscv randconfig-001-20251009 clang-22
riscv randconfig-002-20251009 clang-22
s390 alldefconfig gcc-15.1.0
s390 allmodconfig gcc-15.1.0
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 randconfig-001-20251009 clang-22
s390 randconfig-002-20251009 clang-22
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh ecovec24_defconfig gcc-15.1.0
sh randconfig-001-20251009 clang-22
sh randconfig-002-20251009 clang-22
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20251009 clang-22
sparc randconfig-002-20251009 clang-22
sparc64 randconfig-001-20251009 clang-22
sparc64 randconfig-002-20251009 clang-22
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig clang-19
um randconfig-001-20251009 clang-22
um randconfig-002-20251009 clang-22
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251009 clang-20
x86_64 buildonly-randconfig-002-20251009 clang-20
x86_64 buildonly-randconfig-003-20251009 clang-20
x86_64 buildonly-randconfig-004-20251009 clang-20
x86_64 buildonly-randconfig-005-20251009 clang-20
x86_64 buildonly-randconfig-006-20251009 clang-20
x86_64 defconfig clang-20
x86_64 kexec clang-20
x86_64 randconfig-071-20251009 gcc-14
x86_64 randconfig-072-20251009 gcc-14
x86_64 randconfig-073-20251009 gcc-14
x86_64 randconfig-074-20251009 gcc-14
x86_64 randconfig-075-20251009 gcc-14
x86_64 randconfig-076-20251009 gcc-14
x86_64 randconfig-077-20251009 gcc-14
x86_64 randconfig-078-20251009 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20251009 clang-22
xtensa randconfig-002-20251009 clang-22
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS c7866ee0a9ddd9789faadf58cdac6abd7aabf045
From: kernel test robot @ 2025-10-09 21:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: c7866ee0a9ddd9789faadf58cdac6abd7aabf045 Input: atmel_mxt_ts - allow reset GPIO to sleep
elapsed time: 860m
configs tested: 162
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig clang-22
alpha allyesconfig clang-19
alpha defconfig clang-19
arc allmodconfig clang-19
arc allnoconfig clang-22
arc allyesconfig clang-19
arc axs101_defconfig gcc-15.1.0
arc defconfig clang-19
arm allmodconfig clang-19
arm allnoconfig clang-22
arm allyesconfig clang-19
arm defconfig clang-19
arm imx_v4_v5_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allnoconfig clang-22
arm64 defconfig clang-19
csky allnoconfig clang-22
csky defconfig clang-19
csky randconfig-001-20251009 clang-16
csky randconfig-002-20251009 clang-16
hexagon allmodconfig clang-19
hexagon allnoconfig clang-22
hexagon allyesconfig clang-19
hexagon defconfig clang-19
hexagon randconfig-001-20251009 clang-16
hexagon randconfig-002-20251009 clang-16
i386 allmodconfig clang-20
i386 allnoconfig clang-20
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20251009 gcc-14
i386 buildonly-randconfig-001-20251010 gcc-14
i386 buildonly-randconfig-002-20251009 gcc-14
i386 buildonly-randconfig-002-20251010 gcc-14
i386 buildonly-randconfig-003-20251009 gcc-14
i386 buildonly-randconfig-003-20251010 gcc-14
i386 buildonly-randconfig-004-20251009 gcc-14
i386 buildonly-randconfig-004-20251010 gcc-14
i386 buildonly-randconfig-005-20251009 gcc-14
i386 buildonly-randconfig-005-20251010 gcc-14
i386 buildonly-randconfig-006-20251009 gcc-14
i386 buildonly-randconfig-006-20251010 gcc-14
i386 defconfig clang-20
i386 randconfig-001-20251010 clang-20
i386 randconfig-002-20251010 clang-20
i386 randconfig-003-20251010 clang-20
i386 randconfig-004-20251010 clang-20
i386 randconfig-005-20251010 clang-20
i386 randconfig-006-20251010 clang-20
i386 randconfig-007-20251010 clang-20
i386 randconfig-011-20251009 clang-20
i386 randconfig-012-20251009 clang-20
i386 randconfig-013-20251009 clang-20
i386 randconfig-014-20251009 clang-20
i386 randconfig-015-20251009 clang-20
i386 randconfig-016-20251009 clang-20
i386 randconfig-017-20251009 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-22
loongarch defconfig clang-19
loongarch randconfig-001-20251009 clang-16
loongarch randconfig-002-20251009 clang-16
m68k allmodconfig clang-19
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-19
m68k defconfig clang-19
m68k hp300_defconfig gcc-15.1.0
m68k m5272c3_defconfig gcc-15.1.0
microblaze allmodconfig clang-19
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig clang-19
microblaze defconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
nios2 allnoconfig gcc-15.1.0
nios2 defconfig gcc-15.1.0
nios2 randconfig-001-20251009 clang-16
nios2 randconfig-002-20251009 clang-16
openrisc allnoconfig clang-22
openrisc allyesconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20251009 clang-16
parisc randconfig-002-20251009 clang-16
parisc64 defconfig gcc-15.1.0
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allyesconfig gcc-15.1.0
powerpc icon_defconfig gcc-15.1.0
powerpc randconfig-001-20251009 clang-16
powerpc randconfig-002-20251009 clang-16
powerpc randconfig-003-20251009 clang-16
powerpc64 randconfig-002-20251009 clang-16
powerpc64 randconfig-003-20251009 clang-16
riscv allmodconfig gcc-15.1.0
riscv allnoconfig clang-22
riscv allyesconfig gcc-15.1.0
riscv randconfig-001-20251009 clang-22
riscv randconfig-001-20251010 gcc-9.5.0
riscv randconfig-002-20251009 clang-22
riscv randconfig-002-20251010 gcc-9.5.0
s390 alldefconfig gcc-15.1.0
s390 allmodconfig gcc-15.1.0
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 randconfig-001-20251009 clang-22
s390 randconfig-001-20251010 gcc-9.5.0
s390 randconfig-002-20251009 clang-22
s390 randconfig-002-20251010 gcc-9.5.0
sh allmodconfig gcc-15.1.0
sh allnoconfig gcc-15.1.0
sh allyesconfig gcc-15.1.0
sh ecovec24_defconfig gcc-15.1.0
sh randconfig-001-20251009 clang-22
sh randconfig-001-20251010 gcc-9.5.0
sh randconfig-002-20251009 clang-22
sh randconfig-002-20251010 gcc-9.5.0
sparc allmodconfig gcc-15.1.0
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20251009 clang-22
sparc randconfig-001-20251010 gcc-9.5.0
sparc randconfig-002-20251009 clang-22
sparc randconfig-002-20251010 gcc-9.5.0
sparc64 randconfig-001-20251009 clang-22
sparc64 randconfig-001-20251010 gcc-9.5.0
sparc64 randconfig-002-20251009 clang-22
sparc64 randconfig-002-20251010 gcc-9.5.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig clang-19
um randconfig-001-20251009 clang-22
um randconfig-001-20251010 gcc-9.5.0
um randconfig-002-20251009 clang-22
um randconfig-002-20251010 gcc-9.5.0
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251009 clang-20
x86_64 buildonly-randconfig-002-20251009 clang-20
x86_64 buildonly-randconfig-003-20251009 clang-20
x86_64 buildonly-randconfig-004-20251009 clang-20
x86_64 buildonly-randconfig-005-20251009 clang-20
x86_64 buildonly-randconfig-006-20251009 clang-20
x86_64 defconfig clang-20
x86_64 kexec clang-20
x86_64 randconfig-071-20251009 gcc-14
x86_64 randconfig-072-20251009 gcc-14
x86_64 randconfig-073-20251009 gcc-14
x86_64 randconfig-074-20251009 gcc-14
x86_64 randconfig-075-20251009 gcc-14
x86_64 randconfig-076-20251009 gcc-14
x86_64 randconfig-077-20251009 gcc-14
x86_64 randconfig-078-20251009 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.1.0
xtensa randconfig-001-20251009 clang-22
xtensa randconfig-001-20251010 gcc-9.5.0
xtensa randconfig-002-20251009 clang-22
xtensa randconfig-002-20251010 gcc-9.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* HID_HAPTIC=m prevents from linking
From: Lucas GISSOT @ 2025-10-09 21:54 UTC (permalink / raw)
To: linux-input; +Cc: jikos, bentiss
Hello,
I played with `make randconfig` and I managed to have a link error with
CONFIG_HID_HAPTIC=m
CONFIG_HID_MULTITOUCH=y
This is my first mail I send to this domain name, so I might do
something wrong, but it seems to me that the
#if IS_ENABLED(CONFIG_HID_HAPTIC)
in hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
Kconfig updated.
This is the ld error:
LD .tmp_vmlinux1
ld: vmlinux.o: in function `mt_feature_mapping':
hid-multitouch.c:(.text+0xbfe86a): undefined reference to `hid_haptic_feature_mapping'
ld: vmlinux.o: in function `mt_input_configured':
hid-multitouch.c:(.text+0xbfeffa): undefined reference to `hid_haptic_input_configured'
ld: vmlinux.o: in function `mt_probe':
hid-multitouch.c:(.text+0xbff996): undefined reference to `hid_haptic_init'
ld: vmlinux.o: in function `mt_report':
hid-multitouch.c:(.text+0xc001a3): undefined reference to `hid_haptic_pressure_increase'
ld: hid-multitouch.c:(.text+0xc003bf): undefined reference to `hid_haptic_pressure_reset'
ld: vmlinux.o: in function `mt_input_mapping':
hid-multitouch.c:(.text+0xc00607): undefined reference to `hid_haptic_input_mapping'
ld: hid-multitouch.c:(.text+0xc00853): undefined reference to `hid_haptic_check_pressure_unit'
make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
I tested from a defaultconfig for x86_64 plus the changed on HID_HAPTIC
and HID_MULTITOUCH above
Please let me know if I made something wrong in the Cc or else.
Kind regards,
Lucas GISSOT
.
^ permalink raw reply
* [PATCH] HID: playstation: Remap joystick axes to be centered at 0
From: Siarhei Vishniakou @ 2025-10-10 1:20 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Roderick Colenbrander,
linux-input, linux-kernel
Cc: Siarhei Vishniakou
The joystick axes (ABS_X, ABS_Y, ABS_RX, ABS_RY) for PlayStation
gamepads report a neutral state of 128 over HID, with a full range of
[0, 255]. The driver previously mapped this directly, resulting in an
evdev range of [0, 255] with a resting point of 128.
This approach is unconventional for Linux gamepad drivers and has several
drawbacks: it requires userspace applications to be aware of the
non-zero resting state, and it is incompatible with the input
subsystem's 'flat' (deadzone) logic, which assumes a resting point of 0.
This patch remaps the four joystick axes to the conventional signed
8-bit range of [-128, 127], with 0 as the neutral state. This is
accomplished by changing their evdev range in ps_gamepad_create() and
translating the incoming hardware value in the report parsing functions
by subtracting 128.
The analog trigger axes (ABS_Z, ABS_RZ) are handled separately. Their
resting state is 0 (un-pressed), and their hardware range of [0, 255]
is already the conventional representation. They are left unmodified by
this patch.
This makes the joystick behavior consistent with other gamepad drivers
while preserving the standard behavior for the triggers.
Signed-off-by: Siarhei Vishniakou <svv@google.com>
---
drivers/hid/hid-playstation.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 1468fb11e39d..ca5bca9c2654 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -718,11 +718,11 @@ static struct input_dev *ps_gamepad_create(struct hid_device *hdev,
if (IS_ERR(gamepad))
return ERR_CAST(gamepad);
- input_set_abs_params(gamepad, ABS_X, 0, 255, 0, 0);
- input_set_abs_params(gamepad, ABS_Y, 0, 255, 0, 0);
+ input_set_abs_params(gamepad, ABS_X, -128, 127, 0, 0);
+ input_set_abs_params(gamepad, ABS_Y, -128, 127, 0, 0);
input_set_abs_params(gamepad, ABS_Z, 0, 255, 0, 0);
- input_set_abs_params(gamepad, ABS_RX, 0, 255, 0, 0);
- input_set_abs_params(gamepad, ABS_RY, 0, 255, 0, 0);
+ input_set_abs_params(gamepad, ABS_RX, -128, 127, 0, 0);
+ input_set_abs_params(gamepad, ABS_RY, -128, 127, 0, 0);
input_set_abs_params(gamepad, ABS_RZ, 0, 255, 0, 0);
input_set_abs_params(gamepad, ABS_HAT0X, -1, 1, 0, 0);
@@ -1349,10 +1349,10 @@ static int dualsense_parse_report(struct ps_device *ps_dev, struct hid_report *r
return -1;
}
- input_report_abs(ds->gamepad, ABS_X, ds_report->x);
- input_report_abs(ds->gamepad, ABS_Y, ds_report->y);
- input_report_abs(ds->gamepad, ABS_RX, ds_report->rx);
- input_report_abs(ds->gamepad, ABS_RY, ds_report->ry);
+ input_report_abs(ds->gamepad, ABS_X, ds_report->x - 128);
+ input_report_abs(ds->gamepad, ABS_Y, ds_report->y - 128);
+ input_report_abs(ds->gamepad, ABS_RX, ds_report->rx - 128);
+ input_report_abs(ds->gamepad, ABS_RY, ds_report->ry - 128);
input_report_abs(ds->gamepad, ABS_Z, ds_report->z);
input_report_abs(ds->gamepad, ABS_RZ, ds_report->rz);
@@ -2272,10 +2272,10 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
return -1;
}
- input_report_abs(ds4->gamepad, ABS_X, ds4_report->x);
- input_report_abs(ds4->gamepad, ABS_Y, ds4_report->y);
- input_report_abs(ds4->gamepad, ABS_RX, ds4_report->rx);
- input_report_abs(ds4->gamepad, ABS_RY, ds4_report->ry);
+ input_report_abs(ds4->gamepad, ABS_X, ds4_report->x - 128);
+ input_report_abs(ds4->gamepad, ABS_Y, ds4_report->y - 128);
+ input_report_abs(ds4->gamepad, ABS_RX, ds4_report->rx - 128);
+ input_report_abs(ds4->gamepad, ABS_RY, ds4_report->ry - 128);
input_report_abs(ds4->gamepad, ABS_Z, ds4_report->z);
input_report_abs(ds4->gamepad, ABS_RZ, ds4_report->rz);
--
2.51.0.740.g6adb054d12-goog
^ permalink raw reply related
* 答复: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
From: 卢国宏 @ 2025-10-10 2:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: José Expósito, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, jikos@kernel.org,
bentiss@kernel.org, 李鹏, Fei1 Jiang 蒋飞,
宋密密, 卢国宏
In-Reply-To: <39809571f1b7439abd754279fac7e702@xiaomi.com>
Hi Dmitry,
Please let us know whether you plan to merge this solution into the kernel or not! Thanks!
________________________________________
发件人: 卢国宏
发送时间: 2025年9月29日 20:10:42
收件人: Dmitry Torokhov
抄送: José Expósito; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; jikos@kernel.org; bentiss@kernel.org; 李鹏; Fei1 Jiang 蒋飞; 宋密密; 卢国宏
主题: 答复: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
Hi Dmitry,
Any updates on merging your code for reporting a zero battery level in HID devices? I look forward to hearing from you.
Thank you!
________________________________________
发件人: 卢国宏
发送时间: 2025年9月26日 20:03
收件人: Dmitry Torokhov
抄送: José Expósito; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; jikos@kernel.org; bentiss@kernel.org; 李鹏; Fei1 Jiang 蒋飞; 宋密密; 卢国宏
主题: 答复: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
Hi Dmitry,
After testing, we found that your proposed method can solve our problem. Please help merge this method into the Linux kernel as soon as possible! Please remember to send us the relevant information of the merged git so that we can contact Google and merge their Android GKI as well. Our project is looking forward to using this feature. Thank you very much!
________________________________________
发件人: Dmitry Torokhov <dmitry.torokhov@gmail.com>
发送时间: 2025年9月25日 12:26
收件人: 卢国宏
抄送: José Expósito; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; jikos@kernel.org; bentiss@kernel.org; 李鹏; Fei1 Jiang 蒋飞; 宋密密
主题: Re: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈
On Mon, Sep 22, 2025 at 09:29:20AM +0000, 卢国宏 wrote:
>
> What kind of action are we talking about? Section 31 of the HID
> specification defines events for "Smart Battery" ("To comply with the
> Smart Battery Specification, the Battery System must support the
> functions defined in the Battery and Charger usage tables. For details,
> see Section 4.2, “Battery System Page (x85).”) and is typically used for
> "battery pack for cellular phones (principal source), the battery
> pack(s) for notebook computers (auxiliary source), and the sealed
> batteries in uninterruptible power supplies (auxiliary source)."
>
> Is your use case main battery or battery in a stylus or some other
> peripheral?
>
>
> --->>>
> What we are discussing is the code implementation of Section 31 of the
> HID protocol: 31 Battery System Page (0x85). Our scenario is: an
> Android phone is connected to a handle via USB. The handle is a HID
> device with a battery. The power of the battery in the handle is sent
> to the bottom layer (kernel) of the phone via USB. The bottom layer of
> the phone then reports this power to the upper layer of Android
> through the HID driver.
I see. I guess we can try only filtering out 0 reports for the
digitizers, leaving other devices with batteries alone. Something like
this:
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ff1784b5c2a4..ba3f6655af9e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
dev->battery = NULL;
}
-static void hidinput_update_battery(struct hid_device *dev, int value)
+static void hidinput_update_battery(struct hid_device *dev,
+ unsigned int usage, int value)
{
int capacity;
if (!dev->battery)
return;
- if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+ if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+ return;
+
+ if (value < dev->battery_min || value > dev->battery_max)
return;
capacity = hidinput_scale_battery_capacity(dev, value);
@@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
if (!handled)
- hidinput_update_battery(hid, value);
+ hidinput_update_battery(hid, usage->hid, value);
return;
}
Thanks.
--
Dmitry
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: patch Lenovo Yoga Slim 7x Keyboard rdesc
From: Lauri Tirkkonen @ 2025-10-10 3:40 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, linux-input, linux-kernel
In-Reply-To: <56l5tnplzap4mcqcridsavbtvbevhqd235m4m3h4ititj3j5p2@z6oy6wimoodv>
On Thu, Oct 09 2025 10:29:19 +0200, Benjamin Tissoires wrote:
> On Oct 09 2025, Lauri Tirkkonen wrote:
> > This device uses hid-over-i2c, not hid-lenovo; I've got
> > CONFIG_HID_LENOVO=m but the module is not even loaded. I don't see how
> > putting the fixup in a module that does not attach to the device could
> > work. So where should it go?
>
> Well, the transport layer is i2c-hid, but the logical implementation is
> in hid-generic which leverages the hid core default implementation.
>
> In your case, you need to tell hid-lenovo to handle the device so we
> stick to nice and tidy approach with each HID driver handling it's own
> business.
>
> Adding a line like the following will bind the keyboard part of the
> device to hid-lenovo in lenovo_devices[]:
> { HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC,
> USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_YOGA_SLIM_7X) },
> If you don't use hid-multitouch on the same device you need a
> HID_I2C_DEVICE() macro instead.
Thank you for the explanation; that makes sense.
This machine does have multitouch, but it's in a different product id.
However, it did not work: apparently hid-lenovo can't be loaded on this
machine because it depends on platform_profile, which returns
-EOPNOTSUPP at initialization. This is an arm64 machine with
acpi_disabled. Not sure what to do about that.
--
Lauri Tirkkonen | lotheac @ IRCnet
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts - allow reset GPIO to sleep
From: Dmitry Torokhov @ 2025-10-10 4:32 UTC (permalink / raw)
To: Marek Vasut; +Cc: linux-input, Nick Dyer
In-Reply-To: <20251005023335.166483-1-marek.vasut@mailbox.org>
On Sun, Oct 05, 2025 at 04:33:10AM +0200, Marek Vasut wrote:
> The reset GPIO is not toggled in any critical section where it couldn't
> sleep, allow the reset GPIO to sleep. This allows the driver to operate
> reset GPIOs connected to I2C GPIO expanders.
>
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Tagged for stable and applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Randy Dunlap @ 2025-10-10 4:50 UTC (permalink / raw)
To: Thorsten Leemhuis, Jonathan Denose, Jiri Kosina,
Benjamin Tissoires, Dmitry Torokhov, Jonathan Corbet,
Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien
In-Reply-To: <2b377001-7ee8-449c-b107-1c0164fa54f0@leemhuis.info>
Hi,
On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
> On 8/19/25 01:08, Jonathan Denose wrote:
>> From: Angela Czubak <aczubak@google.com>
>>
>> Define a new structure that contains simple haptic device configuration
>> as well as current state.
>> Add functions that recognize auto trigger and manual trigger reports
>> as well as save their addresses.Hi,
>> Verify that the pressure unit is either grams or newtons.
>> Mark the input device as a haptic touchpad if the unit is correct and
>> the reports are found.
>> [...]
>> +config HID_HAPTIC
>> + tristate "Haptic touchpad support"
>> + default n
>> + help
>> + Support for touchpads with force sensors and haptic actuators instead of a
>> + traditional button.
>> + Adds extra parsing and FF device for the hid multitouch driver.
>> + It can be used for Elan 2703 haptic touchpad.
>> +
>> + If unsure, say N.
>> +
>> menu "Special HID drivers"
>
> I suspect this change is related to a build error I ran into today:
>
> MODPOST Module.symvers
> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
>
> The config where this occurred had this:
>
> CONFIG_HID=y
> CONFIG_HID_MULTITOUCH=m
> CONFIG_HID_HAPTIC=m
>
> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
Sure, but that's just covering up the problem.
First, I get this build error:
ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
so I added those to hid-haptic.c.... and I still get that same build error.
So I looked at the hid-haptic.o file, in the .modinfo section,
and saw this:
Disassembly of section .modinfo:
0000000000000000 <__UNIQUE_ID_modinfo569>:
0: 68 69 64 2e 6c push $0x6c2e6469
5: 69 63 65 6e 73 65 3d imul $0x3d65736e,0x65(%rbx),%esp
c: 47 50 rex.RXB push %r8
e: 4c 00 rex.WR add %r13b,0x69(%rax)
which is ASCII " h i d . l i c e n s e = G P L".
so the license string is there.
Maybe something is modpost is having a problem.
Unless someone who has modified modpost recently has any ideas,
this needs a git bisect, I expect.
---
~Randy
^ permalink raw reply
* [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
From: Zhang Lixu @ 2025-10-10 5:52 UTC (permalink / raw)
To: linux-input, srinivas.pandruvada, jikos, benjamin.tissoires
Cc: lixu.zhang, selina.wang
During suspend/resume tests with S2IDLE, some ISH functional failures were
observed because of delay in executing ISH resume handler. Here
schedule_work() is used from resume handler to do actual work.
schedule_work() uses system_wq, which is a per CPU work queue. Although
the queuing is not bound to a CPU, but it prefers local CPU of the caller,
unless prohibited.
Users of this work queue are not supposed to queue long running work.
But in practice, there are scenarios where long running work items are
queued on other unbound workqueues, occupying the CPU. As a result, the
ISH resume handler may not get a chance to execute in a timely manner.
In one scenario, one of the ish_resume_handler() executions was delayed
nearly 1 second because another work item on an unbound workqueue occupied
the same CPU. This delay causes ISH functionality failures.
A similar issue was previously observed where the ISH HID driver timed out
while getting the HID descriptor during S4 resume in the recovery kernel,
likely caused by the same workqueue contention problem.
Create dedicated unbound workqueues for all ISH operations to allow work
items to execute on any available CPU, eliminating CPU-specific bottlenecks
and improving resume reliability under varying system loads. Also ISH has
three different components, a bus driver which implements ISH protocols, a
PCI interface layer and HID interface. Use one dedicated work queue for all
of them.
Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
---
drivers/hid/intel-ish-hid/ipc/ipc.c | 21 +++++++++++++++++++-
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
drivers/hid/intel-ish-hid/ishtp-hid-client.c | 4 ++--
drivers/hid/intel-ish-hid/ishtp/bus.c | 18 ++++++++++++++++-
drivers/hid/intel-ish-hid/ishtp/hbm.c | 4 ++--
drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h | 3 +++
include/linux/intel-ish-client-if.h | 2 ++
7 files changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c
index 3ddaa2cd39d5..9958f2968c4f 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -628,7 +628,7 @@ static void recv_ipc(struct ishtp_device *dev, uint32_t doorbell_val)
if (!ishtp_dev) {
ishtp_dev = dev;
}
- schedule_work(&fw_reset_work);
+ queue_work(dev->unbound_wq, &fw_reset_work);
break;
case MNG_RESET_NOTIFY_ACK:
@@ -933,6 +933,21 @@ static const struct ishtp_hw_ops ish_hw_ops = {
.dma_no_cache_snooping = _dma_no_cache_snooping
};
+static struct workqueue_struct *devm_ishtp_alloc_workqueue(struct device *dev)
+{
+ struct workqueue_struct *wq;
+
+ wq = alloc_workqueue("ishtp_unbound_%d", WQ_UNBOUND, 0, dev->id);
+ if (!wq)
+ return NULL;
+
+ if (devm_add_action_or_reset(dev, (void (*)(void *))destroy_workqueue,
+ wq))
+ return NULL;
+
+ return wq;
+}
+
/**
* ish_dev_init() -Initialize ISH devoce
* @pdev: PCI device
@@ -953,6 +968,10 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev)
if (!dev)
return NULL;
+ dev->unbound_wq = devm_ishtp_alloc_workqueue(&pdev->dev);
+ if (!dev->unbound_wq)
+ return NULL;
+
dev->devc = &pdev->dev;
ishtp_device_init(dev);
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 9d150ce234f2..b748ac6fbfdc 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -384,7 +384,7 @@ static int __maybe_unused ish_resume(struct device *device)
ish_resume_device = device;
dev->resume_flag = 1;
- schedule_work(&resume_work);
+ queue_work(dev->unbound_wq, &resume_work);
return 0;
}
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
index d8c3c54a8c0f..f61add862b6b 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -860,7 +860,7 @@ static int hid_ishtp_cl_reset(struct ishtp_cl_device *cl_device)
hid_ishtp_trace(client_data, "%s hid_ishtp_cl %p\n", __func__,
hid_ishtp_cl);
- schedule_work(&client_data->work);
+ queue_work(ishtp_get_workqueue(cl_device), &client_data->work);
return 0;
}
@@ -902,7 +902,7 @@ static int hid_ishtp_cl_resume(struct device *device)
hid_ishtp_trace(client_data, "%s hid_ishtp_cl %p\n", __func__,
hid_ishtp_cl);
- schedule_work(&client_data->resume_work);
+ queue_work(ishtp_get_workqueue(cl_device), &client_data->resume_work);
return 0;
}
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 93a0432e7058..c6ce37244e49 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -541,7 +541,7 @@ void ishtp_cl_bus_rx_event(struct ishtp_cl_device *device)
return;
if (device->event_cb)
- schedule_work(&device->event_work);
+ queue_work(device->ishtp_dev->unbound_wq, &device->event_work);
}
/**
@@ -876,6 +876,22 @@ struct device *ishtp_get_pci_device(struct ishtp_cl_device *device)
}
EXPORT_SYMBOL(ishtp_get_pci_device);
+/**
+ * ishtp_get_workqueue - Retrieve the workqueue associated with an ISHTP device
+ * @cl_device: Pointer to the ISHTP client device structure
+ *
+ * Returns the workqueue_struct pointer (unbound_wq) associated with the given
+ * ISHTP client device. This workqueue is typically used for scheduling work
+ * related to the device.
+ *
+ * Return: Pointer to struct workqueue_struct.
+ */
+struct workqueue_struct *ishtp_get_workqueue(struct ishtp_cl_device *cl_device)
+{
+ return cl_device->ishtp_dev->unbound_wq;
+}
+EXPORT_SYMBOL(ishtp_get_workqueue);
+
/**
* ishtp_trace_callback() - Return trace callback
* @cl_device: ISH-TP client device instance
diff --git a/drivers/hid/intel-ish-hid/ishtp/hbm.c b/drivers/hid/intel-ish-hid/ishtp/hbm.c
index 8ee5467127d8..97c4fcd9e3c6 100644
--- a/drivers/hid/intel-ish-hid/ishtp/hbm.c
+++ b/drivers/hid/intel-ish-hid/ishtp/hbm.c
@@ -573,7 +573,7 @@ void ishtp_hbm_dispatch(struct ishtp_device *dev,
/* Start firmware loading process if it has loader capability */
if (version_res->host_version_supported & ISHTP_SUPPORT_CAP_LOADER)
- schedule_work(&dev->work_fw_loader);
+ queue_work(dev->unbound_wq, &dev->work_fw_loader);
dev->version.major_version = HBM_MAJOR_VERSION;
dev->version.minor_version = HBM_MINOR_VERSION;
@@ -864,7 +864,7 @@ void recv_hbm(struct ishtp_device *dev, struct ishtp_msg_hdr *ishtp_hdr)
dev->rd_msg_fifo_tail = (dev->rd_msg_fifo_tail + IPC_PAYLOAD_SIZE) %
(RD_INT_FIFO_SIZE * IPC_PAYLOAD_SIZE);
spin_unlock_irqrestore(&dev->rd_msg_spinlock, flags);
- schedule_work(&dev->bh_hbm_work);
+ queue_work(dev->unbound_wq, &dev->bh_hbm_work);
eoi:
return;
}
diff --git a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
index 23db97ecf21c..4b0596eadf1c 100644
--- a/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
+++ b/drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
@@ -175,6 +175,9 @@ struct ishtp_device {
struct hbm_version version;
int transfer_path; /* Choice of transfer path: IPC or DMA */
+ /* Alloc a dedicated unbound workqueue for ishtp device */
+ struct workqueue_struct *unbound_wq;
+
/* work structure for scheduling firmware loading tasks */
struct work_struct work_fw_loader;
/* waitq for waiting for command response from the firmware loader */
diff --git a/include/linux/intel-ish-client-if.h b/include/linux/intel-ish-client-if.h
index dfbf7d9d7bb5..b235fd84f478 100644
--- a/include/linux/intel-ish-client-if.h
+++ b/include/linux/intel-ish-client-if.h
@@ -87,6 +87,8 @@ bool ishtp_wait_resume(struct ishtp_device *dev);
ishtp_print_log ishtp_trace_callback(struct ishtp_cl_device *cl_device);
/* Get device pointer of PCI device for DMA acces */
struct device *ishtp_get_pci_device(struct ishtp_cl_device *cl_device);
+/* Get the ISHTP workqueue */
+struct workqueue_struct *ishtp_get_workqueue(struct ishtp_cl_device *cl_device);
struct ishtp_cl *ishtp_cl_allocate(struct ishtp_cl_device *cl_device);
void ishtp_cl_free(struct ishtp_cl *cl);
base-commit: 0b2f041c47acb45db82b4e847af6e17eb66cd32d
--
2.43.0
^ permalink raw reply related
* RE: [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from level to edge detection
From: Xu, Even @ 2025-10-10 5:54 UTC (permalink / raw)
To: jikos@kernel.org, bentiss@kernel.org,
srinivas.pandruvada@linux.intel.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhang, Rui1
In-Reply-To: <20250919070939.223954-1-even.xu@intel.com>
Hi, Jiri,
This patch was in review list for 3 weeks without any review comments, would you help merge it?
Thanks!
Best Regards,
Even Xu
> -----Original Message-----
> From: Xu, Even <even.xu@intel.com>
> Sent: Friday, September 19, 2025 3:10 PM
> To: jikos@kernel.org; bentiss@kernel.org; srinivas.pandruvada@linux.intel.com
> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; Xu, Even
> <even.xu@intel.com>; Zhang, Rui1 <rui1.zhang@intel.com>
> Subject: [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from level
> to edge detection
>
> The original implementation used level detection for the first interrupt after
> device reset to avoid potential interrupt line noise and missed interrupts during
> the initialization phase. However, this approach introduced unintended side
> effects when tested with certain touch panels,
> including:
> - Delayed hardware interrupt response
> - Multiple spurious interrupt triggers
>
> Switching back to edge detection for the first interrupt resolves these issues while
> maintaining reliable interrupt handling.
>
> Extensive testing across multiple platforms with touch panels from various
> vendors confirms this change introduces no regressions.
>
> Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI protocol
> implementation")
> Tested-by: Rui Zhang <rui1.zhang@intel.com>
> Signed-off-by: Even Xu <even.xu@intel.com>
> ---
> drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> index e6ba2ddcc9cb..16f780bc879b 100644
> --- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> +++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-protocol.c
> @@ -280,8 +280,7 @@ int reset_tic(struct quickspi_device *qsdev)
>
> qsdev->reset_ack = false;
>
> - /* First interrupt uses level trigger to avoid missing interrupt */
> - thc_int_trigger_type_select(qsdev->thc_hw, false);
> + thc_int_trigger_type_select(qsdev->thc_hw, true);
>
> ret = acpi_tic_reset(qsdev);
> if (ret)
> --
> 2.40.1
^ permalink raw reply
* [PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: Dmitry Torokhov @ 2025-10-10 6:12 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: 卢国宏, kenalba, linux-input, linux-kernel
Commit 581c4484769e ("HID: input: map digitizer battery usage") added
handling of battery events for digitizers (typically for batteries
presented in styli). Digitizers typically report correct battery levels
only when stylus is actively touching the surface, and in other cases
they may report battery level of 0. To avoid confusing consumers of the
battery information the code was added to filer out reports with 0
battery levels.
However there exist other kinds of devices that may legitimately report
0 battery levels. Fix this by filtering out 0-level reports only for
digitizer usages, and continue reporting them for other kinds of devices
(Smart Batteries, etc).
Reported-by: 卢国宏 <luguohong@xiaomi.com>
Tested-by: 卢国宏 <luguohong@xiaomi.com>
Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-input.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ff1784b5c2a4..ba3f6655af9e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
dev->battery = NULL;
}
-static void hidinput_update_battery(struct hid_device *dev, int value)
+static void hidinput_update_battery(struct hid_device *dev,
+ unsigned int usage, int value)
{
int capacity;
if (!dev->battery)
return;
- if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+ if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+ return;
+
+ if (value < dev->battery_min || value > dev->battery_max)
return;
capacity = hidinput_scale_battery_capacity(dev, value);
@@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
if (!handled)
- hidinput_update_battery(hid, value);
+ hidinput_update_battery(hid, usage->hid, value);
return;
}
--
2.51.0.740.g6adb054d12-goog
--
Dmitry
^ permalink raw reply related
* Re: 答复: 答复: [External Mail]Re: The zero power level of the HID device in kernel 6.12 is not reported from the kernel to the upper layer.
From: Dmitry Torokhov @ 2025-10-10 6:13 UTC (permalink / raw)
To: 卢国宏
Cc: José Expósito, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, jikos@kernel.org,
bentiss@kernel.org, 李鹏, Fei1 Jiang 蒋飞,
宋密密
In-Reply-To: <80a4f9e6416944d3919c63a392325d3b@xiaomi.com>
Hi,
On Fri, Oct 10, 2025 at 02:25:55AM +0000, 卢国宏 wrote:
> Hi Dmitry,
> Please let us know whether you plan to merge this solution into the kernel or not! Thanks!
I just sent the patch to HID maintainers. You were CCed on it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Thorsten Leemhuis @ 2025-10-10 6:48 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Denose, Jiri Kosina, Benjamin Tissoires,
Dmitry Torokhov, Jonathan Corbet, Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien, Lucas GISSOT
In-Reply-To: <3184c648-661b-4cf4-b7cf-bd44c381611d@infradead.org>
[Top-Posting for easier consumption]
Mainly writing this mail to bring Lucas GISSOT in here, who reported the
same error yesterday here:
https://lore.kernel.org/all/aOgvA8Jiofcnk2xb@ARSENIURE.localdomain/
Lucas there suggested:
"""but it seems to me that the #if IS_ENABLED(CONFIG_HID_HAPTIC) in
hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
Kconfig updated."""
And Randy: Thx for the closer investigation! It explains some of the
"that feels odd, am I holding this wrong" feeling I had when reporting this.
Ciao, Thorsten
On 10/10/25 06:50, Randy Dunlap wrote:
> On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
>> On 8/19/25 01:08, Jonathan Denose wrote:
>>> From: Angela Czubak <aczubak@google.com>
>>>
>>> Define a new structure that contains simple haptic device configuration
>>> as well as current state.
>>> Add functions that recognize auto trigger and manual trigger reports
>>> as well as save their addresses.Hi,
>>> Verify that the pressure unit is either grams or newtons.
>>> Mark the input device as a haptic touchpad if the unit is correct and
>>> the reports are found.
>>> [...]
>>> +config HID_HAPTIC
>>> + tristate "Haptic touchpad support"
>>> + default n
>>> + help
>>> + Support for touchpads with force sensors and haptic actuators instead of a
>>> + traditional button.
>>> + Adds extra parsing and FF device for the hid multitouch driver.
>>> + It can be used for Elan 2703 haptic touchpad.
>>> +
>>> + If unsure, say N.
>>> +
>>> menu "Special HID drivers"
>>
>> I suspect this change is related to a build error I ran into today:
>>
>> MODPOST Module.symvers
>> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
>> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
>>
>> The config where this occurred had this:
>>
>> CONFIG_HID=y
>> CONFIG_HID_MULTITOUCH=m
>> CONFIG_HID_HAPTIC=m
>>
>> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
>
> Sure, but that's just covering up the problem.
>> First, I get this build error:
>
> ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
>
> so I added those to hid-haptic.c.... and I still get that same build error.
>
> So I looked at the hid-haptic.o file, in the .modinfo section,
> and saw this:
>
> Disassembly of section .modinfo:
>
> 0000000000000000 <__UNIQUE_ID_modinfo569>:
> 0: 68 69 64 2e 6c push $0x6c2e6469
> 5: 69 63 65 6e 73 65 3d imul $0x3d65736e,0x65(%rbx),%esp
> c: 47 50 rex.RXB push %r8
> e: 4c 00 rex.WR add %r13b,0x69(%rax)
>
> which is ASCII " h i d . l i c e n s e = G P L".
>
> so the license string is there.
>
> Maybe something is modpost is having a problem.
> Unless someone who has modified modpost recently has any ideas,
> this needs a git bisect, I expect.
^ permalink raw reply
* 答复: [External Mail][PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: 卢国宏 @ 2025-10-10 10:43 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina, Benjamin Tissoires
Cc: kenalba@google.com, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, 李鹏,
宋密密, 卢国宏
In-Reply-To: <of5qjeij72wduee3zyf26drfcwhpsl4sjs3v6tfjv3tgl3xsol@sss7zcyawwaz>
Thanks, Dmitry.
Hi Jiri Kosina, Benjamin Tissoires, please let me know once you've merged this patch into the kernel. Thanks!
________________________________________
发件人: Dmitry Torokhov <dmitry.torokhov@gmail.com>
发送时间: 2025年10月10日 14:12
收件人: Jiri Kosina; Benjamin Tissoires
抄送: 卢国宏; kenalba@google.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
主题: [External Mail][PATCH] HID: hid-input: only ignore 0 battery events for digitizers
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈
Commit 581c4484769e ("HID: input: map digitizer battery usage") added
handling of battery events for digitizers (typically for batteries
presented in styli). Digitizers typically report correct battery levels
only when stylus is actively touching the surface, and in other cases
they may report battery level of 0. To avoid confusing consumers of the
battery information the code was added to filer out reports with 0
battery levels.
However there exist other kinds of devices that may legitimately report
0 battery levels. Fix this by filtering out 0-level reports only for
digitizer usages, and continue reporting them for other kinds of devices
(Smart Batteries, etc).
Reported-by: 卢国宏 <luguohong@xiaomi.com>
Tested-by: 卢国宏 <luguohong@xiaomi.com>
Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-input.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ff1784b5c2a4..ba3f6655af9e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
dev->battery = NULL;
}
-static void hidinput_update_battery(struct hid_device *dev, int value)
+static void hidinput_update_battery(struct hid_device *dev,
+ unsigned int usage, int value)
{
int capacity;
if (!dev->battery)
return;
- if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+ if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+ return;
+
+ if (value < dev->battery_min || value > dev->battery_max)
return;
capacity = hidinput_scale_battery_capacity(dev, value);
@@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
if (!handled)
- hidinput_update_battery(hid, value);
+ hidinput_update_battery(hid, usage->hid, value);
return;
}
--
2.51.0.740.g6adb054d12-goog
--
Dmitry
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
^ permalink raw reply related
* Re: hid_multitouch - random non-responsive, multitouch, scrolling and zooming
From: Steven Haigh @ 2025-10-10 12:21 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Stéphane Chatty, Peter Hutterer, linux-input
In-Reply-To: <8720ac11-2b1d-4b42-84c8-52407dbda7e7@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 7/10/25 20:10, Benjamin Tissoires wrote:
> On Tue, Oct 7, 2025, at 3:42 AM, Steven Haigh wrote:
>> I ran `libinput record -o recording.yml /dev/event/input6` and have
>> attached the compressed output. Annoyingly, it seems like the touchpad
>> is working fine at the moment - so it may confirm the hardware
>> information, but not a recording of the problem right now.
>
> Yeah, same on one of the Dell laptops I have here. I know it has the bug, but whenever I try to reproduce it it never shows meaning I was never able to pin point the issue :(
So, "good" news is that I managed to grab a recording today when the
touchpad started to play up. When using two-fingers to scroll, I ended
up zooming etc.
I tried to make the recording as short as possible, but still include
examples of clicking, scrolling etc.
Attached for reference.
As for which way to approach a fix - I'm happy for you to suggest what
path we take - a BPF, kernel patch backport, or something else.
You tell me which one gives the most value and is likely to help more
people in the long run.
--
Steven Haigh
📧 netwiz@crc.id.au
💻 https://crc.id.au
[-- Attachment #2: recording.yml.xz --]
[-- Type: application/x-xz, Size: 106992 bytes --]
^ permalink raw reply
* Re: [PATCH v2] input: zforce_ts: Remove error print for devm_add_action_or_reset()
From: Waqar Hameed @ 2025-10-10 13:36 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: kernel, linux-input, linux-kernel
In-Reply-To: <pndbjoum7td.a.out@axis.com>
On Tue, Aug 05, 2025 at 11:33 +0200 Waqar Hameed <waqar.hameed@axis.com> wrote:
> When `devm_add_action_or_reset()` fails, it is due to a failed memory
> allocation and will thus return `-ENOMEM`. `dev_err_probe()` doesn't do
> anything when error is `-ENOMEM`. Therefore, remove the useless call to
> `dev_err_probe()` when `devm_add_action_or_reset()` fails, and just
> return the value instead.
Friendly ping incoming!
^ permalink raw reply
* Re: hid_multitouch - random non-responsive, multitouch, scrolling and zooming
From: Benjamin Tissoires @ 2025-10-10 13:54 UTC (permalink / raw)
To: Steven Haigh; +Cc: Stéphane Chatty, Peter Hutterer, linux-input
In-Reply-To: <26b03bc2-b824-4948-9803-5a0b5f08e394@crc.id.au>
On Fri, Oct 10, 2025, at 2:21 PM, Steven Haigh wrote:
> On 7/10/25 20:10, Benjamin Tissoires wrote:
>> On Tue, Oct 7, 2025, at 3:42 AM, Steven Haigh wrote:
>>> I ran `libinput record -o recording.yml /dev/event/input6` and have
>>> attached the compressed output. Annoyingly, it seems like the touchpad
>>> is working fine at the moment - so it may confirm the hardware
>>> information, but not a recording of the problem right now.
>>
>> Yeah, same on one of the Dell laptops I have here. I know it has the bug, but whenever I try to reproduce it it never shows meaning I was never able to pin point the issue :(
>
> So, "good" news is that I managed to grab a recording today when the
> touchpad started to play up. When using two-fingers to scroll, I ended
> up zooming etc.
Unfortunately, this is a recording after the kernel processing, so all I can do is check that we have ghost fingers (and even that is trciky because I'm not sure if what we see are the expected events or not).
>
> I tried to make the recording as short as possible, but still include
> examples of clicking, scrolling etc.
>
> Attached for reference.
>
> As for which way to approach a fix - I'm happy for you to suggest what
> path we take - a BPF, kernel patch backport, or something else.
Great, thanks!
>
> You tell me which one gives the most value and is likely to help more
> people in the long run.
Right now the most valuable would be to test the series at
https://lore.kernel.org/linux-input/20251008-fix-sticky-fingers-v1-0-760f1f26fce3@kernel.org/T/#m0fba507cbd43acd36bef28151ecb90b7077606a4
If this work and you want a quick and dirty fix you can then return to the default kernel, and use the BPF from https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/204, the latest version should be compatible with your device, just re-download and install it again.
But definitely a tested-by on the kernel patch would be appreciated :)
Cheers,
Benjamin
>
> --
> Steven Haigh
>
> 📧 netwiz@crc.id.au
> 💻 https://crc.id.au
> Attachments:
> * recording.yml.xz
^ permalink raw reply
* Re: [PATCH] HID: multitouch: fix name of Stylus input devices
From: Mika Westerberg @ 2025-10-10 14:55 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Jiri Kosina, Benjamin Tissoires, Tero Kristo, linux-input,
linux-kernel, kernel-dev
In-Reply-To: <20251008-hid_multitouch_stylus-v1-1-9f43f7e79195@igalia.com>
Hi,
On Wed, Oct 08, 2025 at 09:40:33AM -0300, Thadeu Lima de Souza Cascardo wrote:
> HID_DG_PEN devices should have a suffix of "Stylus", as pointed out by
> commit c0ee1d571626 ("HID: hid-input: Add suffix also for HID_DG_PEN").
> However, on multitouch devices, these suffixes may be overridden. Before
> that commit, HID_DG_PEN devices would get the "Stylus" suffix, but after
> that, multitouch would override them to have an "UNKNOWN" suffix. Just add
> HID_DG_PEN to the list of non-overriden suffixes in multitouch.
>
> Before this fix:
>
> [ 0.470981] input: ELAN9008:00 04F3:2E14 UNKNOWN as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-16/i2c-ELAN9008:00/0018:04F3:2E14.0001/input/input8
> ELAN9008:00 04F3:2E14 UNKNOWN
>
> After this fix:
>
> [ 0.474332] input: ELAN9008:00 04F3:2E14 Stylus as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-16/i2c-ELAN9008:00/0018:04F3:2E14.0001/input/input8
>
> ELAN9008:00 04F3:2E14 Stylus
>
> Fixes: c0ee1d571626 ("HID: hid-input: Add suffix also for HID_DG_PEN")
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Looks good to me,
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Randy Dunlap @ 2025-10-10 18:55 UTC (permalink / raw)
To: Thorsten Leemhuis, Jonathan Denose, Jiri Kosina,
Benjamin Tissoires, Dmitry Torokhov, Jonathan Corbet,
Henrik Rydberg
Cc: linux-input, linux-kernel, linux-doc, Angela Czubak,
Sean O'Brien, Lucas GISSOT
In-Reply-To: <1cd7fb11-0569-4032-905c-f887f3e0dd4c@leemhuis.info>
Hi,
I think I found it... see below.
On 10/9/25 11:48 PM, Thorsten Leemhuis wrote:
> [Top-Posting for easier consumption]
>
> Mainly writing this mail to bring Lucas GISSOT in here, who reported the
> same error yesterday here:
> https://lore.kernel.org/all/aOgvA8Jiofcnk2xb@ARSENIURE.localdomain/
>
> Lucas there suggested:
> """but it seems to me that the #if IS_ENABLED(CONFIG_HID_HAPTIC) in
> hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
> Kconfig updated."""
>
> And Randy: Thx for the closer investigation! It explains some of the
> "that feels odd, am I holding this wrong" feeling I had when reporting this.
>
> Ciao, Thorsten
>
> On 10/10/25 06:50, Randy Dunlap wrote:
>> On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
>>> On 8/19/25 01:08, Jonathan Denose wrote:
>>>> From: Angela Czubak <aczubak@google.com>
>>>>
>>>> Define a new structure that contains simple haptic device configuration
>>>> as well as current state.
>>>> Add functions that recognize auto trigger and manual trigger reports
>>>> as well as save their addresses.Hi,
>>>> Verify that the pressure unit is either grams or newtons.
>>>> Mark the input device as a haptic touchpad if the unit is correct and
>>>> the reports are found.
>>>> [...]
>>>> +config HID_HAPTIC
>>>> + tristate "Haptic touchpad support"
>>>> + default n
>>>> + help
>>>> + Support for touchpads with force sensors and haptic actuators instead of a
>>>> + traditional button.
>>>> + Adds extra parsing and FF device for the hid multitouch driver.
>>>> + It can be used for Elan 2703 haptic touchpad.
>>>> +
>>>> + If unsure, say N.
>>>> +
>>>> menu "Special HID drivers"
>>>
>>> I suspect this change is related to a build error I ran into today:
>>>
>>> MODPOST Module.symvers
>>> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>>> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
>>> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
>>>
>>> The config where this occurred had this:
>>>
>>> CONFIG_HID=y
>>> CONFIG_HID_MULTITOUCH=m
>>> CONFIG_HID_HAPTIC=m
>>>
>>> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
>>
>> Sure, but that's just covering up the problem.
>>> First, I get this build error:
>>
>> ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
>> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
>>
ISTM that tristate is incompatible with this newly added Makefile
line:
+hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
hid-* lists files that should be builtin, not loadable modules.
These should all be hid-y. AFAIK, hid-m is not useful.
(A maintainer can correct me as needed.)
So adding a MODULE_LICENSE() and MODULE_DESCRIPTION() to
hid-haptic.c and changing drivers/hid/Makefile to use
obj-$(CONFIG_HID_HAPTIC_ += hid-haptic.o
fixes the build errors for me.
Angela, Jonathan D., is there any reason that
hid-haptic needs to be builtin instead of a loadable
module? It's no problem for hid-multitouch.ko to call
into hid-haptic.ko (both as loadable modules) as long as
hid-haptic.ko is loaded first.
Thanks.
~Randy
---
---
drivers/hid/hid-haptic.c | 3 +++
1 file changed, 3 insertions(+)
--- linux.orig/drivers/hid/hid-haptic.c
+++ linux/drivers/hid/hid-haptic.c
@@ -10,6 +10,9 @@
#include "hid-haptic.h"
+MODULE_DESCRIPTION("HID haptic touchpad support");
+MODULE_LICENSE("GPL");
+
void hid_haptic_feature_mapping(struct hid_device *hdev,
struct hid_haptic_device *haptic,
struct hid_field *field, struct hid_usage *usage)
---
drivers/hid/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux.orig/drivers/hid/Makefile
+++ linux/drivers/hid/Makefile
@@ -4,7 +4,8 @@
#
hid-y := hid-core.o hid-input.o hid-quirks.o
hid-$(CONFIG_DEBUG_FS) += hid-debug.o
-hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
+
+obj-$(CONFIG_HID_HAPTIC) += hid-haptic.o
obj-$(CONFIG_HID_BPF) += bpf/
^ permalink raw reply
* Re: [PATCH] Input: pegasus-notetaker - fix out-of-bounds access vulnerability in pegasus_parse_packet() function of the pegasus driver
From: kernel test robot @ 2025-10-10 19:43 UTC (permalink / raw)
To: pip-izony, Dmitry Torokhov
Cc: oe-kbuild-all, Seungjin Bae, Kyungtae Kim, linux-input,
linux-kernel, stable
In-Reply-To: <20251007214131.3737115-2-eeodqql09@gmail.com>
Hi pip-izony,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus linus/master v6.17 next-20251010]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/pip-izony/Input-pegasus-notetaker-fix-out-of-bounds-access-vulnerability-in-pegasus_parse_packet-function-of-the-pegasus-driver/20251009-180618
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20251007214131.3737115-2-eeodqql09%40gmail.com
patch subject: [PATCH] Input: pegasus-notetaker - fix out-of-bounds access vulnerability in pegasus_parse_packet() function of the pegasus driver
config: powerpc64-randconfig-r073-20251010 (https://download.01.org/0day-ci/archive/20251011/202510110303.ibbCe4PD-lkp@intel.com/config)
compiler: powerpc64-linux-gcc (GCC) 8.5.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510110303.ibbCe4PD-lkp@intel.com/
smatch warnings:
drivers/input/tablet/pegasus_notetaker.c:314 pegasus_probe() warn: inconsistent indenting
vim +314 drivers/input/tablet/pegasus_notetaker.c
270
271 static int pegasus_probe(struct usb_interface *intf,
272 const struct usb_device_id *id)
273 {
274 struct usb_device *dev = interface_to_usbdev(intf);
275 struct usb_endpoint_descriptor *endpoint;
276 struct pegasus *pegasus;
277 struct input_dev *input_dev;
278 int error;
279 int pipe;
280
281 /* We control interface 0 */
282 if (intf->cur_altsetting->desc.bInterfaceNumber >= 1)
283 return -ENODEV;
284
285 /* Sanity check that the device has an endpoint */
286 if (intf->cur_altsetting->desc.bNumEndpoints < 1) {
287 dev_err(&intf->dev, "Invalid number of endpoints\n");
288 return -EINVAL;
289 }
290
291 endpoint = &intf->cur_altsetting->endpoint[0].desc;
292
293 pegasus = kzalloc(sizeof(*pegasus), GFP_KERNEL);
294 input_dev = input_allocate_device();
295 if (!pegasus || !input_dev) {
296 error = -ENOMEM;
297 goto err_free_mem;
298 }
299
300 mutex_init(&pegasus->pm_mutex);
301
302 pegasus->usbdev = dev;
303 pegasus->dev = input_dev;
304 pegasus->intf = intf;
305
306 pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
307 /* Sanity check that pipe's type matches endpoint's type */
308 if (usb_pipe_type_check(dev, pipe)) {
309 error = -EINVAL;
310 goto err_free_mem;
311 }
312
313 pegasus->data_len = usb_maxpacket(dev, pipe);
> 314 if (pegasus->data_len < 5) {
315 dev_err(&intf->dev, "Invalid number of wMaxPacketSize\n");
316 error = -EINVAL;
317 goto err_free_mem;
318 }
319
320 pegasus->data = usb_alloc_coherent(dev, pegasus->data_len, GFP_KERNEL,
321 &pegasus->data_dma);
322 if (!pegasus->data) {
323 error = -ENOMEM;
324 goto err_free_mem;
325 }
326
327 pegasus->irq = usb_alloc_urb(0, GFP_KERNEL);
328 if (!pegasus->irq) {
329 error = -ENOMEM;
330 goto err_free_dma;
331 }
332
333 usb_fill_int_urb(pegasus->irq, dev, pipe,
334 pegasus->data, pegasus->data_len,
335 pegasus_irq, pegasus, endpoint->bInterval);
336
337 pegasus->irq->transfer_dma = pegasus->data_dma;
338 pegasus->irq->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
339
340 if (dev->manufacturer)
341 strscpy(pegasus->name, dev->manufacturer,
342 sizeof(pegasus->name));
343
344 if (dev->product) {
345 if (dev->manufacturer)
346 strlcat(pegasus->name, " ", sizeof(pegasus->name));
347 strlcat(pegasus->name, dev->product, sizeof(pegasus->name));
348 }
349
350 if (!strlen(pegasus->name))
351 snprintf(pegasus->name, sizeof(pegasus->name),
352 "USB Pegasus Device %04x:%04x",
353 le16_to_cpu(dev->descriptor.idVendor),
354 le16_to_cpu(dev->descriptor.idProduct));
355
356 usb_make_path(dev, pegasus->phys, sizeof(pegasus->phys));
357 strlcat(pegasus->phys, "/input0", sizeof(pegasus->phys));
358
359 INIT_WORK(&pegasus->init, pegasus_init);
360
361 usb_set_intfdata(intf, pegasus);
362
363 input_dev->name = pegasus->name;
364 input_dev->phys = pegasus->phys;
365 usb_to_input_id(dev, &input_dev->id);
366 input_dev->dev.parent = &intf->dev;
367
368 input_set_drvdata(input_dev, pegasus);
369
370 input_dev->open = pegasus_open;
371 input_dev->close = pegasus_close;
372
373 __set_bit(EV_ABS, input_dev->evbit);
374 __set_bit(EV_KEY, input_dev->evbit);
375
376 __set_bit(ABS_X, input_dev->absbit);
377 __set_bit(ABS_Y, input_dev->absbit);
378
379 __set_bit(BTN_TOUCH, input_dev->keybit);
380 __set_bit(BTN_RIGHT, input_dev->keybit);
381 __set_bit(BTN_TOOL_PEN, input_dev->keybit);
382
383 __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
384 __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
385
386 input_set_abs_params(input_dev, ABS_X, -1500, 1500, 8, 0);
387 input_set_abs_params(input_dev, ABS_Y, 1600, 3000, 8, 0);
388
389 error = input_register_device(pegasus->dev);
390 if (error)
391 goto err_free_urb;
392
393 return 0;
394
395 err_free_urb:
396 usb_free_urb(pegasus->irq);
397 err_free_dma:
398 usb_free_coherent(dev, pegasus->data_len,
399 pegasus->data, pegasus->data_dma);
400 err_free_mem:
401 input_free_device(input_dev);
402 kfree(pegasus);
403 usb_set_intfdata(intf, NULL);
404
405 return error;
406 }
407
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
From: kernel test robot @ 2025-10-10 20:25 UTC (permalink / raw)
To: James Calligeros, Sven Peter, Janne Grunau, Alyssa Rosenzweig,
Neal Gompa, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, Jean Delvare, Guenter Roeck,
Dmitry Torokhov, Jonathan Corbet
Cc: oe-kbuild-all, asahi, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, linux-hwmon, linux-input, linux-doc
In-Reply-To: <20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02@gmail.com>
Hi James,
kernel test robot noticed the following build errors:
[auto build test ERROR on c746c3b5169831d7fb032a1051d8b45592ae8d78]
url: https://github.com/intel-lab-lkp/linux/commits/James-Calligeros/dt-bindings-rtc-Add-Apple-SMC-RTC/20251010-092141
base: c746c3b5169831d7fb032a1051d8b45592ae8d78
patch link: https://lore.kernel.org/r/20251007-macsmc-subdevs-v3-6-d7d3bfd7ae02%40gmail.com
patch subject: [PATCH v3 06/13] hwmon: Add Apple Silicon SMC hwmon driver
config: sparc-allmodconfig (https://download.01.org/0day-ci/archive/20251011/202510110421.ZnJdu1ds-lkp@intel.com/config)
compiler: sparc64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251011/202510110421.ZnJdu1ds-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510110421.ZnJdu1ds-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/hwmon/macsmc-hwmon.c: In function 'macsmc_hwmon_write_f32':
>> drivers/hwmon/macsmc-hwmon.c:246:24: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration]
246 | fval = FIELD_PREP(FLT_SIGN_MASK, neg) |
| ^~~~~~~~~~
vim +/FIELD_PREP +246 drivers/hwmon/macsmc-hwmon.c
225
226 static int macsmc_hwmon_write_f32(struct apple_smc *smc, smc_key key, int value)
227 {
228 u64 val;
229 u32 fval = 0;
230 int exp = 0, neg;
231
232 val = abs(value);
233 neg = val != value;
234
235 if (val) {
236 int msb = __fls(val) - exp;
237
238 if (msb > 23) {
239 val >>= msb - FLT_MANT_BIAS;
240 exp -= msb - FLT_MANT_BIAS;
241 } else if (msb < 23) {
242 val <<= FLT_MANT_BIAS - msb;
243 exp += msb;
244 }
245
> 246 fval = FIELD_PREP(FLT_SIGN_MASK, neg) |
247 FIELD_PREP(FLT_EXP_MASK, exp + FLT_EXP_BIAS) |
248 FIELD_PREP(FLT_MANT_MASK, val);
249 }
250
251 return apple_smc_write_u32(smc, key, fval);
252 }
253
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Jonathan Denose @ 2025-10-10 20:30 UTC (permalink / raw)
To: Randy Dunlap
Cc: Thorsten Leemhuis, Jiri Kosina, Benjamin Tissoires,
Dmitry Torokhov, Jonathan Corbet, Henrik Rydberg, linux-input,
linux-kernel, linux-doc, Angela Czubak, Sean O'Brien,
Lucas GISSOT
In-Reply-To: <f2243a9b-e032-416b-aef8-958198ff3955@infradead.org>
Hi all,
Thanks for looking into this.
On Fri, Oct 10, 2025 at 1:55 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Hi,
>
> I think I found it... see below.
>
>
> On 10/9/25 11:48 PM, Thorsten Leemhuis wrote:
> > [Top-Posting for easier consumption]
> >
> > Mainly writing this mail to bring Lucas GISSOT in here, who reported the
> > same error yesterday here:
> > https://lore.kernel.org/all/aOgvA8Jiofcnk2xb@ARSENIURE.localdomain/
> >
> > Lucas there suggested:
> > """but it seems to me that the #if IS_ENABLED(CONFIG_HID_HAPTIC) in
> > hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
> > Kconfig updated."""
> >
> > And Randy: Thx for the closer investigation! It explains some of the
> > "that feels odd, am I holding this wrong" feeling I had when reporting this.
> >
> > Ciao, Thorsten
> >
> > On 10/10/25 06:50, Randy Dunlap wrote:
> >> On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
> >>> On 8/19/25 01:08, Jonathan Denose wrote:
> >>>> From: Angela Czubak <aczubak@google.com>
> >>>>
> >>>> Define a new structure that contains simple haptic device configuration
> >>>> as well as current state.
> >>>> Add functions that recognize auto trigger and manual trigger reports
> >>>> as well as save their addresses.Hi,
> >>>> Verify that the pressure unit is either grams or newtons.
> >>>> Mark the input device as a haptic touchpad if the unit is correct and
> >>>> the reports are found.
> >>>> [...]
> >>>> +config HID_HAPTIC
> >>>> + tristate "Haptic touchpad support"
> >>>> + default n
> >>>> + help
> >>>> + Support for touchpads with force sensors and haptic actuators instead of a
> >>>> + traditional button.
> >>>> + Adds extra parsing and FF device for the hid multitouch driver.
> >>>> + It can be used for Elan 2703 haptic touchpad.
> >>>> +
> >>>> + If unsure, say N.
> >>>> +
> >>>> menu "Special HID drivers"
> >>>
> >>> I suspect this change is related to a build error I ran into today:
> >>>
> >>> MODPOST Module.symvers
> >>> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> >>> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
> >>> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
> >>>
> >>> The config where this occurred had this:
> >>>
> >>> CONFIG_HID=y
> >>> CONFIG_HID_MULTITOUCH=m
> >>> CONFIG_HID_HAPTIC=m
> >>>
> >>> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
> >>
> >> Sure, but that's just covering up the problem.
> >>> First, I get this build error:
> >>
> >> ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
> >> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
> >>
>
> ISTM that tristate is incompatible with this newly added Makefile
> line:
>
> +hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
>
> hid-* lists files that should be builtin, not loadable modules.
> These should all be hid-y. AFAIK, hid-m is not useful.
> (A maintainer can correct me as needed.)
>
> So adding a MODULE_LICENSE() and MODULE_DESCRIPTION() to
> hid-haptic.c and changing drivers/hid/Makefile to use
> obj-$(CONFIG_HID_HAPTIC_ += hid-haptic.o
>
> fixes the build errors for me.
>
> Angela, Jonathan D., is there any reason that
> hid-haptic needs to be builtin instead of a loadable
> module? It's no problem for hid-multitouch.ko to call
> into hid-haptic.ko (both as loadable modules) as long as
> hid-haptic.ko is loaded first.
>
As long as hid-multitouch.ko is able to call into hid-haptic.ko I
don't see any issues, but is there a way to enforce that when
CONFIG_HID_HAPTIC is enabled, hid-haptic.ko will be loaded before
hid-multitouch.ko?
>
> Thanks.
>
> ~Randy
> ---
> ---
> drivers/hid/hid-haptic.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- linux.orig/drivers/hid/hid-haptic.c
> +++ linux/drivers/hid/hid-haptic.c
> @@ -10,6 +10,9 @@
>
> #include "hid-haptic.h"
>
> +MODULE_DESCRIPTION("HID haptic touchpad support");
> +MODULE_LICENSE("GPL");
> +
> void hid_haptic_feature_mapping(struct hid_device *hdev,
> struct hid_haptic_device *haptic,
> struct hid_field *field, struct hid_usage *usage)
> ---
> drivers/hid/Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux.orig/drivers/hid/Makefile
> +++ linux/drivers/hid/Makefile
> @@ -4,7 +4,8 @@
> #
> hid-y := hid-core.o hid-input.o hid-quirks.o
> hid-$(CONFIG_DEBUG_FS) += hid-debug.o
> -hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
> +
> +obj-$(CONFIG_HID_HAPTIC) += hid-haptic.o
>
> obj-$(CONFIG_HID_BPF) += bpf/
>
>
--
Jonathan
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Lucas GISSOT @ 2025-10-10 21:09 UTC (permalink / raw)
To: Jonathan Denose
Cc: Randy Dunlap, Thorsten Leemhuis, Jiri Kosina, Benjamin Tissoires,
Dmitry Torokhov, Jonathan Corbet, Henrik Rydberg, linux-input,
linux-kernel, linux-doc, Angela Czubak, Sean O'Brien
In-Reply-To: <CAMCVhVOm5xzN6pkX5cKMSHrMqvdCD_14+XuunAuJLENgLO1NqA@mail.gmail.com>
Hi,
I applied Randy's patch and built with CONFIG_HID_MULTITOUCH=m and
CONFIG_HID_HAPTIC=m, it builts; but there is an ld error on hid_haptic_*
functions as soon as CONFIG_HID_MULTITOUCH is changed to yes.
Is this .config not something desired, and then HID_HAPTIC should not be
a tristate (if I understood correctly), or is there another problem?
Thanks,
Lucas
On Fri, Oct 10, 2025 at 03:30:05PM -0500, Jonathan Denose wrote:
> Hi all,
>
> Thanks for looking into this.
>
> On Fri, Oct 10, 2025 at 1:55 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> >
> > Hi,
> >
> > I think I found it... see below.
> >
> >
> > On 10/9/25 11:48 PM, Thorsten Leemhuis wrote:
> > > [Top-Posting for easier consumption]
> > >
> > > Mainly writing this mail to bring Lucas GISSOT in here, who reported the
> > > same error yesterday here:
> > > https://lore.kernel.org/all/aOgvA8Jiofcnk2xb@ARSENIURE.localdomain/
> > >
> > > Lucas there suggested:
> > > """but it seems to me that the #if IS_ENABLED(CONFIG_HID_HAPTIC) in
> > > hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
> > > Kconfig updated."""
> > >
> > > And Randy: Thx for the closer investigation! It explains some of the
> > > "that feels odd, am I holding this wrong" feeling I had when reporting this.
> > >
> > > Ciao, Thorsten
> > >
> > > On 10/10/25 06:50, Randy Dunlap wrote:
> > >> On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
> > >>> On 8/19/25 01:08, Jonathan Denose wrote:
> > >>>> From: Angela Czubak <aczubak@google.com>
> > >>>>
> > >>>> Define a new structure that contains simple haptic device configuration
> > >>>> as well as current state.
> > >>>> Add functions that recognize auto trigger and manual trigger reports
> > >>>> as well as save their addresses.Hi,
> > >>>> Verify that the pressure unit is either grams or newtons.
> > >>>> Mark the input device as a haptic touchpad if the unit is correct and
> > >>>> the reports are found.
> > >>>> [...]
> > >>>> +config HID_HAPTIC
> > >>>> + tristate "Haptic touchpad support"
> > >>>> + default n
> > >>>> + help
> > >>>> + Support for touchpads with force sensors and haptic actuators instead of a
> > >>>> + traditional button.
> > >>>> + Adds extra parsing and FF device for the hid multitouch driver.
> > >>>> + It can be used for Elan 2703 haptic touchpad.
> > >>>> +
> > >>>> + If unsure, say N.
> > >>>> +
> > >>>> menu "Special HID drivers"
> > >>>
> > >>> I suspect this change is related to a build error I ran into today:
> > >>>
> > >>> MODPOST Module.symvers
> > >>> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
> > >>> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
> > >>>
> > >>> The config where this occurred had this:
> > >>>
> > >>> CONFIG_HID=y
> > >>> CONFIG_HID_MULTITOUCH=m
> > >>> CONFIG_HID_HAPTIC=m
> > >>>
> > >>> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
> > >>
> > >> Sure, but that's just covering up the problem.
> > >>> First, I get this build error:
> > >>
> > >> ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
> > >> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
> > >>
> >
> > ISTM that tristate is incompatible with this newly added Makefile
> > line:
> >
> > +hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
> >
> > hid-* lists files that should be builtin, not loadable modules.
> > These should all be hid-y. AFAIK, hid-m is not useful.
> > (A maintainer can correct me as needed.)
> >
> > So adding a MODULE_LICENSE() and MODULE_DESCRIPTION() to
> > hid-haptic.c and changing drivers/hid/Makefile to use
> > obj-$(CONFIG_HID_HAPTIC_ += hid-haptic.o
> >
> > fixes the build errors for me.
> >
> > Angela, Jonathan D., is there any reason that
> > hid-haptic needs to be builtin instead of a loadable
> > module? It's no problem for hid-multitouch.ko to call
> > into hid-haptic.ko (both as loadable modules) as long as
> > hid-haptic.ko is loaded first.
> >
> As long as hid-multitouch.ko is able to call into hid-haptic.ko I
> don't see any issues, but is there a way to enforce that when
> CONFIG_HID_HAPTIC is enabled, hid-haptic.ko will be loaded before
> hid-multitouch.ko?
> >
> > Thanks.
> >
> > ~Randy
> > ---
> > ---
> > drivers/hid/hid-haptic.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > --- linux.orig/drivers/hid/hid-haptic.c
> > +++ linux/drivers/hid/hid-haptic.c
> > @@ -10,6 +10,9 @@
> >
> > #include "hid-haptic.h"
> >
> > +MODULE_DESCRIPTION("HID haptic touchpad support");
> > +MODULE_LICENSE("GPL");
> > +
> > void hid_haptic_feature_mapping(struct hid_device *hdev,
> > struct hid_haptic_device *haptic,
> > struct hid_field *field, struct hid_usage *usage)
> > ---
> > drivers/hid/Makefile | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- linux.orig/drivers/hid/Makefile
> > +++ linux/drivers/hid/Makefile
> > @@ -4,7 +4,8 @@
> > #
> > hid-y := hid-core.o hid-input.o hid-quirks.o
> > hid-$(CONFIG_DEBUG_FS) += hid-debug.o
> > -hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
> > +
> > +obj-$(CONFIG_HID_HAPTIC) += hid-haptic.o
> >
> > obj-$(CONFIG_HID_BPF) += bpf/
> >
> >
> --
> Jonathan
^ permalink raw reply
* Re: [PATCH v3 04/11] HID: haptic: introduce hid_haptic_device
From: Randy Dunlap @ 2025-10-10 22:51 UTC (permalink / raw)
To: Jonathan Denose
Cc: Thorsten Leemhuis, Jiri Kosina, Benjamin Tissoires,
Dmitry Torokhov, Jonathan Corbet, Henrik Rydberg, linux-input,
linux-kernel, linux-doc, Angela Czubak, Sean O'Brien,
Lucas GISSOT
In-Reply-To: <CAMCVhVOm5xzN6pkX5cKMSHrMqvdCD_14+XuunAuJLENgLO1NqA@mail.gmail.com>
On 10/10/25 1:30 PM, Jonathan Denose wrote:
> Hi all,
>
> Thanks for looking into this.
>
> On Fri, Oct 10, 2025 at 1:55 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> Hi,
>>
>> I think I found it... see below.
>>
>>
>> On 10/9/25 11:48 PM, Thorsten Leemhuis wrote:
>>> [Top-Posting for easier consumption]
>>>
>>> Mainly writing this mail to bring Lucas GISSOT in here, who reported the
>>> same error yesterday here:
>>> https://lore.kernel.org/all/aOgvA8Jiofcnk2xb@ARSENIURE.localdomain/
>>>
>>> Lucas there suggested:
>>> """but it seems to me that the #if IS_ENABLED(CONFIG_HID_HAPTIC) in
>>> hid-haptic.h should be replaced by IS_BUILTIN(CONFIG_HID_HAPTIC) and
>>> Kconfig updated."""
>>>
>>> And Randy: Thx for the closer investigation! It explains some of the
>>> "that feels odd, am I holding this wrong" feeling I had when reporting this.
>>>
>>> Ciao, Thorsten
>>>
>>> On 10/10/25 06:50, Randy Dunlap wrote:
>>>> On 10/9/25 7:43 AM, Thorsten Leemhuis wrote:
>>>>> On 8/19/25 01:08, Jonathan Denose wrote:
>>>>>> From: Angela Czubak <aczubak@google.com>
>>>>>>
>>>>>> Define a new structure that contains simple haptic device configuration
>>>>>> as well as current state.
>>>>>> Add functions that recognize auto trigger and manual trigger reports
>>>>>> as well as save their addresses.Hi,
>>>>>> Verify that the pressure unit is either grams or newtons.
>>>>>> Mark the input device as a haptic touchpad if the unit is correct and
>>>>>> the reports are found.
>>>>>> [...]
>>>>>> +config HID_HAPTIC
>>>>>> + tristate "Haptic touchpad support"
>>>>>> + default n
>>>>>> + help
>>>>>> + Support for touchpads with force sensors and haptic actuators instead of a
>>>>>> + traditional button.
>>>>>> + Adds extra parsing and FF device for the hid multitouch driver.
>>>>>> + It can be used for Elan 2703 haptic touchpad.
>>>>>> +
>>>>>> + If unsure, say N.
>>>>>> +
>>>>>> menu "Special HID drivers"
>>>>>
>>>>> I suspect this change is related to a build error I ran into today:
>>>>>
>>>>> MODPOST Module.symvers
>>>>> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
>>>>> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
>>>>>
>>>>> The config where this occurred had this:
>>>>>
>>>>> CONFIG_HID=y
>>>>> CONFIG_HID_MULTITOUCH=m
>>>>> CONFIG_HID_HAPTIC=m
>>>>>
>>>>> Changing the latter to "CONFIG_HID_HAPTIC=y" fixed the problem for me.
>>>>
>>>> Sure, but that's just covering up the problem.
>>>>> First, I get this build error:
>>>>
>>>> ERROR: modpost: missing MODULE_LICENSE() in drivers/hid/hid-haptic.o
>>>> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-haptic.o
>>>>
>>
>> ISTM that tristate is incompatible with this newly added Makefile
>> line:
>>
>> +hid-$(CONFIG_HID_HAPTIC) += hid-haptic.o
>>
>> hid-* lists files that should be builtin, not loadable modules.
>> These should all be hid-y. AFAIK, hid-m is not useful.
>> (A maintainer can correct me as needed.)
More correctly, any .o that is listed as being built as part of
hid.o should is going to be controlled by CONFIG_HID and should
not its own have a Kconfig symbol at all.
E.g. here:
hid-y := hid-core.o hid-input.o hid-quirks.o
hid-core, hid-input, and hid-quirks don't have their own
Kconfig symbols.
>> So adding a MODULE_LICENSE() and MODULE_DESCRIPTION() to
>> hid-haptic.c and changing drivers/hid/Makefile to use
>> obj-$(CONFIG_HID_HAPTIC_ += hid-haptic.o
>>
>> fixes the build errors for me.
>>
>> Angela, Jonathan D., is there any reason that
>> hid-haptic needs to be builtin instead of a loadable
>> module? It's no problem for hid-multitouch.ko to call
>> into hid-haptic.ko (both as loadable modules) as long as
>> hid-haptic.ko is loaded first.
>>
> As long as hid-multitouch.ko is able to call into hid-haptic.ko I
> don't see any issues, but is there a way to enforce that when
> CONFIG_HID_HAPTIC is enabled, hid-haptic.ko will be loaded before
> hid-multitouch.ko?
I only know of two possibilities though there may be more.
a. use request_module(true, "hid-haptic");
This would probably be used in the hid core somewhere, afterthe device matching is done.
b. use udev. When a device that needs hid-multitouch is
discovered, have udev load both hid-haptic and hid-multitouch.
I see that hid-haptic.h is written so that it has stubs for
when CONFIG_HID_HAPTIC is not enabled. Can hid-multitouch
operate (in a reduced capacity) when HID_HAPTIC is not enabled?
So that they are separate modules and hid-multitouch is not
dependent on hid-haptic?
There is probably a use case for hid-multitouch without having
hid-haptic loaded since hid-multitouch existed without having
hid-haptic around at all.
It seems that you want both of them loaded. And then Lucas
has reported a build error when HID_HAPTIC=m and
HID_MULTITOUCH=y, so either (like Lucas said) HID_HAPTIC
should be bool, not tristate; or in Kconfig,
HID_MULTITOUCH should depend on HID_HAPTIC, which would not
allow the problem config that Lucas reported.
But that forces devices that want HID_MULTITOUCH to also
have HID_HAPTIC loaded, even though they may not need it.
--
~Randy
^ permalink raw reply
* Re: hid_multitouch - random non-responsive, multitouch, scrolling and zooming
From: Steven Haigh @ 2025-10-10 23:30 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Stéphane Chatty, Peter Hutterer, linux-input
In-Reply-To: <ed69f310-8a4d-4023-b1ce-72b78e512177@app.fastmail.com>
On 11/10/25 00:54, Benjamin Tissoires wrote:
> On Fri, Oct 10, 2025, at 2:21 PM, Steven Haigh wrote:
>> On 7/10/25 20:10, Benjamin Tissoires wrote:
>>> On Tue, Oct 7, 2025, at 3:42 AM, Steven Haigh wrote:
>>>> I ran `libinput record -o recording.yml /dev/event/input6` and have
>>>> attached the compressed output. Annoyingly, it seems like the touchpad
>>>> is working fine at the moment - so it may confirm the hardware
>>>> information, but not a recording of the problem right now.
>>>
>>> Yeah, same on one of the Dell laptops I have here. I know it has the bug, but whenever I try to reproduce it it never shows meaning I was never able to pin point the issue :(
>>
>> So, "good" news is that I managed to grab a recording today when the
>> touchpad started to play up. When using two-fingers to scroll, I ended
>> up zooming etc.
>
> Unfortunately, this is a recording after the kernel processing, so all I can do is check that we have ghost fingers (and even that is trciky because I'm not sure if what we see are the expected events or not).
Ah, of course - that makes sense. For some reason, I had it in my head
that it'd record the touchpad data directly - but that's a libinput
tool. Seems obvious now, but I get you can't figure out the fake touches
vs me mashing the touchpad :)
>>
>> I tried to make the recording as short as possible, but still include
>> examples of clicking, scrolling etc.
>>
>> Attached for reference.
>>
>> As for which way to approach a fix - I'm happy for you to suggest what
>> path we take - a BPF, kernel patch backport, or something else.
>
> Great, thanks!
>
>>
>> You tell me which one gives the most value and is likely to help more
>> people in the long run.
>
> Right now the most valuable would be to test the series at
> https://lore.kernel.org/linux-input/20251008-fix-sticky-fingers-v1-0-760f1f26fce3@kernel.org/T/#m0fba507cbd43acd36bef28151ecb90b7077606a4
>
> If this work and you want a quick and dirty fix you can then return to the default kernel, and use the BPF from https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/204, the latest version should be compatible with your device, just re-download and install it again.
>
> But definitely a tested-by on the kernel patch would be appreciated :)
Ok, I'll take a peek at this. Just for my own workloads sake, I've
installed the BPF hack first - just to make sure that it fixes the
issue. I did have a thought that potentially its a hardware issue - but
hopefully this issue is just the driver.
I'll give it a run for a little while to see if I get any of the same
problems - and if not, try to figure out how to build a kernel with this
patch.
To run a like for like comparison, I guess I'd want to take the Fedora
SRPM, add the patch, rebuild that, and then run it to test. It's been a
*long* time since I've done kernel builds :)
I know this isn't conducive to a quick test turnaround - but I'd rather
give you correct feedback than quick feedback.
--
Steven Haigh
📧 netwiz@crc.id.au
💻 https://crc.id.au
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox