Hi Pali,

Am 20.02.2017 um 20:42 schrieb Pali Rohár [off-list ref]:

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.

This assumes that I can and want to write a graphics system myself.

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.

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.

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

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