Hi Pali, > Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar@xxxxxxxxx>: > > On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote: >> 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. > > So... before doing other things, can you deeply look at it and check if > it really fixes this problem? Because I think that yes. > > You can probably set it from DT and in your DT file you can have stored > screen size (or resolution factor). > > Also for testing, you can set it even via userspace (ioctl which I wrote > in previous email). Interesting thing. It does not seem to be well known because nobody else brought it up during several months of lenghty discussions. I have seen it is in use for scaling topics, e.g. https://lkml.org/lkml/2015/7/9/749 > >>>> 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. > > In case kernel defines stable API/ABI and correctly provides information > via that API/ABI and application does not work correctly, then I would > say it is bug in application. Not in kernel. So a kernel can simply add a new interface and declare bugs for userland? > > We can say that some kernel API/ABI is wrong too. And in this case it > could be bug in kernel. > > So is current stable kernel API/ABI for input device wrong? I do not > thing. Difficult to judge because there is scarce documentation of this. > But if you think that yes, please show us what exactly and we can > start discussing how to fix such problem which you see/have. I know that > no application is without bugs, but in my opinion problem which you are > describing is already solved and defined by current stable kernel ABI. > >>> 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? > > I mean that we already have stable API/ABI how to export size of input > screen from kernel to userspace. And you want to rescale event data > directly in kernel to workaround problem of screen size. So I think this > is abusing API/ABI as kernel already have API for it. BR and thanks, Nikolaus
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
