linux-kernel - Re: [PATCH v2] Input: synaptics

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: <20120720130350.GA1508@polaris.bitmath.org>
Date:	Fri, 20 Jul 2012 15:03:50 +0200
From:	"Henrik Rydberg" <rydberg@...math.se>
To:	Daniel Kurtz <djkurtz@...omium.org>
Cc:	Chung-Yih Wang (王崇懿) <cywang@...gle.com>,
	Chase Douglas <chase.douglas@...onical.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	JJ Ding <dgdunix@...il.com>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Input: synaptics - use firmware data for Cr-48

> > Propagating information about various sensor defects to userspace
> > sounds horrid to me. The sooner we can forget about these devices, the
> > better.
> 
> Not providing the userspace driver with enough information to give
> users the best experience possible sounds horrid to me.

The question was whether we should add those to the long-lived input
interface or not, sorry if that sounded like a rant.

> It turns out
> that using a bounding box with fixed "[(min_x, min_y), (max_x,
> max_y)]", and no per-finger pressure information, instead of the
> coordinates and pressures provided by the firmware, is throwing away
> useful data that could be used by the userspace driver.

So far, we have provided the baseline of reliable data from similar
devices.

> What we would like is a way to tell userspace what the firmware
> originally intended, but with a caveat that the firmware can't be 100%
> trusted.  And, since this is for a relatively small class of hardware,
> to do it in a way that doesn't consume precious resources, like
> additional input properties.

Input properties are not a precious resource, there is no limit on the
bitmask values or anything like that, but there is no rush to add new
ones.

> >> > > * Leave the device as SEMI_MT, but provide the real locations, and
> >> > > allow userspace to determine the device vendor/model/etc. If
> >> > > userspace knows that a specific device behaves in a specific way, it
> >> > > can do its own quirking handling. Given the specificity of this
> >> > > behavior to only some devices of one brand, this would be my
> >> > > suggested resolution to the issue.
> >> >
> 
> This is essentially what this patch does.

I am interpreting Chase's suggestion as simply reporting the raw
values instead of min/max.

> It sets the SEMI_MT flag to
> indicate that the kernel data cannot be totally trusted, and then
> provides real MT-B (including per-finger pressures), instead of a
> fixed bounding box.  It leaves it to userspace to treat the two slots
> worth of coordinates as a bounding box or as actual fingers using its
> own heuristics.  By limiting to only one hardware type (using DMI),
> any breakage caused by this alternative use of the SEMI_MT flag is
> limited.

So it seems there is no need to add logic to the driver, only change
one line from min/max to raw data for this particular hardware. That
would solve your problem, yes?

> Hopefully it is clear what we are trying to accomplish.  I don't see
> how we can make a bounding box, even an improved bounding box, work.
> Perhaps Henrik has a really good idea, but I haven't been able to
> figure out what he is suggesting.

I understand you are not interested in looking into this, and your
main objective is quite clear.

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/