linux-kernel - Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation

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]

Date:	Thu, 15 Jan 2015 17:14:38 +0100
From:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
To:	Sebastian Reichel <sre@...nel.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Belisko Marek <marek.belisko@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Benoit Cousson <bcousson@...libre.com>,
	Tony Lindgren <tony@...mide.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-input@...r.kernel.org, Marek Belisko <marek@...delico.com>,
	Jonathan Richardson <jonathar@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>,
	Yoichi Yuasa <yuasa@...ux-mips.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>
Subject: Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation


Am 15.01.2015 um 15:38 schrieb Sebastian Reichel <sre@...nel.org>:

> Hi,
> 
> On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote:
>>> 1. Perform conversion in input core rather than individual drivers. I
>>> think we should allocate a new bitmaps for some transformations and have
>>> the code do X/Y flip/clip of the coordinates.
>> 
>> Do you have a suggestion where this should be (I have no clue how
>> the input system works or is structured - we just know how to extend a
>> driver that uses it)?
>> 
>>> 2. Standardize on bindings. We already have of-touchscreen.c doing
>>> rudimentary parsing, we shoudl look into extending it rather than
>>> creating myriad of driver-specific bindings.
>> 
>> Ok, looks reasonable.
> 
> Documentation is in 
> 
> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

I did look into it now. Unfortunately, it does not fit well into my view of how bindings
should be. They should describe hardware (as we are told for many other kernel
subsystems).

Pixels and resolutions are IMHO related to the screen it is glued on - and that is
quite independent.

So I don’t see how they do describe the different ways the touch screen can be
wired to a tsc2007 controller.

Please can you add minimum and maximum properties for us?

Then, inverted-x and inverted-y is redundant because it is the same as having
an expected higher value from the ADC for the minimum coordinate and a lower
for the maximum.

> 
>>> Also, do we need swap and flip or do we simply need rotation (like the
>>> proposed Broadcom iproc driver has)?
>> 
>> Well, since the DT should describe hardware, there are 3 sets of wires which
>> can have a cross-over: X+ and X-, Y+ and Y-, X and Y.
>> 
>> So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an
>> interpretation of the result of these connections in combination with some
>> panel the touch is glued to and should therefore not be represented in the DT.
>> 
>> As a result we have proposed a scheme without explicit rotation. We specify what
>> coordinates X- and X+ should report at their ends (min, max) because the DT
>> programmer has to specify them anyways. Flipping is a result of defining these
>> coordinates in an ascending or descending way. Only swapping of the X and Y
>> wires can’t be implicitly defined so it has its own property. So the scheme we
>> have proposed tries to optimize the efforts needed to adapt new boards and write
>> DTs and focus the DT on hardware description.
>> 
>> As a bonus we also specify the min and max value to be reported for the touch
>> pressure (Z axis) using the same basic principle.
>> 
>> And it is a pure add-on on top of the existing driver so that it attempts not
>> to break existing device trees.
> 
> from what I can see there are no in-tree-users using any of the
> new properties.
> 
>> Maybe could you accept it as a first step for this specific driver (and let’s do
>> the big standardization work later on)?
> 
> That does not work, since you create an ABI.
> 
> -- Sebastian

--
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/