On 04/01/2015 08:46 PM, Fasse wrote:
On Wed, 01 Apr 2015 20:05:46 +0200
Ulf Brosziewski<[email protected]> wrote:
Hi,
there might be a problem. The Linux driver for that touchpad type also
accepts "debounce packets", which have the same format as for the
non-crc version. I have no idea whether that is correct and if those
packets do occur in practice, but if they do they wouldn't pass this
version of sync() (byte 3 would be 0x02 then).
You are right. I haven't had issues so far with debounce packets
missing but I obviously only have a very small sample size so there is
that. Since the debounce packet is ignored anyways I don't know if it
matters that it is thrown out early. Although if it didn't matter there
probably wouldn't even be a debounce packet? We could allow byte 3 to
pass if its value after the check is 0x02 but that kind of defeats the
purpose of the integrity check I guess.
Fortunately the values of debounce and head packets match up for non crc
elantech v3 touchpads. I don't think there is an elegant way to solve
this problem because pms_sync_elantech_v3 is called before the packet is
complete and you need the whole packet to check if it is a debounce
packet. To solve this we would have to do somthing similar to the linux
driver by only checking complete packets.
Yes, without some refactoring there won't be an elegant way.
pms_sync_elantech_v2 encodes some sync state in the 'flags' field
(ELANTECH_F_2FINGER_PACKET), but doing the same in the v3/CRC case might
be ugly.
