Just tested this with 3.17-rc2, still no results. However I did notice the following message in kern.log:

atmel_mxt_ts 8-004a: Direct firmware load for maxtouch.cfg failed with error -2
input: Atmel maXTouch Touchscreen as /devices/pci0000:00/0000:00:15.2/i2c-8/8-004a/input/input14

Correction:
After a while it starts to work by itself, scolling, select works, however tap doesn't.

However kern.log starts to fill up with the following message:
atmel_mxt_ts 8-004a: Interrupt triggered but zero messages

Hi. It would be useful to have the following:
 * full dmesg log from probe
 * device configuration (which can be obtained by building mxt-app and running mxt-app -d i2c-dev:8-004a --save device.xcfg

mxt-app can be build with these instructions:
https://github.com/atmel-maxtouch/obp-utils/blob/master/README.md#compiling-from-source

Nick,

I need to correct:
the touschcreen doesn't start by itself, it starts after I suspend and resume. And then seems to be working normally, except from the error messages in syslog.

When I tried to rmmod atmel_mxt_ts (before the suspend/resume) the terminal hangs (I can't even kill it) and I need to use the power button to force reset.

I thought I try this because I remember reading somewhere (archlinux?) they removed 2 modules then inserted them in opposite order to get it working. But can't find that now.

What do you mean 'from probe'? Something like dmesg | grep atmel_mxt_ts? That gives:
[    5.966020] atmel_mxt_ts 8-004a: Direct firmware load for maxtouch.cfg failed with error -2
[    5.966026] atmel_mxt_ts 8-004a: Falling back to user helper
[    6.066395] atmel_mxt_ts 8-004a: Family: 162 Variant: 0 Firmware V2.0.AB Objects: 33
[   55.864028] Modules linked in: ctr ccm ip6t_REJECT nf_log_ipv6 xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_comment nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp dm_crypt joydev xt_addrtype cyapa atmel_mxt_ts nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ip6table_filter snd_hda_intel snd_hda_controller ip6_tables snd_hda_codec snd_hwdep nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp snd_pcm nf_conntrack snd_seq_midi iptable_filter snd_seq_midi_event ip_tables x_tables snd_rawmidi arc4 ath9k ath9k_common intel_rapl x86_pkg_temp_thermal intel_powerclamp uvcvideo snd_seq videobuf2_vmalloc ath9k_hw coretemp chromeos_laptop videobuf2_memops ath kvm_intel videobuf2_core v4l2_common snd_seq_device mac80211 videodev media kvm snd_timer crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd serio_raw cfg80211 lpc_ich snd i2c_designware_pci dw_dmac_pci soundcore tpm_infineon dw_dmac 8250_dw dw_dmac_core i2c_designware_platform i2c_designware_core spi_pxa2xx_platform mac_hid parport_pc ppdev lp parport ahci i915 libahci video i2c_algo_bit sdhci_acpi drm_kms_helper sdhci drm [last unloaded: bluetooth]
[   71.072936] atmel_mxt_ts 8-004a: Interrupt triggered but zero messages
< snipped 1605 repeated lines>

BTW I'm on rc3 now. Firmware error changed from rc2, now falls back to another method.

I'll try to find a bit of time to build the mxt-app.

PS I hope it is clear the C720P has the maxTouch touchscreen. The touch pad is the Cypress APA trackpad.

mxt-app gives me:

ferry@chromium:~/build/mxt-app$ obp-utils/mxt-app -d i2c-dev:8-004a --save device.xcfg
Version:1.17-5-g722b
Registered i2c-dev adapter:8 address:0x4a
Could not open /dev/i2c-8, error No such file or directory (2)
Failed to read ID information

You will need to rebuild your kernel with CONFIG_I2C_DEBUG enabled to get the /dev/i2c-8 i2c debug interface.

It looks to me as though the communications configuration settings on the maXTouch device, which define how it uses the interrupt line, aren't quite right. This is normally fixed by settings the T18 COMMSCONFIG byte 1 in the device config to 0x44. You would do this by running:

mxt-app -d [device] -W -T18 44

(once you have mxt-app working, of course)

If the device is set to use edge-triggered interrupts, the effect is sometimes that the edge is missed at suspend/resume/probe.

You will need to backup the configuration once it is set, see the mxt-app manual.

Was this device working previously? What kernel tree/driver was in use? I need to know whether we have caused a regression.

The device is working fine with stock ubuntu kernel:
uname -a
Linux chromium 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:45:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

with the following mod:

I have run the scripts from here https://github.com/visionect/c720p that pulls and build the driver modules from google with some patches from kernel.org. Done that by using:

wget https://raw.githubusercontent.com/visionect/c720p/master/files/ubuntu-1404_3.13-c720p-modules.sh 
sudo chmod +x ubuntu-1404_3.13-c720p-modules.sh 
sudo ./ubuntu-1404_3.13-c720p-modules.sh 

This current bug report is about testing using the Canonical pre-built kernel 3.17 see #1, without building any drivers myself.

Like I said in #4: with 3.17rc[1-3] initially touchscreen is not working until *after* suspend/resume. Then it works normally. At that point it starts spitting errors in syslog, but keeps on working.

I have not tested any kernel 3.14 - 3.16 so can't say if anything regressed there.
3.13 has no in tree support for this touch screen, so that won't count as a regression either.

Compared to the google driver there is imho obviously an initialization regression, however I have no idea if the current driver is based on googles code.

I am keeping my fingers crossed that we can get touchscreen working with 3.17 so let me know what I can do. However building a whole kernel on the poor little Chromebook with 16GB free diskspace might not be real option.
Sadly mxt-app does not work on either the patched 3.13 nor the 3.17-rc.

Well, what do you know. In 3.17-rc4 the touchscreen is initialized properly and works. Also it remains functional after suspend/resume (tried once).

Now, the only problems remaining:
it falls back to the helper for firmware download (whatever that means)
it still floods  dmesg with:

atmel_mxt_ts 8-004a: Interrupt triggered but zero messages

note this is a correction from above comments, all those are from dmesg.

syslog (as does kern.log) just shows:
Sep  9 17:42:02 chromium kernel: [37198.340050] atmel 8-004a: enable touch device
Sep  9 17:42:02 chromium kernel: [37198.340051] atmel 8-004a: skipping lid pm change in suspend
Sep  9 17:42:02 chromium kernel: [37199.127931] atmel_mxt_ts 8-004a: Status: 10 Config Checksum: c652a4
Sep  9 17:42:02 chromium kernel: [37199.130494] atmel_mxt_ts 8-004a: Status: 00 Config Checksum: c652a4

That's good news that it's working better!

I have looked through the driver that you linked to which is from
https://googledrive.com/host/0BxMvXgjEztvAbEdYM1o0ck5rOVE

It's possible that something about the handling of the T7 power configuration or the T9 enable/disable was causing your issue. If it re-occurs, can you send the output of cat /sys/bus/i2c/drivers/atmel_mxt_ts/8-004a/object which should allow me to identify the config problem.

I have sent a patch to Dmitry to reduce the repeated "Interrupt triggered but zero messages" dmesg output. It shouldn't affect operation but it does lead to some extra i2c transfers. I will work on a proper fix for a later version.

Additionally, the error messages appear in bursts, not a continous stream. First I thought it to be related to touching the screen, but right now it is quiet whatever I do. Very strange. The present -rc4 code can't be completely wrong. Unfortunately I don't know how to trigger T7 or T9 related events though.

For future reference, the output of -rc4 cat /sys/bus/i2c/drivers/atmel_mxt_ts/8-004a/object is (note the last line seems to missing data, this is not a copy/paste error on my part):

T6:
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)

T38:
        [ 0]: 02 (2)
        [ 1]: 01 (1)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 00 (0)
        [10]: 00 (0)
        [11]: 00 (0)
        [12]: 00 (0)
        [13]: 00 (0)
        [14]: 00 (0)
        [15]: 00 (0)
        [16]: 00 (0)
        [17]: 00 (0)
        [18]: 00 (0)
        [19]: 00 (0)
        [20]: 00 (0)
        [21]: 00 (0)
        [22]: 00 (0)
        [23]: 00 (0)
        [24]: 00 (0)
        [25]: 00 (0)
        [26]: 00 (0)
        [27]: 00 (0)
        [28]: 00 (0)
        [29]: 00 (0)
        [30]: 00 (0)
        [31]: 00 (0)
        [32]: 00 (0)
        [33]: 00 (0)
        [34]: 00 (0)
        [35]: 00 (0)
        [36]: 00 (0)
        [37]: 00 (0)
        [38]: 00 (0)
        [39]: 00 (0)
        [40]: 00 (0)
        [41]: 00 (0)
        [42]: 00 (0)
        [43]: 00 (0)
        [44]: 00 (0)
        [45]: 00 (0)
        [46]: 00 (0)
        [47]: 00 (0)
        [48]: 00 (0)
        [49]: 00 (0)
        [50]: 00 (0)
        [51]: 00 (0)
        [52]: 00 (0)
        [53]: 00 (0)
        [54]: 00 (0)
        [55]: 00 (0)
        [56]: 00 (0)
        [57]: 00 (0)
        [58]: 00 (0)
        [59]: 00 (0)
        [60]: 00 (0)
        [61]: 00 (0)
        [62]: 00 (0)
        [63]: 00 (0)

T7:
        [ 0]: 1e (30)
        [ 1]: ff (255)
        [ 2]: dc (220)
        [ 3]: 40 (64)

T8:
        [ 0]: 74 (116)
        [ 1]: 00 (0)
        [ 2]: 14 (20)
        [ 3]: 14 (20)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: ff (255)
        [ 7]: 01 (1)
        [ 8]: 1e (30)
        [ 9]: 00 (0)

T9:
Instance 0
        [ 0]: 8f (143)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 20 (32)
        [ 4]: 34 (52)
        [ 5]: 00 (0)
        [ 6]: 5f (95)
        [ 7]: 28 (40)
        [ 8]: 02 (2)
        [ 9]: 03 (3)
        [10]: 19 (25)
        [11]: 01 (1)
        [12]: 01 (1)
        [13]: 40 (64)
        [14]: 0a (10)
        [15]: 14 (20)
        [16]: 14 (20)
        [17]: 05 (5)
        [18]: ff (255)
        [19]: 02 (2)
        [20]: 55 (85)
        [21]: 05 (5)
        [22]: 08 (8)
        [23]: 09 (9)
        [24]: 07 (7)
        [25]: 05 (5)
        [26]: 8e (142)
        [27]: 1d (29)
        [28]: 88 (136)
        [29]: 11 (17)
        [30]: 19 (25)
        [31]: 0f (15)
        [32]: 31 (49)
        [33]: 32 (50)
        [34]: 00 (0)
        [35]: 00 (0)
        [36]: 45 (69)
        [37]: e6 (230)
        [38]: 28 (40)
        [39]: 00 (0)
        [40]: 00 (0)
        [41]: 00 (0)
        [42]: 00 (0)
        [43]: 00 (0)
        [44]: 00 (0)
        [45]: 00 (0)
        [46]: 00 (0)

Instance 1
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 05 (5)
        [10]: 00 (0)
        [11]: 00 (0)
        [12]: 00 (0)
        [13]: 00 (0)
        [14]: 00 (0)
        [15]: 00 (0)
        [16]: 00 (0)
        [17]: 00 (0)
        [18]: 00 (0)
        [19]: 00 (0)
        [20]: 00 (0)
        [21]: 00 (0)
        [22]: 00 (0)
        [23]: 00 (0)
        [24]: 00 (0)
        [25]: 00 (0)
        [26]: 00 (0)
        [27]: 00 (0)
        [28]: 00 (0)
        [29]: 00 (0)
        [30]: 00 (0)
        [31]: 00 (0)
        [32]: 00 (0)
        [33]: 00 (0)
        [34]: 00 (0)
        [35]: 00 (0)
        [36]: 00 (0)
        [37]: 00 (0)
        [38]: 00 (0)
        [39]: 00 (0)
        [40]: 00 (0)
        [41]: 00 (0)
        [42]: 00 (0)
        [43]: 00 (0)
        [44]: 00 (0)
        [45]: 00 (0)
        [46]: 00 (0)

T15:
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 00 (0)
        [10]: 00 (0)

T18:
        [ 0]: 40 (64)
        [ 1]: 00 (0)

T19:
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)

T24:
Instance 0
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 00 (0)
        [10]: 00 (0)
        [11]: 00 (0)
        [12]: 00 (0)
        [13]: 00 (0)
        [14]: 00 (0)
        [15]: 00 (0)
        [16]: 00 (0)
        [17]: 00 (0)
        [18]: 00 (0)

Instance 1
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 00 (0)
        [10]: 00 (0)
        [11]: 00 (0)
        [12]: 00 (0)
        [13]: 00 (0)
        [14]: 00 (0)
        [15]: 00 (0)
        [16]: 00 (0)
        [17]: 00 (0)
        [18]: 00 (0)

T25:
        [ 0]: 03 (3)
        [ 1]: 00 (0)
        [ 2]: d0 (208)
        [ 3]: 67 (103)
        [ 4]: 30 (48)
        [ 5]: 58 (88)
        [ 6]: 00 (0)
        [ 7]: 00 (0)
        [ 8]: 00 (0)
        [ 9]: 00 (0)
        [10]: 00 (0)
        [11]: 00 (0)
        [12]: 00 (0)
        [13]: 00 (0)
        [14]: c8 (200)
        [15]: a0 (160)
        [16]: 0f (15)
        [17]: 00 (0)
        [18]: 00 (0)
        [19]: 00 (0)
        [20]: 00 (0)

T27:
Instance 0
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)

Instance 1
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)
        [ 5]: 00 (0)
        [ 6]: 00 (0)

T40:
Instance 0
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]: 00 (0)
        [ 3]: 00 (0)
        [ 4]: 00 (0)

Instance 1
        [ 0]: 00 (0)
        [ 1]: 00 (0)
        [ 2]

ANd then suddenly, for no appearant reason, touchscreen stopped but starts working again after suspend/resume. And starts spitting out error messages.

Now it calm again. 

Reminds me of when my sons were babies :-)

Other then this little problem, the C720P really is a fabulous device.

With rc5 most error messages disapear.

However, touch does not work on boot/login (so that regresses compared to -rc4). After suspend/resume it seems to be working fine. No new error messages appear. Tried also chromium browser as this supports multi-touch gestures like pinch in/out, swipe left/right in the main window etc. This all works fine.

dmesg | grep atmel_mxt_ts
[    6.725014] atmel_mxt_ts 8-004a: Direct firmware load for maxtouch.cfg failed with error -2
[    6.725019] atmel_mxt_ts 8-004a: Falling back to user helper
[    6.739529] atmel_mxt_ts 8-004a: Family: 162 Variant: 0 Firmware V2.0.AB Objects: 33
[  139.094815] atmel_mxt_ts 8-004a: T44 count 255 exceeded max report id
[  139.102204] atmel_mxt_ts 8-004a: Unexpected invalid message

No change with -rc6

Tried with 3.17 (release) still no change.

However, today logged in to Crome OS, which installed an update (I guess).

And tada, logging back into Kubuntu touchscreen works (before and after  suspend/resume).

Or something else changed? I don't know. Comparing dmesg:

dmesg | grep atmel_mxt_ts
atmel_mxt_ts 8-004a: Direct firmware load for maxtouch.cfg failed with error -2
atmel_mxt_ts 8-004a: Falling back to user helper
atmel_mxt_ts 8-004a: Resetting chip
atmel_mxt_ts 8-004a: Family: 162 Variant: 0 Firmware V2.0.AB Objects: 33

So something is now resetting the chip, and invalid messages disappeared.

If there is any way I can help to clear this up let me know. Otherwise we can probably close this bug.

Thank you Nick (and whoever siltenty contributed)!

Cheered to early it seems.

What I find is that after booting ChromeOS then shutting down, then switching on and booting Kubuntu the touch screen work fine. But after restarting Kubuntu (without powering down) touch screen only works after doing a suspend/resume cycle.

Ok, so finally I discovered:
- after a cold boot of 3.17 the touch screen works fine
- after a restart (warm boot) the touch screen work only after suspend.

To me that sounds like a i2c not being properly reset on boot?

I have experienced this issue myself on a Chromebook Pixel running kernel 3.18.9 and 3.19.1 under Ubuntu 14.04.2. Previously I ran 3.13.0-46 under which the tpad and tscreen both worked. 
I tried fixing by backporting the driver from 3.16.4 to 3.18.9, and when this did not work I tried reverting the kernel back to 3.13.0. The tpad and tscreen both failed to work completely. A suspend/resume nor module reload did not fix the issue. 
With kernel 3.18.9 I was able to get a click-event from the tpad, but nothing else.
Further looking into the issue, I found a useful thread on https://lkml.org/lkml/2014/7/24/364 where similar atmel mxt issues where described. I got (https://github.com/atmel-maxtouch/obp-utils) and compiled the atmel tool described there (mxt-app). Next, I checked some items in both chips (and got a lot of timeout errors), including the configuration using the command (make sure i2c-dev is loaded):
  mxt-app -d i2c-dev:1-004b --save fail.cfg
Where "i2c-dev:1-004b" is the address of either the TPAD or TSCREEN devices as found in your kernel logs.
After doing that, I compared the configuration file that was dumped to the original ChromeOs configuration file for these devices, found under /[root chromeos drive]/opt/google/touch/config/
 ...1664s.raw -> for the TSCREEN configuration
 ...224sl.raw -> for the TPAD configuration

I found there was a difference between the two, so somehow this configuration must have gotten corrupted in the steps I took above.

Next, I restored the correct configurations from ChromeOS to the device using
  mxt-app -d i2c-dev:1-004b --load 1664s.raw (for the TSCREEN device)
  mxt-app -d i2c-dev:1-004b --load 224sl.raw (for the TPAD device)

Sample output of the tool:
Version:1.20-1-g8283
Registered i2c-dev adapter:1 address:0x4b
Loaded config from /home/sander/atmel/tpad.raw in OBP_RAW format
Writing config to chip
Configuration loaded
Backed up settings to the non-volatile memory
Configuration backed up
Sending reset command
Chip reset

After executing this with the appropriate configuration file, this immediately fixed both devices. The issues did not appear again after a reboot, but I will be paying attention if/when the issue does occur again.
I hope this helps to debug the issue further, and to help fixing the issue for whoever experiences it.

Sander

Sander, this is not exactly my issue.

For me since 3.17 and up to 3.19 the touch screen works after a cold boot.
After a warm boot it needs a suspend/resume cycle, then it works. it then stays working no matter how many suspens/resume cycles follow (i.e. not random).

I still get the firmware load error, but that does not prevent the touchscreen from working.

So you tested the configuration using the above instructions and did not see any difference ? In that case, it only seemed like my issue, but as it is not a kernel bug it is not worth a separate bug, just for information.
Good luck with the issue still though.

No I didn't test according to your instructions. I am not a kernel developer, just a simple soul trying to help out where I can.

I'm just saying in your case things seem to be failing completely, while in my case there could be an initialization problem and cold start or suspend/resume seems to fix that.

And in your case you have been able to capture configurations under chromeos and linux. That might be very usefull to the developers?

You are right, but what I do read in your description of the issue is that reinitialization fixes it: I believe the Atmel stores some of it's configuration in backup nvram, so perhaps in your case the configuration is simply overwritten upon suspend (somehow), and restored upon cold boot (because there is nothing in volatile ram yet). That is why I thought that if you run the above instructions on your Acer, with the correct configuration file as gotten from the local Chromeos installation (or recovery disk), you might recover without cold restart. In that case, you know where the problem lies and the fix is not in the kernel.

Ah.

But actually it works for me after a cold boot. After a warm boot it doesn't until I suspend/resume. So either suspend or resume would also restore the configuration.

That would be weird. And also suggests that it should be possible to restore the configuration after a warm boot.

Personally I believe that the i2c bus is left in the wrong state after a warm reboot, and the i2c hangs. Probably after a cold boot i2c is in a known state. In that case appearantly a suspend/resume cycle resets the i2c to a known state too. (this is of course just me guessing, based on trouble shooting embedded microcontrollers with i2c to external flash memory, not linux related).

In my experience i2c devices need to follow a specific reset sequence on power up or warm reboot and can't be trusted to be in a known state when you initiate communication. However, I have no idea how linux handles this, or where in the code that might be.