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]
Message-Id: <201702202254.35023@pali>
Date:   Mon, 20 Feb 2017 22:54:34 +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@...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

On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@...il.com>:
> > 
> > On Monday 20 February 2017 21:35:18 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. 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.
> >> 
> >> This assumes that I can and want to write a graphics system
> >> myself.
> > 
> > Not only. There are already existing graphics systems. And you need
> > to provide needed information from kernel, so they can start using
> > it.
> > 
> > So input_abs_set_res() is needed to use in your kernel driver.
> 
> I didn't know about this feature and obviously nobody else has
> implemented it in the tsc2007 driver.

So... before doing other things, can you deeply look at it and check if 
it really fixes this problem? Because I think that yes.

You can probably set it from DT and in your DT file you can have stored 
screen size (or resolution factor).

Also for testing, you can set it even via userspace (ioctl which I wrote 
in previous email).

> >> And if it does, it does it in a
> >> plethora of different implementation states. That is the reason
> >> why we want to solve it once for all userlands in the kernel and
> >> not rely on user-space help.
> > 
> > For me this looks like "we are going to fix userspace bugs in
> > kernel".
> 
> Such things are system bugs and it is neither necessarily a userspace
> or kernel bug.

In case kernel defines stable API/ABI and correctly provides information 
via that API/ABI and application does not work correctly, then I would 
say it is bug in application. Not in kernel.

We can say that some kernel API/ABI is wrong too. And in this case it 
could be bug in kernel.

So is current stable kernel API/ABI for input device wrong? I do not 
thing. But if you think that yes, please show us what exactly and we can 
start discussing how to fix such problem which you see/have. I know that 
no application is without bugs, but in my opinion problem which you are 
describing is already solved and defined by current stable kernel ABI.

> > Really! Not a good idea. Plus I still see this as abusing kernel
> > API/ABI as resolution should be handled differently as you are
> > proposing.
> 
> I don't understand what you say here. Where are we abusing kernel
> API/ABI?

I mean that we already have stable API/ABI how to export size of input 
screen from kernel to userspace. And you want to rescale event data 
directly in kernel to workaround problem of screen size. So I think this 
is abusing API/ABI as kernel already have API for it.

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