linux-kernel - Re: v4.1 to v4.7: regression in tsc2005 driver

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]

Date:	Fri, 22 Jul 2016 10:12:19 +1000
From:	Peter Hutterer <peter.hutterer@...-t.net>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Michael Welling <mwelling@...e.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, sre@...nel.org, aaro.koskinen@....fi,
	ivo.g.dimitrov.75@...il.com, patrikbachan@...il.com,
	serge@...lyn.com
Subject: Re: v4.1 to v4.7: regression in tsc2005 driver

On Thu, Jul 21, 2016 at 11:04:29AM +0200, Pali Rohár wrote:
> On Thursday 21 July 2016 10:54:21 Pavel Machek wrote:
> > On Thu 2016-07-21 16:42:41, Peter Hutterer wrote:
> > > On Thu, Jul 21, 2016 at 08:32:34AM +0200, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > > > In the mean time you can adjust the name or use XID instead.
> > > > > 
> > > > > X has partially fixed this a few years ago. All input drivers (that
> > > > > matter) export a Device Node property that sets the device node for each
> > > > > device.
> > > > > 
> > > > >  $ xinput list-props "SynPS/2 Synaptics TouchPad" | grep "Device Node"
> > > > >         Device Node (261):      "/dev/input/event4"
> > > > > 
> > > > > Based on that you can get the udev device and work your way into any of the
> > > > > sysfs tree. Or do whatever else you want.
> > > > > 
> > > > > But other than that there isn't anything in X to fix. xinput is primarily a
> > > > > debugging tool and it does name resolution for convenience. But it's not a
> > > > > tool for complex configurations. It does exactly what it needs to do, if you
> > > > > need something that's more complicated and relies on information not
> > > > > available to the X device itself then you'll need to write a custom tool
> > > > > that does what you need. sorry.
> > > > 
> > > > Ok.. so out of the box, touchscreen is "upside down" and miscalibrated
> > > > on n900. So I need to run
> > > > 
> > > > xinput --set-prop --type=float 8 115  1.10 0.00 -0.05  0.00 1.18 -0.10 0.00 0.00 1.00
> > > > xinput --set-prop --type=int 8 249 0 1
> > > > 
> > > > (or equivalent with names) so that I can use the touchscreen. (And
> > > > that's quite important -- X is somehow unusable without pointing
> > > > device).
> > > > 
> > > > If xinput is not the right solution, what is the right solution?
> > > 
> > > if it's reliably miscalibrated (i.e. the numbers don't change), use an
> > > xorg.conf snippet. If it needs some run-time changes add the hooks
> > > to
> > 
> > Does not change and is needed for all the N900's.
> > 
> > Well. I guess xorg.conf snippet will do the trick, but that's hardly
> > better.
> > 
> > Should x.org have internal database saying "Nokia N900 with tsc2005
> > touchscreen means this calibration"?
> > 
> > Should we have calibration info in the device tree, with kernel
> > passing it to the x?
> > 
> > Should kernel somehow do the calibration itself?
> 
> From my memory how this problem is solved on Maemo 5:
> 
> There is XML snippet of HAL file which contains xorg properties for
> input driver. Xorg server loads from HAL xorg settings and somehow
> propagate them. That file is generated either from default system data
> (those comes from DEB package) or from user config file (that is
> generated from Settings application) or from CAL partition (NAND
> partition which contains device/product specific calibration data).
> 
> Because it is read also from CAL, I need to say those data does not have
> to be same for all N900 devices.
> 
> And because there is Settings application which can re-calibrate
> touchscreen, those data are not even static.
> 
> Now HAL is deprecated, but I suspect that xorg.conf.d/ directory or UDEV
> can be used in same way to propagate device specific settings for
> touchscreen device...

yes, xorg.conf.d snippets replaced HAL configuration, with pretty much the
same functionality. Using udev is not generally recommended.

Cheers,
   Peter

> So... if we decide that it is good idea to put calibration data (either
> to kernel driver/N900 DTS or xorg project), first we need to somehow
> check and verify that those default calibration data are good for most
> (or all) N900. Or check on more N900 how differs data in CAL partition
> (maybe they are really static??).
> 
> -- 
> Pali Rohár
> pali.rohar@...il.com