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