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

H. Nikolaus Schaller hns at goldelico.com
Tue Feb 21 07:42:17 CET 2017

Hi Pali,

> Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar at gmail.com>:
> 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 at 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 at 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.
> 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
> 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,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170221/3a34edb3/attachment.asc>

More information about the Letux-kernel mailing list