Chrome OS Version: Chrome OS 3.14
Chrome OS Platform: Intel x64 compatible PC running ChromeOS

This problems happens with Win8 compatible 10 contact HID multitouch sensor connected to PC running ChromeOS with v3.14 kernel and using default kernel multitouch driver.

Steps To Reproduce:
(1) Place both palms and 10 contacts on 10 contact win8-compatible multitouch sensor 
(2) Tap with 10 fingers on sensor for some time to produce large amount of contact input 

Expected Result:
- Eventually multitouch performance becomes worse, i.e. zooming/scrolling gestures work sluggishly or do not work at all.
It is best detected using the default evtest program. When this problem occurs, evtest reacts on less and less number of fingers placed on sensor. 
 

Actual Result:

How frequently does this problem reproduce? 
-Always when number of actual contacts on sensor is equal to the maximal number of contacts for this touch sensor.

What is the impact to the user, and is there a workaround? If so, what is
it?
-Multitouch function deterioration. It is restored after reboot.

Please provide any additional information below. Attach a screen shot or
log if possible.
- The problem happens with default HID multitouch driver working with multitouch protocol B. In this protocol touch contacts are reported in slots 0-9 for 10 contact multitouch device. Each slot besides contact coordinates contains tracking ID generated by kernel driver (and reported to applications) and the "key" field which is a contact ID coming from touch controller. Initially all tracking IDs are -1 meaning that correspondent slots are free. When a new contact is coming from touch controller, a free slot (with tracking ID = -1) is allocated for it. However when this contact is lifted, tracking ID (-1) is reported by input_event() function but tracking ID field of the slot is not set to -1, meaning that this slot remains "äctive" even after the correspondent finger is lifted off. Eventually all available slots (10 for 10 contact multitouch) become "äctive" and a new contact is reported as events only if its contact ID is the same as one of the "key" fields of the slots. If contact ID sent from touch controller does not match any of "key" fields of the slots, this contact is ignored, even if it is the only contact touching the sensor.

I think tracking IDs of the multitouch slots should be reset to -1 after contacts are lifted.