Am 20.02.2017 um 22:08 schrieb Pali Rohár [off-list ref]:

On Monday 20 February 2017 20:42:15 Pali Rohár wrote:

quoted

Hi Nikolaus!

On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:

quoted

Hi Dmitry,

quoted

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.

Looking at kernel code... via EVIOCSABS ioctl() you can even set
resolution from userspace for specified input device.

So this could be potentially used for calibrating input device from
userspace? (In case DT data will not fully match current HW)

quoted

I hope that XServer is already using it for evdev devices...

For whole implementation look at evtest program. That should be good
starting point for your userspace implementation.

While I'm watching this discussion... in my opinion kernel should
just invert input axes (when needed)

It is questionable why it should do that at all then.

User-Space can also easily do it. Either the driver should provide raw
data only or if it does pre-processing (scaling by +/-1), why exclude
pre-scaling by other factors?

quoted

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

--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org