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:   Tue, 21 Feb 2017 09:47:24 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     "H. Nikolaus Schaller" <hns@...delico.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 <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-omap <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

Hi!

On Tuesday 21 February 2017 08:14:09 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@...il.com>:
> > 
> > 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.
> 
> I can't find this function defined anywhere but used in 101 LOC.
> LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res
> 
> What is going on here?

It is inline function defined by preprocessor. This should help you:

git grep INPUT_GENERATE_ABS_ACCESSORS
git grep input_abs_set_res

> > 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.
> 
> Ok, if this is not set by a driver it is indeed a driver bug.

Zero value is special and means "driver does not know it". In case
driver really does not know it, then it is not a driver bug.

> But we have to define it's value in DT because the tsc2007 does not know
> anything about the panel dimensions.

Yes, driver itself does not know it and DT seems to be correct place.

> IMHO something that should be done by generic of_touchscreen.c

I agree. DT for specific hardware can pass these information into
touchscreen driver (which does not have to know these parameters) and it
exports it to userspace.

> If of_touchscreen would simply pass the touchscreen-size parameters
> to input_abs_set_res() and the bindings would define it to be units/mm
> it might have saved us all a lot of work and discussion.

Seem that nobody until now needed such thing and everybody is (probably)
using Xorg userspace with userspace calibration.

But it really make sense to set input_abs_set_res() from DT.

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ