Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

HI Pavel,

> Am 20.02.2017 um 20:29 schrieb Pavel Machek <pavel@xxxxxx>:
> 
> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail