From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Ping Cheng <pinglinux@gmail.com>
Cc: Henrik Rydberg <rydberg@euromail.se>, linux-input@vger.kernel.org
Subject: Re: [PATCH] input : wacom - report resolution for ABS_MT events
Date: Fri, 28 Jan 2011 16:05:39 -0800 [thread overview]
Message-ID: <20110129000539.GL6252@core.coreip.homeip.net> (raw)
In-Reply-To: <AANLkTikUmajiTDxNzOKNznevdutnefO7CgTrBg8=rRCu@mail.gmail.com>
On Fri, Jan 28, 2011 at 01:57:17PM -0800, Ping Cheng wrote:
> On Fri, Jan 28, 2011 at 12:54 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >> >> > so I believe
> >> >> > min, max and resultion should be reported on ABS_X, Y, X, etc, or, if
> >> >> > you want to have this data in ABS_MT_POSITION, it should be trhe same.
> >> >>
> >> >> max/min is different from resolution. We can scale max/min since they
> >> >> are logical data. But we can not change the device's physical size.
> >> >> That's the root cause of the "stubborn" nature of resolution.
> >> >
> >> > This is the same device so it should have the same physical dimensions,
> >> > right?
> >>
> >> No, pen and touch use different chips. They can have different sizes.
> >
> > It does not matter how many chips you have inside. What matters whether
> > they share a working surface or not. If working surface is the same (and
> > consequentially you have single input_dev structure) then dimensions are
> > the same.
>
> They do not always share the exact same surface. Most of the devices
> do have the same working surface. But not all of them although the
> differences are normally small. To represent a finger touch, it may
> not be too big a deal. But, making the assumption that they are the
> same size doesn't sound right.
>
> Do we ignore that small imprecision?
I think we should consider these cases as having roughly the same
dimensions of working surfaces. Because if we do what you are proposing
the next thing we'll see an MT device that can report several tools
simultaneously and your scheme breaks apart.
Devices with surface characteristics so different that they can't be
handled well by scaling to common denominator should probably be
presented as 2 independent logical devices.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2011-01-29 0:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-28 1:47 [PATCH] input : wacom - report resolution for ABS_MT events Ping Cheng
2011-01-28 17:30 ` Henrik Rydberg
2011-01-28 18:23 ` Ping Cheng
2011-01-28 18:46 ` Dmitry Torokhov
2011-01-28 19:01 ` Ping Cheng
2011-01-28 19:37 ` Dmitry Torokhov
2011-01-28 20:08 ` Ping Cheng
2011-01-28 20:54 ` Dmitry Torokhov
2011-01-28 21:57 ` Ping Cheng
2011-01-29 0:05 ` Dmitry Torokhov [this message]
2011-01-29 6:19 ` Ping Cheng
2011-01-28 19:12 ` Henrik Rydberg
2011-01-28 20:08 ` Ping Cheng
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=20110129000539.GL6252@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=pinglinux@gmail.com \
--cc=rydberg@euromail.se \
/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).