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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Feb 2017 23:45:49 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     Petr Cvek <petr.cvek@....cz>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        "H. Nikolaus Schaller" <hns@...delico.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>,
        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" <linux-input@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <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

On Monday 20 February 2017 23:21:37 Petr Cvek wrote:
> Hi,
> 
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller
> > <hns@...delico.com> 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:
> >>>> Hi Nikolaus!
> >>>> 
> >>>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> >>>>> Hi Dmitry,
> >>>>> 
> >>>>>> Input driver may set resolution for given axis in units per mm
> >>>>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
> >>>>>> ABS_RZ), and if you check the binding, you can use
> >>>>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
> >>>>>> of entire touch surface and set resolution from it so that
> >>>>>> userspace can calculate the proper scaling factor.
> >>>>> 
> >>>>> How is this information exposed by the kernel to user-space? By
> >>>>> scanning the DT file or tree?
> >>>> 
> >>>> Set input_abs_set_res() from kernel. And in userspace call
> >>>> EVIOCGABS ioctl() on input device. Look at struct
> >>>> input_absinfo, you should have all needed information here.
> >>>> This is generic input interface, no DT is needed.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device
> >>> from userspace? (In case DT data will not fully match current
> >>> HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be
> >>>> good starting point for your userspace implementation.
> >>>> 
> >>>> 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.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is
> > always "up" and "right" is always "right".
> 
> Actually my Xorg calibration 3x3 matrix is fine with both axis
> inverted (on TSC2046).

Yes, 3x3 matrix which represent affine transformation can code inverted 
axis. This is IIRC what Xorg is doing.

But with information of min, max and current values plus resolution you 
cannot code information that axes are inverted (unless you misuse fact 
what is minimal and what maximal value). And this is what kernel 
provides for input device.

Affine transformation supported by Xorg is "stronger" as resolution 
provided by kernel.

-- 
Pali Rohár
pali.rohar@...il.com

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ