Bug 206259 - HID ELAN9038 probe fails with "report is too long"
Summary: HID ELAN9038 probe fails with "report is too long"
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: drivers_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-19 14:53 UTC by js
Modified: 2020-03-20 01:48 UTC (History)
6 users (show)

See Also:
Kernel Version: 5.6
Tree: Mainline
Regression: Yes


Attachments
patch hid-core.c to fix ELAN digitizer HID bug (694 bytes, patch)
2020-01-19 16:35 UTC, js
Details | Diff

Description js 2020-01-19 14:53:24 UTC
ELAN i2c digitizer on microsoft surface go fails to initialize and device is non-functional

initialization fails on 4.19.96:
----
[    5.507245] hid-generic 0018:04F3:261A.0005: report is too long
[    5.507256] hid-generic 0018:04F3:261A.0005: item 0 1 0 8 parsing failed
[    5.507290] hid-generic: probe of 0018:04F3:261A.0005 failed with error -22
[    5.556409] hid-multitouch 0018:04F3:261A.0005: report is too long
[    5.581641] hid-multitouch 0018:04F3:261A.0005: item 0 1 0 8 parsing failed
[    5.618495] hid-multitouch: probe of 0018:04F3:261A.0005 failed with error -22

initialization succeeds on 4.19.95:
----
[    7.150887] hid-generic 0018:04F3:261A.0001: input,hidraw2: I2C HID v1.00 Device [ELAN9038:00 04F3:261A] on i2c-ELAN9038:00
[    8.253077] input: ELAN9038:00 04F3:261A as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-ELAN9038:00/0018:04F3:261A.0001/input/input20
[    8.253219] input: ELAN9038:00 04F3:261A Pen as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-ELAN9038:00/0018:04F3:261A.0001/input/input23
[    8.253330] hid-multitouch 0018:04F3:261A.0001: input,hidraw0: I2C HID v1.00 Device [ELAN9038:00 04F3:261A] on i2c-ELAN9038:00

problem seems to be due to this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=31d06cc8e7caec36bedeb4f90444920431462f61
Comment 1 js 2020-01-19 16:35:50 UTC
Created attachment 286897 [details]
patch hid-core.c to fix ELAN digitizer HID bug
Comment 2 js 2020-01-19 16:38:20 UTC
attached patch fixes the bug
Comment 3 js 2020-01-19 16:52:02 UTC
NOTE: this bug applies to 5.4 line as well
Comment 4 Jan Zabel 2020-01-27 20:07:22 UTC
Hi, is there any chance of the patch coming into mainline kernel? 5.5 does not seem to have it.
Comment 5 js 2020-01-28 00:01:09 UTC
(In reply to Jan Zabel from comment #4)
> Hi, is there any chance of the patch coming into mainline kernel? 5.5 does
> not seem to have it.

if you compile your own kernels, the patch should work against 5.5 as it's in a block of code that hasn't changed for at least a year.

if you want it committed to the mainline, i suggest you add your voice to my patch request here:
https://www.spinics.net/lists/linux-input/msg65385.html

you can contact the maintainers via the linux-input mailing list:
linux-input [at] vger.kernel.org
Comment 6 Milan Votava 2020-01-28 11:04:14 UTC
I have the same problem on my Asus ZenBook Pro Duo and Asus ZenBook Duo (touchsreens not detected in latest Fedora 31 5.4 kernels)
Comment 7 Michael B. 2020-01-29 19:49:13 UTC
Got the same Problem on my Surface Go with Kernel 5.4.15
Comment 8 Johan Korsnes 2020-02-04 11:08:19 UTC
I've previously submitted a patch to increase HID buffer size[0], and a related off-by-one memset[1]. I mention the latter as it should make it evident why your suggested patch js would need careful review before being accepted. I'm not sure if or when these patches will get accepted, but usb-linux maintainer Jiri Kosina seemed positive.[2]

Hopefully this increase in buffer size is adequate for your device as well.

[0] https://lore.kernel.org/linux-usb/20200117120836.2354966-2-jkorsnes@cisco.com/
[1] https://lore.kernel.org/linux-usb/20200117120836.2354966-1-jkorsnes@cisco.com/
[2] https://lore.kernel.org/linux-usb/nycvar.YFH.7.76.2001171115230.31058@cbobk.fhfr.pm/
Comment 9 js 2020-02-04 12:54:16 UTC
This is kind of funny - I wrote a similar patch to [2] a few days ago and didn't submit it because I was too busy to write out the logic of the fix. I got around to it today:
https://lore.kernel.org/linux-input/CAKsRvPOyPqxLaUx+gemCARq+gVeOO94iqyVMWspUEKXk==_wZg@mail.gmail.com/

(In reply to Johan Korsnes from comment #8)
> I've previously submitted a patch to increase HID buffer size[0], and a
> related off-by-one memset[1]. I mention the latter as it should make it
> evident why your suggested patch js would need careful review before being
> accepted. I'm not sure if or when these patches will get accepted, but
> usb-linux maintainer Jiri Kosina seemed positive.[2]
Comment 10 Rylan 2020-02-12 23:13:53 UTC
Hello, I also have a system that is affected by this issue (Surface Go). The ELAN touchscreen wouldn't work, and I'd see this in dmesg when booting:

---- Linux version 5.6.0-rc1
[1.128929] hid-multitouch 0018:04F3:261A.0001: report is too long
[1.130546] hid-multitouch 0018:04F3:261A.0001: item 0 1 0 8 parsing failed
[1.132153] hid-multitouch: probe of 0018:04F3:261A.0001 failed with error -22
----

I tried the patches in [0] and [1] independently of each other, and can confirm that both of these fix the issue.

[0] https://lore.kernel.org/linux-usb/20200117120836.2354966-2-jkorsnes@cisco.com/
[1] https://www.spinics.net/lists/linux-input/msg65385.html
Comment 11 Johan Korsnes 2020-02-13 06:40:18 UTC
(In reply to Rylan from comment #10)
> Hello, I also have a system that is affected by this issue (Surface Go). The
> ELAN touchscreen wouldn't work, and I'd see this in dmesg when booting:
>
[...]

Relevant commits (5ebdffd25098, 84a406263246) have been applied to hid-next tree[0]. Hopefully these solves your issue.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-next
Comment 13 Josip Medved 2020-03-19 01:00:51 UTC
Will this be also merged into 5.3? I can confirm described issue is present starting 5.3.0-42 (not in 5.3.0-40 though).
Comment 14 Johan Korsnes 2020-03-19 12:21:39 UTC
(In reply to Josip Medved from comment #13)
> Will this be also merged into 5.3? I can confirm described issue is present
> starting 5.3.0-42 (not in 5.3.0-40 though).

I would not expect them to be; I have not received any emails from Greg Kroah-Hartman or Sasha Levin about backporting to 5.3.
Comment 15 js 2020-03-19 20:46:59 UTC
(In reply to Josip Medved from comment #13)
> Will this be also merged into 5.3? I can confirm described issue is present
> starting 5.3.0-42 (not in 5.3.0-40 though).

Truthfully, the maintainers of this subtree consider breaking our hardware not so much a bug as a security "feature" and were extremely rude and dismissive toward me when I explained the issue to them and provided a fix.

The patch attached to this bug report will completely resolve the issue on any and every affected kernel because it is a narrow correction of the bad commit.

You can download the patch from the "Attachments" section, apply it to your kernel, rebuild, replace, and reboot. The hardware will then work correctly.

If you need a step-by-step procedure for doing so, post to this bug and I will write a quick guide to doing so.
Comment 16 Josip Medved 2020-03-20 01:48:46 UTC
(in reply o js from comment #15)
> You can download the patch from the "Attachments" section, apply it to your >
> kernel, rebuild, replace, and reboot. The hardware will then work correctly.

Thank you for fix. Greatly appreciated!

Note You need to log in before you can comment on or make changes to this bug.