On 02/04/15(Thu) 18:43, Ulf Brosziewski wrote: > On 04/02/2015 03:39 AM, Fasse wrote: > >On Wed, 01 Apr 2015 21:23:15 +0200 > >Ulf Brosziewski<ulf.brosziew...@t-online.de> wrote: > >>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. > > > >Admittedly I am biased because I don't want to refactor ~2400 LOC to get > >my touchpad working but I don't think that crc enabled v3 touchpads use > >the debounce packet. I just installed Ubuntu and compiled the 3.19.3 > >linux kernel with added printk statements in the elantech_packet_check_v3 > >function on my laptop. In the linux kernel documentation [0] for elantech > >touchpads it says about the debounce packet: "Note on debounce: In case > >the box has unstable power supply or other electricity issues, or when > >number of finger changes, F/W would send "debounce packet" to inform > >driver that the hardware is in debounce status." > >I could not reproduce the unstable power supply but when switching the > >number of fingers on the touchpad no debounce packet is issued. Instead > >just the head and tail packets are registered and processed (unlike the > >OpenBSD driver which ignores the tail packet). This leads me to belief > >that v3/crc does not use debounce packets. > >Do you think this is possible/likely? (...) > > Why not? You seem to have shown that it is possible, at least for your > hardware and multiple touches. It might well be that the author(s) of the > Linux driver just wanted to be on the safe side.
Even if that's true, nothing prevent us to commit this diff first, as long as it does not introduce regression and then work on the possible refactoring needed to support debounce packets :)
