[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A77657DA-BFF3-4A4E-9302-047B77072F3A@goldelico.com>
Date: Mon, 20 Feb 2017 22:24:31 +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: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.
>
>>> I hope that XServer is already using it for evdev devices...
>>
>> No idea if it does. It is a black box for me out of our control.
>
> https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c#n1479
>
> So yes, it does.
>
>>> For whole implementation look at evtest program. That should be
>>> good starting point for your userspace implementation.
>>
>> The problem I have is that *I* have no userspace implementation and
>> the GTA04 project does not want to enforce one. We have several
>> different ones: X11 based (LXDE and others), Qt (fb based),
>> Replicant to name some.
>>
>> All have the same problem to be solved once. The common denominator
>> for a solution are 2 lines of code in the kernel plus some DT
>> properties you need anyways if calibration should be automated in
>> userland.
>
> As I wrote above part of linux input API is resolution value. And from
> all information I understood that having current value, minimal value,
> maximal value and resolution is enough for correct calculation of pixel
> coordinates in userspace.
>
> And Xserver evdev driver is using it.
>
> If other non-X11 application (which you want/need to use) use resolution
> information incorrectly (or calculate positions incorrectly), then this
> is bug that application. Not in Linux kernel, that is important.
>
> And I would rather see fixes of such bugs in that (broken) application
> as doing workarounds in kernel, just because of bugs in application.
>
> More important, are those applications really broken?
>
> From my point of view: Reporting size of input device is already part of
> stable kernel <--> userspace API/ABI and it should be used instead of
> inventing new way...
>
>>> 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).
>>
>> It can, but afaik it does not yet.
>
> I did not tested it, but code is in xf86-input-evdev already there.
>
> So please try to implement input_abs_set_res() in kernel driver and test
> userspace.
>
>> 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.
> 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?
>
>> Surely, userland can do a lot of things. It could also do the whole
>> file system stuff (FUSE).
>>
>> A more input device related example comes to my mind: userland could
>> do keyboard mapping completely. It would suffice if the kernel
>> presents some x/y coordinates or gpio-numbers for buttons and
>> user-space could map. Still there is a (pre-)mapping to Key-Codes.
>> And yes, they are mapped a second time in userland if needed, but it
>> works sufficiently well if not done.
>>
>> BR and thanks,
>> Nikolaus
BR,
Nikolaus
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists