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=EfOjm5AX+g22ksFTZhw-rdjT5vWmh0mu6RQZ8oXPCRqw@mail.gmail.com>
Date:	Sun, 6 May 2012 16:34:28 +0200
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Henrik Rydberg <rydberg@...omail.se>,
	Chase Douglas <chasedouglas@...il.com>,
	Peter Hutterer <peter.hutterer@...-t.net>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Stephane Chatty <chatty@...c.fr>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] input: Introduce MT_CENTER_X and MT_CENTER_Y

Hi Henrik,

Well, this is the mail I intended to send yesterday before I run out
of internet connection. This may be useless, but, I'll send it
anyway....

On Fri, May 4, 2012 at 3:48 PM, Henrik Rydberg <rydberg@...omail.se> wrote:
> Hi Benjamin, Stephane,
>
>> Microsoft published a new version of their multitouch specification.
>> They introduced a new multitouch field: MT_CENTER_X|Y.
>
> I would like a bit of elaboration here, since I am not convinced the
> mapping should be directly translated to the MT protocol.
>
> Clearly, the basic idea to be able to model an assymmetric tool is
> good. Without an angle description, however, there seems to be a
> mismatch in the degrees of freedom. In win8, one can place the hot
> spot in a corner of the rectangle, but one cannot make the rectangle
> into an ellipse in that direction.

That's not the interpretation I made of the spec.
http://msdn.microsoft.com/library/windows/hardware/br259100

Win8 is a total respin of the multitouch protocol (though backward
compatible). It asks for a lot more reliability and performances for
the devices.
>From what I understood, the T point (the touch) can be an arbitrary
point within the ellipse. Furthermore, the ellipse can be oriented in
an arbitrary rotation (like linux) because they introduced the hid
field Azimuth (0x3f) that is the "Counter-clockwise rotation of the
cursor around the Z axis".

To sum up, there are two kind of information:
- The touch point (where the user wants to touch)
- The elliptic shape of the touch (width, height, center, azimuth, pressure)

I think these two information are interesting as most of the time, the
center of the ellipse is _not_ the point where the user wants to
touch. The best thing to test that is to see how many time you miss
the pixel you want to touch in the current implementation.

I also wanted to publish these 2 last patches to raise the discussion,
and to show that the fix of the randomness in the splitting of the
touches within the reports was compatible with new kinds of devices.

We should focus for now (3.5) on the first 3 patches, and let aside
the 2 last for the next version, when everyone agrees.

Cheers,
Benjamin


> In linux, one can put the ellipse
> in the wanted direction, but the hot spot is always in the center. To
> first order, both models allow for finger-rotation information, but in
> different ways. Adding more parameters requires a bit more
> thought. Perhaps one should use the newly found win8 parameters to
> reshape the pointing ellipse to start with.
>
> Thanks,
> Henrik
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ