Thread (94 messages) 94 messages, 11 authors, 2017-02-23

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

From: H. Nikolaus Schaller <hidden>
Date: 2017-02-19 19:32:40
Also in: linux-iio, linux-input, linux-omap, lkml

Hi Pavel,
Am 19.02.2017 um 20:05 schrieb Pavel Machek [off-list ref]:

Hi!
quoted
Hi Pavel,
I love discussions with you :)
Unfortunately I can't say the same.
quoted
quoted
Am 19.02.2017 um 18:15 schrieb Pavel Machek [off-list ref]:

quoted
quoted
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.
quoted
quoted
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...
quoted
quoted
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.
quoted
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?
quoted
How can you implement it in
a stable and portable way?
Easily.
Please go ahead and show code.
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help