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: <4BA8DA1B-D6CB-4D38-AAD6-3B1CF217E521@goldelico.com>
Date:   Tue, 21 Feb 2017 07:42:17 +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 22:54 schrieb Pali Rohár <pali.rohar@...il.com>:
> 
> 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).

Interesting thing. It does not seem to be well known because nobody else
brought it up during several months of lenghty discussions.

I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749

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

So a kernel can simply add a new interface and declare bugs for userland?

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

Difficult to judge because there is scarce documentation of this.

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

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