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