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

["H. Nikolaus Schaller" <hns@goldelico.com>]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

Hi Pavel,

> Am 19.02.2017 um 20:05 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>> Hi Pavel,
>> I love discussions with you :)
> 
> Unfortunately I can't say the same.

> 
>>> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> 
>>>>> Solve it properly. That means passing calibration
>>>>> data from kernel to userland.
>>>> 
>>>> As written before, the really proper solution would be to provide floating
>>>> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
>>>> and leaving downscaling to user space (where everybody can make it
>>>> worse).
>>> 
>>> That has no advantages,
>> 
>> It has the advantage of providing you with the full precision of raw data (but
>> properly scaled) so that you don't loose any bit of information. This is what
>> you just asked for - one or two mails before.
> 
> Not really, right? No matter what kind of fixed point you introduce,
> you'll still loose precision.

Can you please elaborate?

My thoughts:

If the ADC has 12 bit of precision, then let's say 32 bits (16 before and 16
after the decimal point) of fixed point precision are not loosing anything
if you scale to screen coordinates (in most cases they are between 480 and
1280 max).

Theoretically you can loose the LSB of the 16 bits right of the decimal point.
This is ca. 0.000015259 pixels of precision. I don't care about this loss of
precision... Do you? If yes, why?

But as said I don't think we need float or fixed point for practical systems
at all.

> 
>>> and floating point in kernel is hard. Also
>>> you'd either have to invent new interface, or you'd break touchscreen
>>> for people that already have their touchscreens calibrated.
>> 
>> No, I don't break calibration for people using a different chip.
> 
> So you propose your touchscreen to behave differently from all other
> touchscreens in tree?

No. I only propose that my touch screen behaves properly and in the
best way it can. If others are worse, they should also be improved at
some time.

And note that I am not making things different from others in tree, I
am making the tsc2007 right (incl. following the touchscreen bindings
which define the touchscreen size in "Pixels").

> That's just no-go.

In other words: you want to block any improvements unless your favourite
touchscreen is giving directions...

> 
>>> Yes, that's not really proper solution, that just overengineered. Not
>>> worth implementing. Pass calibration data to userland.
>> 
>> You seem to repeat yourself and just say which solution you prefer,
>> but I am missing the arguments why your solution (Pass calibration data
>> to userland) is right and the best one.
>> Which problems does it solve?
> 
> All you described.

I think you are missing one problem: providing already properly scaled touch
values to user space.

Please look how iio is doing raw and processed data.

> 
>> Which one does it solve better than others?
> 
> It is not terminally ugly.

"ugly" is not a technical or scientific criterion and depends on your personal
perception. Do you have a better argument?

> 
>> How can you implement it in
>> a stable and portable way?
> 
> Easily.

Please go ahead and show code.

> 
>> How can you make sure that all user-space GUI
>> systems can and will make use of this calibration data?
> 
> You can't,

Exactly. Hence my proposal is superior. Because it avoids asking
the user-space to use calibration data.

>  and you don't need to.

How can you know that I don't have to? Do you know my systems and
users and what they want?

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]