From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Henrik Rydberg" Subject: Re: [PATCH v2 08/11] HID: hid-multitouch: fix Win 8 protocol Date: Sun, 4 Nov 2012 21:54:59 +0100 Message-ID: <20121104205459.GA777@polaris.bitmath.org> References: <1351241067-9521-1-git-send-email-benjamin.tissoires@gmail.com> <1351241067-9521-9-git-send-email-benjamin.tissoires@gmail.com> <20121029221905.GA15537@polaris.bitmath.org> <20121031185332.GA1745@polaris.bitmath.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Benjamin Tissoires Cc: Dmitry Torokhov , Jiri Kosina , Stephane Chatty , linux-input , "linux-kernel@vger.kernel.org" List-Id: linux-input@vger.kernel.org Hi Benjamin, > The goal of this patch is to implement in a reliable way Win 8 > multitouch protocol (to avoid quirking many devices). Thanks to the > precision they made in the specification, I think it is feasible: > they add the dynamic part that were missing in Win 7 spec: > """ > When sending data in hybrid or parallel mode, a contact that is > delivered in one report must be delivered in all subsequent reports > until it is lifted off the screen. If time is needed to adequate > determine if the contact was lifted off the surface, the device must > report the last known position of the contact and then deliver the > =E2=80=9CUP=E2=80=9D state of the contact in a subsequent report. Dev= ices should not > send a report without the information for that contact while trying t= o > determine its current state. > """ The text seems to say that devices are not required to send touch state information in a separate frame, but if the device needs time to determine the touch state, the touch properties should stay the same during that time. > Thus, the quirk ALWAYS_VALID fits very well with win 8 devices (the > device has to send the touch until it is lifted and out of range, and > the device must send the 'up' state). One could simply add another quirk which fits the win8 case exactly instead. No need to change the existing one. > The problem lies that some devices may reuse contact id 0 within the > frame for the end of the report (my Win8 device doesn't has this kind > of problem): >=20 > With the following hid usages: > I -> contact Id > T -> tip switch > X, Y -> X, Y > S -> scan time > C -> contact count >=20 > a friendly device would report: >=20 > I:1 T:1 X:125 X:130 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:0 C:01 > I:1 T:1 X:130 X:135 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:1 C:01 > I:1 T:1 X:135 X:140 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:2 C:01 > I:1 T:1 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:3 C:01 > I:1 T:0 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:4 C:01 >=20 > *but*, I've already seen win 7 devices, that do send: >=20 > I:0 T:1 X:125 X:130 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:0 C:01 > I:0 T:1 X:130 X:135 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:1 C:01 > I:0 T:1 X:135 X:140 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:2 C:01 > I:0 T:1 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:3 C:01 > I:0 T:0 X:140 X:145 Y:750 Y:755 I:0 T:0 X:0 X:0 Y:0 Y:0 S:4 C:01 I see, more brain-damaged usage. :-) Still, there seems to be a simpler way to distinguish this case: if there are more than one touch with the same id in the frame, use the one with T=3D1. > The difference lies in the first bit, contact id is 0. >=20 > So, the quirk always valid is not sufficient because the second touch > in the frame will override the values of the first (the valid one). >=20 > As Microsoft says that "the device must report the last known positio= n > of the contact and then deliver the =E2=80=9CUP=E2=80=9D state of the= contact", so we > can safely discard the second touch because X and Y do not match the > current state of the valid touch. >=20 > Then, as exposed in the "How to Design and Test Multitouch Hardware > Solutions for Windows 8" document here: > http://msdn.microsoft.com/en-us/library/windows/hardware/hh872968.asp= x > when the device attempt the certification, if the "up" is not valid, > the error "Last move location different" raises, which, I hope will > prevent the device to get the certification. I think it would be too fragile to rely on this assumption. Hopefully the suggestion above will work equally well. Thanks, Henrik