Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

["Pali Rohár" <pali.rohar@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 4653 bytes --]

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@gmail.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 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". 
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.

> 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

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]