Date:   Mon, 20 Feb 2017 21:20:20 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Michael Welling <mwelling@...e.org>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Igor Grinberg <grinberg@...pulab.co.il>,
        "Andrew F. Davis" <afd@...com>, Mark Brown <broonie@...nel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Alexander Stein <alexander.stein@...tec-electronic.com>,
        Eric Engestrom <eric@...estrom.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Petr Cvek <petr.cvek@....cz>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Nick Dyer <nick@...anahar.org>,
        Siebren Vroegindeweij <siebren.vroegindeweij@...mail.com>,
        Michel Verlaan <michel.verl@...il.com>,
        linux-input@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, linux-iio@...r.kernel.org,
        kernel@...a-handheld.com, Aaro Koskinen <aaro.koskinen@...ia.com>,
        Pali Rohár <pali.rohar@...il.com>,
        Andrey Gelman <andrey.gelman@...pulab.co.il>,
        Haibo Chen <haibo.chen@...escale.com>
Subject: Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

HI Pavel,

> Am 20.02.2017 um 20:29 schrieb Pavel Machek <pavel@....cz>:
> 
> Hi!
> 
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> 
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
> 
> If I draw a line in gimp, I don't expect it to have steps because of
> "barely noticeable" errors.

You can't draw a line with exactly 1 pixel distance on such a touch screen.

> 
>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> 
> Resistive touch is used for drawing, too.

Yes, for taking handwritten notes but not for high-precision graphics design.
For that you take a bigger screen and zoom the relevant areas.

> 
>> So the discussion boils down to "what gives the better usability?":
>> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
>> b) getting highest theoretical precision which has a low practical relevance
>> 
>> I am in favor of a). Like most users we ask. A minority is in favor of b).
>> Since we don't exclude b) users from reconfiguring their system to get it done
>> as they like. I think this is the best we can achieve.
> 
> Do you even read what I wrote?
> 
> Because I presented way to have both a) _and_ b).

I am not aware that you did this. You made a proposal for the X system but not
for others, e.g. Replicant.

> 
>>>>> No. You have to design interface such that they _can_ be improved, and
>>>>> what you propose does not work that way.
>>>> 
>>>> It works. Please do real world tests...
>>> 
>>> You do a real world test on N900, and propose upgrade path.
>> 
>> I have no N900 running. But since it uses a tsc2004/5 controller which seems
>> to be quite similar, you can likely copy&paste some code or add the algorithm:
>> 
>> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
>> 
>> Thats it.
>> 
>> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
>> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
>> user-space gets what it would have got before adding such a formula and then you
>> can and must do calibration there.
>> 
>> Taking this as the defaults if none of the new properties is specified, makes
>> the scaling feature completely disappear. And I don't care about 2 additional
>> subtractions, one multiplication and one division per axis.
>> 
>> So the upgrade path is:
>> 1. introduce new optional properties, parse and store them in the struct
>> 2. set defaults for the optional properties as described above
>> 3. add the formula to the code (1 line for each axis)
>> 4. deploy - nobody will notice
> 
> Good so far.

Ok!

> 
>> 5. update the DT and remove user-space calibration - people will be happy
>>   that they do not have to calibrate first any more
> 
> You can't do this. And this is fatal problem with your proposal.

> 
> If I update the DT in the kernel, my users will be very unhappy,
> because their screens will now be miscalibrated.

If you tell them that they should recalibrate once, after they upgrade
to Linux 4.12 because they no longer need it I doubt they will not be very
unhappy.

And as said I do not expect or force you to take step 5 for the N900 touch
screen. Not even step 1.

I would take this more sensitive if you would use the same chip.

> New kernel must not
> force users to update their userland at the same time.

Yes, it shouldn't. But to be honest, this is not my experience. I have to
tweak userland a little almost every time a new kernel merge window is done.
Admittedly not in the input system. And I may be using the wrong distribution.

But if you ever want to deploy better features it is really difficult to avoid.

Nevertheless, what problem do you have to implement steps 1-4 in kernel
and step 5 outside?

BR and thanks,
Nikolaus


Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists