Bug 206259

Created attachment 286897 [details]
patch hid-core.c to fix ELAN digitizer HID bug

attached patch fixes the bug

NOTE: this bug applies to 5.4 line as well

Hi, is there any chance of the patch coming into mainline kernel? 5.5 does not seem to have it.

(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

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)

Got the same Problem on my Surface Go with Kernel 5.4.15

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/

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]

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

(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

Resolved in commits:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-next&id=5ebdffd25098898aff1249ae2f7dbfddd76d8f8f
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-next&id=84a4062632462c4320704fcdf8e99e89e94c0aba

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

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

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

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