Created attachment 289747 [details] log when touchscreen detected but touchpad not This device has both touchscreen (GXTP7386) and touchpad (HTIX5288). The touchscreen gets detected as input most of the time (it still fails sometimes), but touchpad is like 1 out of 100 attempt. I failed to save dmesg output when both works, but attached is related dmesg content when touchscreen is registered as input while touchpad isn't. Tested workarounds: * /etc/modprobe.d/psmouse.conf -> options psmouse proto=imps * kernel parameter i8042.reset, i8042.nomux, i8042.nopnp, i8042.noloop More dmesg when both undetected or both detected incoming, but I have to have enough luck by doing multiple reboots.
Created attachment 289749 [details] log when both touchscreen and touchpad are undetected seems that the cause is `hid_descr_cmd failed` and no retry is issued
Created attachment 289751 [details] log when I try to hot reload i2c-hid Even if the touchscreen wasn't registered on boot, it might be registered after reloading this module. Touchpad still left undetected, though.
Keep reloading i2c-hid, eventually touchpad will be detected and registered :)
New info: the touchpad can be recognized on boot if I do some actions (swipe, slide, whatever) on it while boot is in progress. It looks like the touchpad driver needs some kind of "trigger" to wake up.
(In reply to Mario Ray Mahardhika from comment #4) > New info: the touchpad can be recognized on boot if I do some actions > (swipe, slide, whatever) on it while boot is in progress. It looks like the > touchpad driver needs some kind of "trigger" to wake up. Indeed it seems to help but I've found out that it works 100% reliably on 4.19 (debian kernel package 4.19.0-9) with no special procedure. Newer kernels, such as 5.6 (debian 5.6.0-2) and 5.7 (debian 5.7.0-1) are much more hit and miss.
> Indeed it seems to help but I've found out that it works 100% reliably on > 4.19 > (debian kernel package 4.19.0-9) with no special procedure. Now that's new. I'll try to find one for KDE Neon.
OK, confirmed. It works without me needing to touch the touchpad on boot. As a downside, the touchscreen is now the one that's inconsistent. Anyway, I'm good enough with this workaround. At least two LTS kernels work fine.
One thing which stand out in the log with the non working touchpad is all these messages: [ 6.563388] hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 Can you attach a dmesg log of a boot (with e.g. the 4.19 kernel) where the touchpad does work? Also can you do, as root, the following for both a working and non-working boot: cat /sys/kernel/debug/hid/0018:0911:5288.000?/rdesc > touchpad-rdesc-working resp. cat /sys/kernel/debug/hid/0018:0911:5288.000?/rdesc > touchpad-rdesc-non-working And attach the 2 generated files here?
Created attachment 290273 [details] dmesg 4.19 working kernel 4.19, dmesg output of a working boot
Created attachment 290275 [details] rdesc 4.19 working kernel 4.19, rdesc file for a working boot
Created attachment 290277 [details] dmesg 5.7 notworking kernel 5.7, dmesg output of a nonworking boot
Created attachment 290279 [details] rdesc 5.7 notworking kernel 5.7, rdesc file for a non working boot
Created attachment 290281 [details] dmesg 5.7 working kernel 5.7, dmesg output of a working boot yes, once in a while booting 5.7 will work at the first try.
Created attachment 290283 [details] dmesg 5.7 repeated reloads kernel 5.7, dmesg output of a nonworking boot followed by repated unload & reload of i2c_hid which, as already noted, will eventually produce a working touchpad
I have the same problem, and not only this problem; adittionally to Inconsistent touchpad & touchscreen detection in BMAX Y13, when ubuntu launches a new kernel and it is installed, when restarting the laptop, the laptop does not start, it stays on the ubuntu loading screen and you have to shut it down forcefully and restart it to boot.
Thank you for the logs and sorry for being a bit slow to respond. As I suspected for some reason we are not reading the HID report decriptors properly on the failed probes. They are all 0 except for the 3th byte which reads as 8. Can you try the following "patch": --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -713,6 +713,8 @@ static int i2c_hid_parse(struct hid_device *hid) if (ret) return ret; + msleep(200); + use_override = i2c_hid_get_dmi_hid_report_desc_override(client->name, &rsize); And what about this "patch" : ? diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 294c84e136d7..50125d34de0f 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -704,15 +704,6 @@ static int i2c_hid_parse(struct hid_device *hid) return -EINVAL; } - do { - ret = i2c_hid_hwreset(client); - if (ret) - msleep(1000); - } while (tries-- > 0 && ret); - - if (ret) - return ret; - use_override = i2c_hid_get_dmi_hid_report_desc_override(client->name, &rsize);
How do I apply the patch? I don't understand programming. Thanks.
@Hans: would you like me to test them separately one at a time or also together? May I use my current debian kernel (5.7.0-1) as base or should I pick another specific version from mainline or stable? @Javier: I could share my builds: they're for Debian but you should be able to use them on Ubuntu as well; they won't have Ubuntu-specific patches, that's all.
(In reply to Andrea Borgia from comment #18) > @Hans: would you like me to test them separately one at a time or also > together? Separately please. > May I use my current debian kernel (5.7.0-1) as base or should I pick > another specific version from mainline or stable? 5.7.0 as base should be fine.
@Javier and whoever else is interested: here you'll find the two builds of the current 5.7 from debian/testing with each one of those patches alternatively: https://drive.google.com/drive/folders/1ApnGTMFleWKe_cFSF4RKRVGrOhPAxkGU?usp=sharing (the folder will be removed once testing is completed!)
Created attachment 290611 [details] dmesg / rdesc of two proposed patches @Hans: I took the libery of naming the patches for my convenience, as follows: n.1: "sleep" n.2: "noret" (dmesg and rdesc outputs named accordingly) Even if with the default debian 5.7.0 I had no issues so far with the wifi, I noted the status in my test because at least once it failed. I bring it up in case rfkill is conncted to i2c, no idea. Test were run as in the sequence below: 1 - hid sleep a. reboot from previous debian 5.7.0: touchpad ok b. reboot from windows: touchpad ok, wifi ok c. coldboot: 1st: touchpad ok, wifi dead with "probe failed" (tried rmmod / modprobe, did not help) 2nd: second attempt: touchpad still ok, wifi worked fine d. suspend / resume: touchpad still ok, wifi recovered (rmmod / modprobe worked) 2. hid noret a. not tested b. reboot from windows: touchpad ok, wifi ok c. coldboot: 1st: both touchpad and wifi 2nd: also both good d. suspend / resume: touchpad, wifi both still ok
@Andrea, so if I read your testing results correct, then they can be summarized as either patch (does not matter which one) resolves the issue, is that correct ?
@Hans: correct, though I have a slight preference for the second given that the first one had issues with wifi. If you know for a fact that it cannot possibly be related, then sure they're equivalent to me.
I think the first fix (keep the reset of the i2c-hid device, add a sleep between reset and fetching descriptors) is a more appropriate fix for upstream. And I doubt that there is a relation ship between the wifi sometimes not working on a coldboot and the i2c-hid stuff. I'm pretty sure that if you try a cold-boot a couple of more times with the no-reset (noret) kernel you will eventually also see the wifi issue, assuming that this is an intermittent issue and that it was not a glitch. If the wifi issue was a one-time glitch, then you should not be able to reproduce it with the "sleep" kernel either. If you could double-check that the wifi issue is indeed an intermittent issue, that would be great. After that can you try lowering the sleep to 100 ms ? And if that works to 50 ms ? 200 ms is a bit long, so if possible I would like to make it a bit shorter. Note if 100 ms does not work, you do NOT have to try 150ms we want to have some margin on the safe side, so then we will just go with 200ms.
p.s. thank you for all the testing!
@Hans : why, thank YOU for the coding! Testing is the least I can do, since I have the hw. I'll report back once I have completed the builds and the tests, might be a few days. @Javier: let me know if you want to test the changes, too. Otherwise, I'll skip uploading the images, because it takes ages with my crappy DSL.
Sorry for being late to the test party. I cannot install either kernels, dpkg complains with: dpkg: regarding linux-image-5.7.0-1-amd64-unsigned_5.7.6-1a~test_amd64.deb containing linux-image-5.7.0-1-amd64-unsigned: linux-image-5.7.0-1-amd64-unsigned breaks wireless-regdb (<< 2019.06.03-1~) wireless-regdb (version 2018.05.09-0ubuntu1~18.04.1) is present and installed.
@Mario sorry, if you're not comfortable dealing with package dependencies perhaps it's best to learn about that first; I'd rather not break your machine with wrong or incomplete suggestions. @Hans these are the results of 10 attempts for each kernel, back to back in the same sequence as shown below: 1. with "hid-sleep" (200ms) after many hours of poweroff, I managed to recreate the issue and also fix it just as before, by hibernating, then removing and reloading the iwlwifi module. After that, I once had an issue with the touchscreen but that was all, the wifi worked fine as did the touchpad, of course. 2. with "hid-noret", all attempts ok. Definitely more than a couple more times :) 3. with "100ms", all attempts ok. 4. with "50ms", all attempts ok. I guess it works, then.
Andrea thank you for all the testing. So if I understand things correctly then with 200ms sleep you can sometimes (seldomly) re-create the wifi problem. And with a sleep of 50 ms all is fine, but the touchpad and the wifi. So if I submit a patch upstream to insert a 50 ms sleep then everything will work ok on your laptop, correct? If you can confirm that, then I'll go and submit a patch for this upstream. I would like to give you credit by adding the following line to the patch's commit message: Reported-and-tested-by: Andrea Borgia <email-address@associated-with-your-bugzilla.account> Is that ok with you ?
@Hans Yes, with respect to the wifi I suspect there might be an issue when it's powered down long enough but at this point I'd say we'll deal with it separately if and when I can get a handle on it. In the meantime, please proceed as you suggested and the credit is much appreciated, thanks.
To be fair, I tested the fix but I did not report it :)
So while writing the commit message for the patch I wrote this: ### HID: i2c-hid: Add a msleep(50) between resetting the device and getting the HID report descriptor On the BMAX Y13 laptop the touchpad HID descriptors will read as all zeros unless we put a small delay between the reset and the command to read the HID descriptors. The descriptor being all zeros leads to the following message being logged repeatedly: hid-generic 0018:0911:5288.0002: unknown main item tag 0x0 And a non working touchpad. At this point we do already have a vid:pid from the I2C-HID descriptor, so we could make this a quirk. However there have been multiple reports of i2c touchpads on other (very low budget Apollo / Gemini Lake) laptops, e.g. the Jumper EZBook 3 series, intermittently not working with similar symptoms. The msleep() should be harmless on systems which do not need it, combined with the other reports of similar problems it seems best to just always do the msleep() before reading the descriptors. ### And then to make sure that my memory about the Jumper EZBook 3 series was correct I did a duckduckgo search for touchpad issues on that model which found me: https://forum.manjaro.org/t/ezbook-3-pro-touchpad-problem/38173/17 Which has a link to: https://patchwork.kernel.org/patch/10046575/ Yes, that is a patch I wrote. Note that the vid:pid that patch applies to is the same as the one from the troublesome touchpad on the BMAX Y13. An that patch replaces waiting for the touchpad to signal reset-complete with an IRQ with a msleep(), because at least on my T-Bao T-book Air the touchpad never sends an IRQ on reset. Which means that there already is a msleep on the BMAX Y13, the one which I added years ago, and the problem is that the msleep which I added is too short for the touchpad on the BMAX Y13...
Created attachment 290727 [details] [PATCH] HID: i2c-hid: Increase I2C_HID_QUIRK_NO_IRQ_AFTER_RESET msleep duration TL;DR: I believe the proper way to fix this is to increase the msleep() which is already done for the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk. So here is a new patch for you to test (sorry). Once I have confirmation that this new patch fixes things, I'll submit it upstream right away.
(In reply to Hans de Goede from comment #32) > https://patchwork.kernel.org/patch/10046575/ > Yes, that is a patch I wrote. Yep, it was that patch which led me to you in the first place :) (In reply to Hans de Goede from comment #33) > So here is a new patch for you to test (sorry). Building...
1st test: dead touchpad, rdesc all zeroes and lots of "unknown main item tag 0x0" in dmesg. This time the hibernate / rmmod / modprobe trick does not work, at least not as reliably as before: I needed 4 tries to get it working. 2nd test: even worse, I needed 33 unload / reload cycles to get the touchpad back online. 3rd (and last) test: this time, only 3 tries after resuming from hibernation. I know it is weird but a single 200ms sleep seems to be doing worse than a 100ms one followed by a shorter 50ms one. Now that is interesing.
Ok, so the difference between the 1 large sleep and the 2 sleeps is this: One large sleep: 1. Send reset cmd 2. msleep(200) 3. Send power on cmd 4. Try to read HID descriptor Two sleeps: 1. Send reset cmd 2. msleep(100) 3. Send power on cmd 4. msleep(50) 5. Try to read HID descriptor So clearly we need a delay after the power-on cmd. And if you look at a larger part of the init sequence of the unpatches i2c-hid core, then it looks like this: 1. Send power on cmd 2. usleep_range(1000, 5000) 3. Send reset cmd 4. msleep(100) 5. Send power on cmd 6. Try to read HID descriptor Notice there already is a (short) sleep after the first power on cmd. Since sometimes the descriptors do already get read successfully, that short sleep might be enough, and maybe it is necessary to do such a short sleep after every power-on? At least this analysis explains why 2 sleeps work better then 1 large sleep. So, once again sorry for asking for yet more testing, but as you can hopefully understand I want to get the fix for this right, so I'm going to spin one more patch for testing. I'll attach it here when it is done.
Created attachment 290755 [details] [PATCH] HID: i2c-hid: Always sleep 1ms after I2C_HID_PWR_ON commands Note if this does not work, please try increasing the usleep_range from: usleep_range(1000, 5000); to: usleep_range(5000, 10000);
(In reply to Hans de Goede from comment #36) > At least this analysis explains why 2 sleeps work better then 1 large sleep. Understood, thanks. > So, once again sorry for asking for yet more testing, but as you can > hopefully understand I want to get the fix for this right, so I'm going to > spin one more patch for testing. I'll attach it here when it is done. I do, so stop saying sorry: I'm really glad somebody is working on it! I'm building the first version right now, will update when the results are in.
All right, 10 attempts later I'd say this one works for me, without increasing the range. Touchpad always worked, touchscreen and wifi too. Looks good.
(In reply to Andrea Borgia from comment #38) > I do, so stop saying sorry: I'm really glad somebody is working on it! Ok, I hear you. (In reply to Andrea Borgia from comment #39) > All right, 10 attempts later I'd say this one works for me, without > increasing the range. Touchpad always worked, touchscreen and wifi too. > Looks good. Great, thank you. I will submit the patch upstream right away then.
Super, thanks.
Looks like the patch made its way into 5.8 at least, so I guess we might close this report.
(In reply to Andrea Borgia from comment #42) > Looks like the patch made its way into 5.8 at least, so I guess we might > close this report. Thank you, closing.
Hey guys just want to say that this is still an issue in both Fedora 36 and Ubuntu 22 tried both distros today and installed them multiple times. It seems to be random weather touch pad and touch screen work or not. I did have both track pad and touch screen working in Fedora 36 but then silly me wanted to test Ubuntu. Ubuntu then suddenly had the gyro detected (not detected in fedora) and kept flipping the screen upside down. Reinstalled Fedora and neither would work. Reinstalled Ubuntu again and the upsidedown issue resolved itself but the touch screen would no longer work and neither does the touch pad. I found something interesting tho, if I reboot Ubuntu while constantly doing circle motions on the track pad until I get to the login screen then it the trackpad will suddenly work and remain afterwards. If I reboot Ubuntu while tapping the screen and using the trackpad the inverted screen comes back and the trackpad doesn't work. It seems the only way to get everything working is to boot into windows, verify everything works and then reinstall fedora and only then also you need blind luck. But anyways, Ive seen a to of comments on different forums about reloading i2c_hid until things are detected but nobody says how to do that. How does one reload i2c_hid?