Hi Pali, > Am 20.02.2017 um 20:42 schrieb Pali Rohár <pali.rohar@xxxxxxxxx>: > > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
