linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hutterer <peter.hutterer@who-t.net>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Michael Welling <mwelling@ieee.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org, sre@kernel.org,
	aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com,
	patrikbachan@gmail.com, serge@hallyn.com
Subject: Re: v4.1 to v4.7: regression in tsc2005 driver
Date: Fri, 22 Jul 2016 10:12:19 +1000	[thread overview]
Message-ID: <20160722001219.GB11426@jelly> (raw)
In-Reply-To: <20160721090429.GP29844@pali>

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

  reply	other threads:[~2016-07-22  0:12 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-17 17:52 v4.1 to v4.7: regression in tsc2005 driver Pavel Machek
2016-07-17 18:24 ` Michael Welling
2016-07-17 18:42   ` Pavel Machek
2016-07-17 18:51     ` Michael Welling
2016-07-17 20:03       ` Pavel Machek
2016-07-17 22:56         ` Michael Welling
2016-07-19 23:51           ` Dmitry Torokhov
2016-07-20  0:39             ` Michael Welling
2016-07-20  0:53               ` Dmitry Torokhov
2016-07-20  1:34                 ` Michael Welling
2016-07-20  1:44                   ` Dmitry Torokhov
2016-07-20  2:09                     ` Michael Welling
2016-07-20  3:49                     ` [PATCH] Input: tsc200x - Report proper input_dev name Michael Welling
2016-07-20  6:31                       ` Pavel Machek
2016-07-20  6:50                         ` Michael Welling
2016-07-20  6:54                           ` Pavel Machek
2016-07-20  7:06                             ` Michael Welling
2016-07-20  7:48                               ` Pavel Machek
2016-07-20 16:45                             ` Dmitry Torokhov
2016-07-20 16:56                               ` Pali Rohár
2016-07-20 17:04                                 ` Dmitry Torokhov
2016-07-20 17:14                                   ` Dmitry Torokhov
2016-07-20 20:25                                     ` Pavel Machek
2016-07-20 20:37                                     ` Pali Rohár
2016-07-20 16:33                 ` v4.1 to v4.7: regression in tsc2005 driver Pali Rohár
2016-07-20  1:26               ` Aaro Koskinen
2016-07-20  2:18                 ` Michael Welling
2016-07-20  6:25             ` Pavel Machek
2016-07-20 16:23               ` Dmitry Torokhov
2016-07-20 20:22                 ` Pavel Machek
2016-07-20 21:47                 ` Peter Hutterer
2016-07-20 22:20                   ` Dmitry Torokhov
2016-07-20 22:55                     ` Peter Hutterer
2016-07-21  6:32                   ` Pavel Machek
2016-07-21  6:42                     ` Peter Hutterer
2016-07-21  8:54                       ` Pavel Machek
2016-07-21  9:04                         ` Pali Rohár
2016-07-22  0:12                           ` Peter Hutterer [this message]
2016-07-25 14:59                             ` Pali Rohár
2016-07-31 21:28                               ` Peter Hutterer
2016-07-22  0:10                         ` Peter Hutterer
2016-07-22  0:57                           ` Dmitry Torokhov
2016-07-25 14:56                     ` Pali Rohár
2016-07-28 19:33                       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160722001219.GB11426@jelly \
    --to=peter.hutterer@who-t.net \
    --cc=aaro.koskinen@iki.fi \
    --cc=dmitry.torokhov@gmail.com \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mwelling@ieee.org \
    --cc=pali.rohar@gmail.com \
    --cc=patrikbachan@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=serge@hallyn.com \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).