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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141125212321.GA12591@lantern>
Date:	Tue, 25 Nov 2014 22:23:23 +0100
From:	ulrik.debie-os@...ig.org
To:	Marcus Overhagen <marcus.overhagen@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Hans de Goede <hdegoede@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-input <linux-input@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [git pull] Input updates for 3.18-rc4

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/