lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <53529A9D-E2AA-405C-A12A-716984D2CDBC@goldelico.com>
Date:   Mon, 20 Feb 2017 21:35:18 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Pali Rohár <pali.rohar@...il.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Michael Welling <mwelling@...e.org>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Igor Grinberg <grinberg@...pulab.co.il>,
        "Andrew F. Davis" <afd@...com>, Mark Brown <broonie@...nel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Alexander Stein <alexander.stein@...tec-electronic.com>,
        Eric Engestrom <eric@...estrom.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Petr Cvek <petr.cvek@....cz>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Nick Dyer <nick@...anahar.org>,
        Siebren Vroegindeweij <siebren.vroegindeweij@...mail.com>,
        Michel Verlaan <michel.verl@...il.com>,
        linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        letux-kernel@...nphoenux.org, linux-iio@...r.kernel.org,
        kernel@...a-handheld.com, Aaro Koskinen <aaro.koskinen@...ia.com>,
        Pavel Machek <pavel@....cz>,
        Andrey Gelman <andrey.gelman@...pulab.co.il>,
        Haibo Chen <haibo.chen@...escale.com>
Subject: Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Pali,

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

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

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

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

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


Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ