Am 15.01.2015 um 15:38 schrieb Sebastian Reichel [off-list ref]:

Hi,

On Thu, Jan 15, 2015 at 08:36:44AM +0100, Dr. H. Nikolaus Schaller wrote:

quoted

quoted

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)?

quoted

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.

quoted

quoted

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.

quoted

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