Hi Pali, > Am 20.02.2017 um 22:07 schrieb Pali Rohár <pali.rohar@xxxxxxxxx>: > > 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@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. > > 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 didn't know about this feature and obviously nobody else has implemented it in the tsc2007 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". Such things are system bugs and it is neither necessarily a userspace or kernel bug. > 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. I don't understand what you say here. Where are we abusing kernel API/ABI? > >> 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 BR, Nikolaus
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
