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: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