Could you file a feedback report after you see this issue?  (alt + shift + i)  That will have some logs which can hopefully help us determine the problem!

Hi,

We have experienced this issue with high frequency across our fleet of 300+ of the Dell 3120s in our school district. Several of us have filed feedback reports in the last two months. I am not sure how to direct you to those, but they'll all have Google accounts ending in @angletonisd.net.  

Feedback reports:
http://feedback/#/Report/54097588349
http://feedback/#/Report/53851880264
http://feedback/#/Report/53383334690
http://feedback/#/Report/53382406205


From the logs (similar lines in all reports):
[    0.907223] elants_i2c 2-0010: invalid 'hello' packet: ff ff ff ff
[    0.957470] input: Elan Touchpad as /devices/platform/80860F41:00/i2c-0/0-0015/input/input6
[    0.959024] elan_i2c 0-0015: invalid report id data (ff)
[    0.997590] elants_i2c 2-0010: invalid 'hello' packet: ff ff ff ff

2017-02-15T15:35:05.148825-06:00 ERR kernel: [  709.184883] elants_i2c 2-0010: elants_i2c_send failed (77 77 77 77): -121
2017-02-15T15:35:05.148827-06:00 ERR kernel: [  709.184892] elants_i2c 2-0010: software reset failed: -121

These reports are all hwid 2a44, which is the BOE touchscreen panel.

We still can't repro in-house on any of our Candy devices.  Steven is going to help us track down one from Dell or from the field.


Upon further investigation, the vast majority of reports are on Candy 2a44, but that's probably just a reflection of the device pool.  I found at least one report on 2b37 which mentions suspend/resume and is probably this same issue: http://feedback/#/Report/56256891832

Some reports have both the packet error and a GPIO error:
2017-04-18T09:10:12.413439-04:00 DEBUG kernel: [    0.928631] elants_i2c i2c-ELAN0001:00: GPIO lookup for consumer reset
2017-04-18T09:10:12.413441-04:00 DEBUG kernel: [    0.928638] elants_i2c i2c-ELAN0001:00: using ACPI for GPIO lookup
2017-04-18T09:10:12.413448-04:00 DEBUG kernel: [    0.928644] acpi ELAN0001:00: GPIO: looking up reset-gpios
2017-04-18T09:10:12.413451-04:00 DEBUG kernel: [    0.928650] acpi ELAN0001:00: GPIO: looking up reset-gpio
2017-04-18T09:10:12.413453-04:00 DEBUG kernel: [    0.928655] acpi ELAN0001:00: GPIO: looking up 0 in _CRS
2017-04-18T09:10:12.413455-04:00 DEBUG kernel: [    0.928717] elants_i2c i2c-ELAN0001:00: using lookup tables for GPIO lookup
2017-04-18T09:10:12.413457-04:00 DEBUG kernel: [    0.928724] elants_i2c i2c-ELAN0001:00: lookup for GPIO reset failed

Here's a report from M56 (on Candy).  I've not seen any that mention suspend/resume before M56, so whatever this is probably happened around then.
http://feedback/#/Report/53741587024


There are a few more reports which have this same packet error on other devices.  But it's mostly Candy, and so far it's only Candy that specifically mentions the wake from sleep part of the repro.

Cave:
http://feedback/#/Report/58153535896

Cyan:
http://feedback/#/Report/58018667959
http://feedback/#/Report/57975738971

Wizpig:
http://feedback/#/Report/57937220757
http://feedback/#/Report/57837662090

I am not sure if they had been previously reported or not, but I got my hands on two machines that reliably exhibit the issue and just did two feedback reports in the last 15 minutes.   I also have another Candy device that has never exhibited the issue.  Please let me know if there's any additional info I can provide.  Over the next three days, I'll have regular access to one machine that reliably exhibits the issue, and one that reliably does not.  

Re #8:
http://feedback/#/Report/58249408867
http://feedback/#/Report/58249344476

I started seeing this when we upgraded our district devices to 57.  Also some of our beta testers have been complaining about this for a couple months but we were unable to resolve the issue.  Since going to 57 we have seen a large number of devices affected by this.  I have a device with me that I can reproduce this behavior on every time.  It is on version 59.  I also filed a feedback report  

partner bug: see b/37617526

Update from google on this issue:

We are currently reviewing firmware in relation to this issue. There is no ETA at this time, but work is in progress.

To everyone who can repro this bug:

We've landed a short-term fix in M57 stable.  You should see an update to version 9202.64.2.  Go to chrome://help and check for updates if you want to speed up the process.

We have an affected device from a user and the touchscreen now works after sleep.  The touchscreen vendor is working on a more permanent solution.  If this build doesn't solve your Candy touchscreen issues, please reply here!

Can you give us more info on the V9202.64.2? 

i have more than 1000 with version V9202.64.2 same issue no touchscreen 

Latest Chrome version release for Chrome devices is V60. Which 1000+ devices are you installing V9202?

I can confirm that this issue is still occurring on a Dell Chromebook 11 (3189) with latest version V9460.60.0.  The touchscreen works after a reboot, but as soon as the system goes into sleep mode, the touchscreen will fail to respond after waking up.  This has been reported on several of our 100+ Chromebooks.

@kathrelkeld - can you please retriage this for us ?

Ping. We are starting to see more occurrences of this issue among large school districts in Texas. What do we need to further triage?

The fix for the related Sabin (Kefka) problem mentioned in #20 landed in 9460.66.0.  We verified it in house for all the different touch panels on those two devices.

None of the feedback reports I see are for any build newer than that.  The solution is to update to M60 or to not have your build pinned to M59- by your admin.