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: <CAN+gG=FkhofpNmpP6=3uBeywYRVceYViGoAG1Z5W6u1Bofm9tA@mail.gmail.com>
Date:	Wed, 26 Nov 2014 09:33:26 -0500
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Ulrik De Bie <ulrik.debie-os@...ig.org>
Cc:	Marcus Overhagen <marcus.overhagen@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...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 Ulrik,

On Tue, Nov 25, 2014 at 4:23 PM,  <ulrik.debie-os@...ig.org> wrote:
> 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 for the progress on these. Do you think you will be able to get
something in shape before the final 3.18?

Dmitry, can we either revert the current patches and reschedule them
for 3.19 or at least apply one quick fix? I am starting to see a lot
of people complaining about it, and I am wondering if adding this
functionality in a -rc5 release was not a good idea :-/.

Cheers,
Benjamin
--
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/