Re: [git pull] Input updates for 3.18-rc4

[ulrik.debie-os@e2big.org]

Hi,

On Wed, Nov 19, 2014 at 11:21:31PM +0100, Marcus Overhagen wrote:
> Hi,
> 
> when moving a single finger [3] seems to be one of 0x21, 0x25, 0x31, 0x35
> moving two fingers [3] seems to be mostly 0x22, 0x26, 0x32, 0x36  but
> also sometimes it's 0x42, 0x46, 0x52, 0x56.
> It seems to occationally seems to switch between these two groups
> after touching the pad with three or more fingers, but not every time.
> 
> Moving three fingers I see[3] beeing  0x26, 0x36, 0x76, 0x66 (probably more)
> 
> regards
> Marcus


Ok, after some digging through the packet dump kindly provided by Marcus,
it is clear that Documentation/input/elantech.txt is not correctly 
representing anymore the packets of the v4 hardware. There should be some
0 and 1's replaced by x because they are currently "don't know" and definitely
not always 0 or 1.

Example:
He has 0x26,0x36,0x46,0x56,0x66,0x76 in packet[3], and the documentation had
the bits as:
id2 id1 id0   1   0   0   1   0
              X       X
The bits marked with X can thus be different. But when those are changed to
X==don't care then it is not trivial to differentiate them from the trackpoint
that has the following signature for that byte:
0   0   ~sy  ~sx  0   1   1   0



I'm considering the following change:
The test

        t = get_unaligned_le32(&packet[0]);

        switch (t & ~7U) {
        case 0x06000030U:
        case 0x16008020U:
        case 0x26800010U:
        case 0x36808000U:

could be moved to elantech_packet_check_v3/4() instead of the
simpler test on the lowest nibble of packet[3] (and keep the etd->tp_dev check):
       if ((packet[3] & 0x0f) == 0x06 && etd->tp_dev)
                return PACKET_TRACKPOINT;

I'll think a little bit more on it. Based on the packet dump I have this
seems to allow a perfect discrimation between trackpoint and touchpad packets.

Thanks,
Regards,
Ulrik