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: <20120508235219.GA4067@yabbi.redhat.com>
Date:	Wed, 9 May 2012 09:52:19 +1000
From:	Peter Hutterer <peter.hutterer@...-t.net>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, chatty@...c.fr,
	chasedouglas@...il.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Input: MT - Include win8 support

On Tue, May 08, 2012 at 08:40:52PM +0200, Henrik Rydberg wrote:
> > > to aid in the discussion, I have shared a drawing of the MT model
> > > and the (supposed) win8 model.
> > > 
> > > https://docs.google.com/document/d/1KKu7kqPOsvE9tCmWhdGnmO8tgmN0Cd-Mv_crVaCZueY/view
> > 
> > having an asciiart version of this in Documentation/ would be quite useful,
> > IMO
> 
> Yep, that ought to be possible to arrange.
> 
> > Insert a paragraph into the actual documentation. I think that's more
> > helpful than tacking it on (if not quite as nice in a diff)
> > 
> > "The orientation of the ellipse. The value should describe a signed quarter
> > of a revolution clockwise around the touch center. The signed value range
> > is arbitrary, but zero should be returned for a finger aligned along the Y
> > axis of the surface, a negative value when finger is turned to the left, and
> > a positive value when finger turned to the right. When completely aligned
> > with the X axis, the range max should be returned.  
> > 
> > Touch ellipsis are symmetrical by default. For devices capable of true 360
> > degree orientation, the reported orientation must exceed the range max to
> > indicate more than a quarter of a revolution. For an upside-down finger, 
> > range max * 2 should be returned.
> > 
> > Orientation can be omitted if the touching object is circular, or if the
> > information is not available in the kernel driver. Partial orientation
> > support is possible if the device can distinguish between the two axis, but
> > not (uniquely) any values in between. In such cases, the range of
> > ABS_MT_ORIENTATION should be [0, 1] [4]."
> 
> Looks good, will copy that in its entirety. :-)
> 
> > Not a big fan of reporting values above absmin/absmax, tbh. It means we
> > can't rely on the axis values and have to special-case it. Plus, there's no
> > way to detect this before you actually get a value.
> 
> True, and I am open to other suggestions. However, I think the
> proposal integrates pretty well with the existing model and is likely
> to produce reasonable results without userland modifications.
> 
> > > Looking at the figure, it is clear that the MT model has two centers,
> > > one for each ellipse. Thus, center is not discriminating
> > > enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> > 
> > ABS_MT_OUTER_CENTER
> 
> I appreciate the suggestion, but along two-word combinations,
> ABS_MT_OUTER_POSITION would integrate better with existing names. Both
> seem awfully long, though.

problem I see with "outer position" is that I'd associate it with the
top/left position of whatever "outer" is, not with the center of said
envelope. that's why I'd argue that "center" should be somewhere in the
name.

Cheers,
  Peter
--
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