More info from selvamuthukumar.senthilvelan@elotouch.com:

The Atmel USB touch controller has 2 dedicated interrupt interfaces to report touch data, one to report mouse events and other to report multitouch digitizer events. At any point in time, depending on the controller mode(mouse or digitizer), only one interface is active and reporting events. The other interface is visible to the OS but dormant.

All OSes(Windows/Ubuntu Linux 16.04.4 LTS/ Chrome v60) seem to treat these 2 interfaces/channels as separate input devices and configure them to report input events in parallel. Hence, we do not have issues, as long as one channel is active.

In Ubuntu, the kernel logs, evtest and xinput commands all show both these channels being configured properly. Evtest reports mouse events or digitizer events from respective device ID, depending on which channel is active. Xinput command shows 2 entries for Atmel both linking into the Linux virtual core pointer device.

In Chrome v65, the Linux kernel v3.8.11 underlying Chrome does configure both channels, but it does not seem to propagate upwards to the userspace layers. Evtest on Chrome also shows both the channels being configured properly. Evtest reports mouse events or digitizer events from respective device ID, depending on which channel is active.

However, Chrome v65 seems to configure only the first arriving channel at the userspace, leading to our touch issues. Touch issues occur when the dormant channel is the first channel and Chrome v65 picks that up and ignores the active channel. 

Chrome v65 needs to recognize and configure both channels at the Linux kernel layer and upper userspace layers to get the multiple interface Atmel chip fully functional.

More info from selvamuthukumar.senthilvelan@elotouch.com:

In Chrome v65, I opened up a Chrome shell and monitored the touch events using the evtest command. The Atmel USB controller reported 2 entries under evtest list of input devices, one for mouse and other for digitizer(even though the labels said digitizer for both).    

When the Atmel USB controller is in mouse mode, the mouse entry/interface was actively sending mouse events(BTN_LEFT, ABS_X and ABS_Y), while the digitizer entry/interface was dormant.      
 
When the controller is in multitouch digitizer mode, the digitizer entry/interface was actively sending single and multi touch digitizer events (ABS_X,  ABS_Y, ABS_MT_POSITION_X, ABS_MT_POSITION_Y, etc ), while the mouse entry/interface was dormant. 
 
In Chrome v65, the mouse interface seems to always get configured earlier during OS bootup and gets the first event device number(/dev/input/event3) and the digitizer interface follows with /dev/input/event4. However, if you unplug and replug the USB cable after OS bootup, the digitizer interface always gets configured first as /dev/input/event3, followed by the mouse interface as /dev/input/event4. 
 
Chrome v65 only picks up the first event device and works with it. Due to the switching of these event devices for the 2 interfaces on boot or USB replug, it leads to inconsistent touch operation on Chrome v65. 

If the Atmel controller is in mouse mode, it results in touch at startup and loss of touch after USB replug. If the controller is in digitizer mode, it results in no touch at startup and recovery of touch after USB replug. 

Cursor/pointer is calibrated to the touch and not an issue in both mouse or digitizer modes, when we have touch functioning. We have only one video monitor connected to the Chromebox.
 

Current theory is that is caused by changes for the new calibration feature which assumes (vendor, product, name) is a unique tuple for every device - see  bug 827452 

It's notable that in this example, the order devices are configured matters. It is a very important property that configuration have the same outcome regardless of which order devices are connected to the system. The order devices connect at boot or resume from suspend is pretty much random, so if we don't have that property, the input device configuration may actually change every time you boot, or even every time you close and open the lid.

IIRC for touchscreens we used to only depend on order in ambiguous cases, such as two displays attached to a chromebox that need to be correctly paired with two indistinguishable touchscreen devices. At one point I argued that we should simply not fail automatic configuration in these ambiguous cases, which would have eliminated all of the order dependence. I lost that argument though and we ended up with a few cases where the touchscreen configuration is unpredictable.

Manual touchscreen calibration is supposed to solve the ambiguous cases. So hopefully we can fix all of them and make touchscreen configuration completely independent of device connection order.

Thanks to @agha.ahsan I got a test device (ELO150) to work with.

I tried reproducing this issue with an eve and cave. However I am not sure how to toggle between the two modes, mouse and digitizer. 

So I tested it with the default mode.

Steps:
1) I connected ELO150 to device. (Just the USB cable for touch)
2) Tested the touch input. Events were propagated to the UI as expected.
3) I unplugged-plugged the touch cable for ELO150and tested the touch input. All WAI.
4) I now connected the HDMI cable along with the USB cable for ELO150.
5) Re-performed steps 2 & 3. - Everything was WAI.
6) Connected an external display to the device.
7) Repeated steps 2 & 3. - Everything WAI.
8) Disconnected the HDMI for ELO150. - Repeated steps 2 & 3. All WAI.
9) Closed the lid for the device so its in docked mode.
10) Repeated steps 2 & 3. - WAI
11) Reconnected the HDMI cable for ELO150. Repeated steps 2 & 3. - WAI
12) Restarted the system. Repeated steps 2 & 3. - WAI

So far everything was working as intended. Are there any specific steps I should follow to repro this issue?

This is Chia-Lun from Elo.

You tested it with Chrome v65, right? Is it a Chromebook or Chromebox? The one with issues is a ChromeBox.

Do you know which mode Elo150 is in (mouse or digitizer)? You can either check the touch events (single mouse or multi-touch digitizer) or use two finger to zoom in/out.

If it is in digitizer mode, shut down the Chromebox and power up with Elo150 connected. There will be no touch. Unplugging and plugging in the USB cable will restore the touch.

If it is in mouse mode, it is the other way around.

Could you try it again? Thanks.

I performed the test on a chromebook at M-67 currently in beta.
I just repeated the tests on M65 chromebox and the results were the same. Sharing the video.

Deleted: Elo Touch Demo.mp4 13.9 MB

	Elo Touch Demo.mp4 13.9 MB View Download

The device was always in digitizer mode since I could use two finger zoom in/out at all times. (At boot and after re-plug)

Thanks for your testing. Attached is the HP CromeBox with this issue. Do you happen to have the same one? Or do you want us to send you this HP CromeBox? Thanks.

Deleted: IMG_4929.JPG 2.0 MB

	IMG_4929.JPG 2.0 MB View Download

I did not use this specific HP chrome box. I will post updates once I test the device on this.

The required fix has landed. However the changes will be in stable from M67.

@spang - Do you think we should merge the change to M66 branch?

I don't so, as it's possible we've broken something else and we need time for these changes to get tested.

Next time, rather than trying to fix forward, we should revert (and then merge the revert..) and then reland in a way that does not regress.