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

H. Nikolaus Schaller
2017-02-21T06:50:06Z

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

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár <pali.rohar@gmail.com>:
>
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>>
>> It is questionable why it should do that at all then.
>>
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
>
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
>
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

>
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

>
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
>
>>>> and should not do any other
>>>> normalization or integer/floating-point
>>>> re-calibration/re-calculation. If it correctly exports minimum
>>>> value, maximum value and resolution then userspace can correctly
>>>> re-scale input events to units which userspace needs (e.g. mapping
>>>> into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus

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