Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1583736 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-17 21:50 +0100
    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-18 04:30 +0100
      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
        Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-19 00:50 +0100
          Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 13:10 +0100
            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Sebastian Reichel <sre@kernel.org> - 2017-02-19 21:20 +0100
              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
    Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-18 09:20 +0100
    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-18 10:20 +0100
      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
        Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-18 19:10 +0100
          Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 20:30 +0100
            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 00:00 +0100
              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 13:10 +0100
                Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 15:20 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 18:10 +0100
                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 18:20 +0100
                      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 19:00 +0100
                        Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 20:10 +0100
                          Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 20:40 +0100
                            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 22:00 +0100
                              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-19 23:10 +0100
                                Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:30 +0100
                                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
                                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-20 20:30 +0100
                                      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:30 +0100
                                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Petr Cvek <petr.cvek@tul.cz> - 2017-02-20 23:30 +0100
                                      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 09:40 +0100
                              Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-19 23:40 +0100
                                Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:50 +0100
                                  Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
                                    Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-20 20:40 +0100
                                      Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:30 +0100
                                        Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:00 +0100
    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-18 12:40 +0100
      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 02:20 +0100
        Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 18:00 +0100
          Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 20:50 +0100
            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 21:40 +0100
              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 22:10 +0100
                Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:30 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:00 +0100
                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 07:50 +0100
                      Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 10:00 +0100
            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 22:10 +0100
              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-20 22:30 +0100
                Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 23:00 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-20 23:30 +0100
                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:00 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Petr Cvek <petr.cvek@tul.cz> - 2017-02-20 23:40 +0100
                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:50 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 07:40 +0100
                    Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 10:10 +0100
                      Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Andreas Kemnade <andreas@kemnade.info> - 2017-02-21 18:20 +0100
                Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-20 23:10 +0100
                  Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:00 +0100
            Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation "H. Nikolaus Schaller" <hns@goldelico.com> - 2017-02-21 08:20 +0100
              Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pali Rohár <pali.rohar@gmail.com> - 2017-02-21 09:50 +0100
                Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new  common binding names, pre-calibration, flipping and rotation Christ van Willegen <cvwillegen@gmail.com> - 2017-02-21 10:00 +0100
          Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding  names, pre-calibration, flipping and rotation Pavel Machek <pavel@ucw.cz> - 2017-02-21 12:10 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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@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.

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).

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

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

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hi Pali,

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

[toc] | [prev] | [next] | [standalone]

#1585135

On Tuesday 21 February 2017 07:42:17 H. Nikolaus Schaller wrote:
> Hi Pali,
> 
> > Am 20.02.2017 um 22:54 schrieb Pali Rohár <pali.rohar@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@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.
> > 
> > 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

E.g. my touchpad (ALPS) exports this information. It is not touchscreen
device, but still it is absolute positioned device. And looking into
kernel tree it is used by more input drivers...

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

That is something different. But yes it could be problematic if you
create userspace and immediately after that kernel define some API which
is against usage of your userspace. So something like this would depend
on situation.

But I hope right now it is clear. That resolution property is there for
a long time and new code (which is your case) should use it.

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

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> 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.

Looking at kernel code... via EVIOCSABS ioctl() you can even set 
resolution from userspace for specified input device.

So this could be potentially used for calibrating input device from 
userspace? (In case DT data will not fully match current HW)

> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> 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).

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>> 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.
> 
> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> resolution from userspace for specified input device.
> 
> So this could be potentially used for calibrating input device from
> userspace? (In case DT data will not fully match current HW)
> 
>> I hope that XServer is already using it for evdev devices...
>> 
>> For whole implementation look at evtest program. That should be good
>> starting point for your userspace implementation.
>> 
>> While I'm watching this discussion... in my opinion kernel should
>> just invert input axes (when needed)

It is questionable why it should do that at all then.

User-Space can also easily do it. Either the driver should provide raw
data only or if it does pre-processing (scaling by +/-1), why exclude
pre-scaling by other factors?

>> 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).
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1584925

On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>
>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>> 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.
>>
>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>> resolution from userspace for specified input device.
>>
>> So this could be potentially used for calibrating input device from
>> userspace? (In case DT data will not fully match current HW)
>>
>>> I hope that XServer is already using it for evdev devices...
>>>
>>> For whole implementation look at evtest program. That should be good
>>> starting point for your userspace implementation.
>>>
>>> While I'm watching this discussion... in my opinion kernel should
>>> just invert input axes (when needed)
>
> It is questionable why it should do that at all then.

Because the task of the kernel is to provide unified view of the
hardware. Axis swapping and inversion is needed to that "up" is always
"up" and "right" is always "right".

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1584938

On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
> Hi,
>
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>
>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>
>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>> 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.
>>>>
>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>> resolution from userspace for specified input device.
>>>>
>>>> So this could be potentially used for calibrating input device from
>>>> userspace? (In case DT data will not fully match current HW)
>>>>
>>>>> I hope that XServer is already using it for evdev devices...
>>>>>
>>>>> For whole implementation look at evtest program. That should be good
>>>>> starting point for your userspace implementation.
>>>>>
>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>> just invert input axes (when needed)
>>>
>>> It is questionable why it should do that at all then.
>>
>> Because the task of the kernel is to provide unified view of the
>> hardware. Axis swapping and inversion is needed to that "up" is always
>> "up" and "right" is always "right".
>
> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

Yes, you can make it work for your touchscreen as long as you know
that it inverted somehow. How you gain this knowledge is the question.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

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

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek <petr.cvek@tul.cz> wrote:
>> Hi,
>> 
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>> 
>>>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>>> 
>>>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>>>> 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.
>>>>> 
>>>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>>>> resolution from userspace for specified input device.
>>>>> 
>>>>> So this could be potentially used for calibrating input device from
>>>>> userspace? (In case DT data will not fully match current HW)
>>>>> 
>>>>>> I hope that XServer is already using it for evdev devices...
>>>>>> 
>>>>>> For whole implementation look at evtest program. That should be good
>>>>>> starting point for your userspace implementation.
>>>>>> 
>>>>>> While I'm watching this discussion... in my opinion kernel should
>>>>>> just invert input axes (when needed)
>>>> 
>>>> It is questionable why it should do that at all then.
>>> 
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is always
>>> "up" and "right" is always "right".
>> 
>> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).
> 
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that because
the developer has gained this knowledge once and predefined the rotation matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my proposal
to get rid of touch inversion and flipping properties and code from the touch
screen drivers.

BR and thanks,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1584945

Hi,

Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>>
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> 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.
>>>
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>>
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>>
>>>> I hope that XServer is already using it for evdev devices...
>>>>
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>>
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>>
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on TSC2046).

best regards,
Petr

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Monday 20 February 2017 23:21:37 Petr Cvek wrote:
> Hi,
> 
> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller
> > <hns@goldelico.com> wrote:
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> 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.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device
> >>> from userspace? (In case DT data will not fully match current
> >>> HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be
> >>>> good starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel
> >>>> should just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is
> > always "up" and "right" is always "right".
> 
> Actually my Xorg calibration 3x3 matrix is fine with both axis
> inverted (on TSC2046).

Yes, 3x3 matrix which represent affine transformation can code inverted 
axis. This is IIRC what Xorg is doing.

But with information of min, max and current values plus resolution you 
cannot code information that axes are inverted (unless you misuse fact 
what is minimal and what maximal value). And this is what kernel 
provides for input device.

Affine transformation supported by Xorg is "stronger" as resolution 
provided by kernel.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> 
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> 
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> 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.
>>> 
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>> 
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>> 
>>>> I hope that XServer is already using it for evdev devices...
>>>> 
>>>> For whole implementation look at evtest program. That should be good
>>>> starting point for your userspace implementation.
>>>> 
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is not acceptable

I will monitor this to see if this becomes sorted out before submitting anything
new.

BR and thanks,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1585152

On Tuesday 21 February 2017 07:36:17 H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >> 
> >>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> >>> 
> >>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >>>> 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.
> >>> 
> >>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> >>> resolution from userspace for specified input device.
> >>> 
> >>> So this could be potentially used for calibrating input device from
> >>> userspace? (In case DT data will not fully match current HW)
> >>> 
> >>>> I hope that XServer is already using it for evdev devices...
> >>>> 
> >>>> For whole implementation look at evtest program. That should be good
> >>>> starting point for your userspace implementation.
> >>>> 
> >>>> While I'm watching this discussion... in my opinion kernel should
> >>>> just invert input axes (when needed)
> >> 
> >> It is questionable why it should do that at all then.
> > 
> > Because the task of the kernel is to provide unified view of the
> > hardware. Axis swapping and inversion is needed to that "up" is always
> > "up" and "right" is always "right".
> 
> Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
> screen and touching pixel (639,479) is always (639,479)?

Important is that there is no 1:1 mapping between input evdev device and
drm/fb output device. These are two independent devices. There is no
connection between screen and touch. So such presumption should not be
done in kernel. You can do that in userspace.

Lets take e.g. touchpad. It acts similarly as touchscreen input device
(both reports absolute positioned touch events), but touchpad is not
connected with screen. And from kernel point of view these devices are
both input and absolute positioned.

It looks like the whole problem is there that you wanted to do this
mapping for your hardware in kernel. And this is not what is kernel
doing or should do. Moreover I know people who are using integrated
touchscreen on laptop as (touch) input device for external monitor. And
in this configuration it does not make any sense to map touchscreen
input to pixels of integrated LCD touchscreen (as external monitor could
have different resolution as integrated LCD touchcreen).

> I think it is time to end this discussion.
> 
> It has show me how much a mess and half-baked area this is, which I did
> not expect. I read contradicting messages from different people:
> 
> * don't break user space because it is carved in stone
> * fix users space if you want to do it properly
> * scaling by +/-1 and shifting by full range is ok
> * scaling by ts-size/adc-range and shifting by adc_min is not ok
> * full numeric ADC resolution is required but subpixel coordinates is not acceptable
> 
> I will monitor this to see if this becomes sorted out before submitting anything
> new.
> 
> BR and thanks,
> Nikolaus

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hi,

[...]
> > Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0)
> > on the screen and touching pixel (639,479) is always (639,479)?
> 
> Important is that there is no 1:1 mapping between input evdev device
> and drm/fb output device. These are two independent devices. There is
> no connection between screen and touch. So such presumption should
> not be done in kernel. You can do that in userspace.
> 
But at least it can be told to userspace that these two devices are
connected. That information should be specified in devicetree because
it is not auto-detectable.

> Lets take e.g. touchpad. It acts similarly as touchscreen input device
> (both reports absolute positioned touch events), but touchpad is not
> connected with screen. And from kernel point of view these devices are
> both input and absolute positioned.
> 
> It looks like the whole problem is there that you wanted to do this
> mapping for your hardware in kernel. And this is not what is kernel
> doing or should do. Moreover I know people who are using integrated
> touchscreen on laptop as (touch) input device for external monitor.
> And in this configuration it does not make any sense to map
> touchscreen input to pixels of integrated LCD touchscreen (as
> external monitor could have different resolution as integrated LCD
> touchcreen).
>   
Interesting example. But then you also do not need flipping/rotation
because the angle between your screen and your absolute position device
is not fixed.

Regards,
Andreas

>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
> > Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
> > 
> > On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
> >> While I'm watching this discussion... in my opinion kernel should
> >> just invert input axes (when needed)
> 
> It is questionable why it should do that at all then.
> 
> User-Space can also easily do it. Either the driver should provide
> raw data only or if it does pre-processing (scaling by +/-1), why
> exclude pre-scaling by other factors?

Via resolution property which is in that EVIOCSABS ioctl() you specify 
value which represent unit per mm. So you cannot do full rescaling like 
via affine transformation. Specially you cannot swap axes or invert it.

As such thing is not supported by current kernel <--> userspace API it 
needs to be done in kernel.

Moreover I see that this is already handled by kernel's of_touchscreen.c 
code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

And... I'm not sure but I think that linux exports absolute input 
devices with coordinates where point (0,0) is mapped as left upper 
corner.

> >> 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).

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár <pali.rohar@gmail.com>:
> 
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár <pali.rohar@gmail.com>:
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>>>> While I'm watching this discussion... in my opinion kernel should
>>>> just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
>> 
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
> 
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
> 
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

> 
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

> 
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
> 
>>>> 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).

BR and thanks,
Nikolaus

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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.

I can't find this function defined anywhere but used in 101 LOC.
LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res

What is going on here?

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

Ok, if this is not set by a driver it is indeed a driver bug.

But we have to define it's value in DT because the tsc2007 does not know
anything about the panel dimensions.

IMHO something that should be done by generic of_touchscreen.c

If of_touchscreen would simply pass the touchscreen-size parameters
to input_abs_set_res() and the bindings would define it to be units/mm
it might have saved us all a lot of work and discussion.

> 
> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> 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).

BR and thanks,
Nikolaus

[toc] | [prev] | [next] | [standalone]

#1585132

Hi!

On Tuesday 21 February 2017 08:14:09 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.
> 
> I can't find this function defined anywhere but used in 101 LOC.
> LXR doesn't know it either: http://lxr.free-electrons.com/ident?i=input_abs_set_res
> 
> What is going on here?

It is inline function defined by preprocessor. This should help you:

git grep INPUT_GENERATE_ABS_ACCESSORS
git grep input_abs_set_res

> > 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.
> 
> Ok, if this is not set by a driver it is indeed a driver bug.

Zero value is special and means "driver does not know it". In case
driver really does not know it, then it is not a driver bug.

> But we have to define it's value in DT because the tsc2007 does not know
> anything about the panel dimensions.

Yes, driver itself does not know it and DT seems to be correct place.

> IMHO something that should be done by generic of_touchscreen.c

I agree. DT for specific hardware can pass these information into
touchscreen driver (which does not have to know these parameters) and it
exports it to userspace.

> If of_touchscreen would simply pass the touchscreen-size parameters
> to input_abs_set_res() and the bindings would define it to be units/mm
> it might have saved us all a lot of work and discussion.

Seem that nobody until now needed such thing and everybody is (probably)
using Xorg userspace with userspace calibration.

But it really make sense to set input_abs_set_res() from DT.

> > 
> > I hope that XServer is already using it for evdev devices...
> > 
> > For whole implementation look at evtest program. That should be good
> > starting point for your userspace implementation.
> > 
> > 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).
> 
> BR and thanks,
> Nikolaus
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

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

Hi all,

On Tue, Feb 21, 2017 at 9:47 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> But it really make sense to set input_abs_set_res() from DT.

And _not_ add the 1 or two lines of code that checks some DT variable,
and then fixes _everybody's_ userland?

That means those lines of code need to go into _every_ userland, which
makes maintenance sooo much harder. And the kernel knows about this
and doesn't care??

Weird...

Christ van Willegen

[toc] | [prev] | [next] | [standalone]

#1585216

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > They are "pixels" or the touch controller, i.e. native unites in which
> > device reports coordinates, as opposed to points per inch, or
> > millimeters, or whatever. These "pixels" do not have to have 1:1
> > relation to the LCD pixels; in fact they rarely do.
> 
> I wouldn't call this "pixels". Rather "ADC steps" or something.

Submit a patch.

> > Why? Nothing stops you from querying the device and figure out scaling.
> 
> What stops me is that I have no (and do not want to have) that level of control over
> user-space code.

Umm. Then perhaps you should not be submitting kernel patches.

> > And still, according to DT folks, device tree forms an ABI and thus we
> > are not to change it, even if it is easy.
> 
> I think this needs a more differentiated view.
> 
> In my view the names of the binding properties and what they influence form indeed
> an ABI. It should be stable and interpreted in the same way.
> 
> But it allows to load different firmware for different requirements. Like the user
> application ABI is stable but you can still load different software.

No. You can't expect people to konfigure kernel by modifying dts.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web