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: 3900 bytes --]

Hi Pavel,
I love discussions with you :)

> 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.

And it provides me (and my users) with properly scaled touch coordinates, which
is what I (and they - compare e.g. comment by Andreas Kemnade) ask for.

So it would be a solution that fulfills both requirements. And fulfilling
requirements of two groups of people is advantageous to making only one happy.
Isn't it?

> 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.

And since we just upstream a solution for devices (GTA04) which already use this
mechanism for years, we also won't break their calibration, because they are happy
with the non-calibration it provides.

We break it only for those, who use the same chip *and* upgrade to a kernel which
includes this patch. And even then, only if they update their device tree to use
it (the default without DT modifications is to provide raw data as before). If
they stay with an older kernel or older DT there is no change and action required.

So there are ca. 5 pre-conditions that others will notice a change at all.

Do you think user-space recalibration is such a difficult task compared to
upgrading a kernel that it must therefore be avoided? Compared to other
kernel-userland synchronization problems it has the good side that you
even will notice it immediately and will know what to do (recalibrate once
and it is done forever).

> Just
> pass calibration data to userland.

What is this good for if kernel can already do the calibration for userland?
If the kernel does it, it don't even waste efforts to pass calibration data
to userland.

And don't forget: if you need calibration data in userland, there are much
better mechanisms. The simplest one is a file (e.g. xorg.conf) which is
something the kernel and X11 already supports.

I.e. adding a new mechanism to pass calibration data from the kernel to
user-space doesn't make any sense, IMHO.

If the kernel knows about calibration it should use it directly and process it.
Like in iio where you can get raw and processed data, although processing could
also be done completely in user-space. So there seem to be good reasons to do
it in kernel...

And, citing your argument from above: "Also you'd either have to invent
new interface, or you'd break touchscreen for people that already have their
touchscreens calibrated."

> 
>> But I don't think it is worth implementing subpixel touch events for real
>> world devices due to the jitter I mentioned.
> 
> 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?
Which one does it solve better than others? How can you implement it in
a stable and portable way? How can you make sure that all user-space GUI
systems can and will make use of this calibration data?

BR and thanks,
Nikolaus


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