Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

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