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