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

jic23 at jic23.retrosnub.co.uk jic23 at jic23.retrosnub.co.uk
Sun Feb 19 20:30:13 CET 2017

<michel.verl at gmail.com>,linux-input at vger.kernel.org,devicetree at vger.kernel.org,linux-kernel at vger.kernel.org,linux-omap at vger.kernel.org,letux-kernel at openphoenux.org,linux-iio at vger.kernel.org,kernel at pyra-handheld.com,Aaro Koskinen <aaro.koskinen at nokia.com>,=?ISO-8859-1?Q?Pali_Rohár?= <pali.rohar at gmail.com>,Andrey Gelman <andrey.gelman at compulab.co.il>,Haibo Chen <haibo.chen at freescale.com>
From: Jonathan Cameron <jic23 at jic23.retrosnub.co.uk>
Message-ID: <225406A8-329D-42B7-A55D-D4F759A00FA2 at jic23.retrosnub.co.uk>

On 19 February 2017 17:51:00 GMT+00:00, "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>Hi Pavel,
>I love discussions with you :)
>> Am 19.02.2017 um 18:15 schrieb Pavel Machek <pavel at 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
>>> or fixed point subpixel input events. Not arbitrarily scaling up in
>>> 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
>requirements of two groups of people is advantageous to making only one
>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
>Do you think user-space recalibration is such a difficult task compared
>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
>and it is done forever).
>> Just
>> pass calibration data to userland.
>What is this good for if kernel can already do the calibration for
>If the kernel does it, it don't even waste efforts to pass calibration
>to userland.
>And don't forget: if you need calibration data in userland, there are
>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...
Not a good example. Preferred option  in IIO is to pass up to userspace as raw if it is easy to describe 
the conversion i.e. if linear.

Processed is mostly for non linear nasty function cases or sensor hubs that are doing
scaling in hardware. A few slip through review and as the ABI allows it we let it slide.

>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
>touchscreens calibrated."
>>> But I don't think it is worth implementing subpixel touch events for
>>> 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
>systems can and will make use of this calibration data?
>BR and thanks,

Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the Letux-kernel mailing list