Hi Pali,
Am 20.02.2017 um 22:07 schrieb Pali Rohár pali.rohar@gmail.com:
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@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.
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#n...
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