lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Feb 2017 07:49:00 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Michael Welling <mwelling@...e.org>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Igor Grinberg <grinberg@...pulab.co.il>,
        "Andrew F. Davis" <afd@...com>, Mark Brown <broonie@...nel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Alexander Stein <alexander.stein@...tec-electronic.com>,
        Eric Engestrom <eric@...estrom.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Petr Cvek <petr.cvek@....cz>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Nick Dyer <nick@...anahar.org>,
        Siebren Vroegindeweij <siebren.vroegindeweij@...mail.com>,
        Michel Verlaan <michel.verl@...il.com>,
        linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        letux-kernel@...nphoenux.org, linux-iio@...r.kernel.org,
        kernel@...a-handheld.com, Aaro Koskinen <aaro.koskinen@...ia.com>,
        Pavel Machek <pavel@....cz>,
        Andrey Gelman <andrey.gelman@...pulab.co.il>,
        Haibo Chen <haibo.chen@...escale.com>
Subject: Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár <pali.rohar@...il.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@...il.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

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ