linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Éric Piel" <E.A.B.Piel@tudelft.nl>
Cc: JJ Ding <jj_ding@emc.com.tw>,
	linux-input@vger.kernel.org, Tom Lin <tom_lin@emc.com.tw>,
	Aaron Huang <aaron_huang@emc.com.tw>,
	Daniel Kurtz <djkurtz@chromium.org>
Subject: Re: [PATCH] Input: elantech - correct x, y value range for v2 hardware
Date: Wed, 17 Aug 2011 09:37:46 -0700	[thread overview]
Message-ID: <20110817163746.GC4877@core.coreip.homeip.net> (raw)
In-Reply-To: <4E4B8FB3.9090100@tudelft.nl>

On Wed, Aug 17, 2011 at 11:53:55AM +0200, Éric Piel wrote:
> Op 17-08-11 08:43, Dmitry Torokhov schreef:
> >Hi JJ,
> >
> >>As far as I know, this doesn't fix a bug. I just want to make sure the
> >>driver and what the firmware sends are consistent.
> >
> >As Éric mentioned, simply extending range to 12 bits is dangerous
> >because we might cause overflows. Blindly increasing ETP_YMAX_V2 is not
> >a good idea either as userspace would expect much larger device and
> >reports would only cover fraction of its surface. We need to separate
> >ETP_YMAX_V2 as absolute maximum from reported coordinates range, like it
> >is done in synaptics driver.
> Hi Dmitry,
> Concerning this point, I was wondering if it'd be ok to only send
> negative values? Such as min/max are between -768 and 0. So that, if
> the hardware actually has a bigger resolution, it can go down to
> -4095 without any overflow?

Theoretically it should be possible, at least nothing in evdev protocol
says that absolute coordinates shoudl be positive. It is certainly not
true for joystick-like devvices. But I am concerned about users (as
in applications/drivers) getting negative coordinates for
touchpad/touchscreen like devices. I believe first reaction is to expect
non-negative values.

> It sounds the simplest way to report the
> coordinate for a device which has an opposite axis. Or is it safer
> to stay in the positive numbers, with min/max between 3328 and 4095,
> and in case of bigger resolution the values go down to 0?

I think this is the best way. EVIOCGABS gives the "window" into the
expected range of coordinates emitted by the device, so as long as we
keep the scale (i.e. not reporting min/max as 0-4096 while actual
coordinates go only 0-768) it should work fine.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2011-08-17 16:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-15  3:51 [PATCH] Input: elantech - correct x, y value range for v2 hardware JJ Ding
2011-08-15  5:25 ` Daniel Kurtz
2011-08-15 12:45 ` Éric Piel
2011-08-16  1:12   ` JJ Ding
2011-08-16 11:11 ` JJ Ding
2011-08-16 21:50   ` Éric Piel
2011-08-17  1:28     ` JJ Ding
2011-08-17  6:43       ` Dmitry Torokhov
2011-08-17  9:53         ` Éric Piel
2011-08-17 16:37           ` Dmitry Torokhov [this message]

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=20110817163746.GC4877@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=E.A.B.Piel@tudelft.nl \
    --cc=aaron_huang@emc.com.tw \
    --cc=djkurtz@chromium.org \
    --cc=jj_ding@emc.com.tw \
    --cc=linux-input@vger.kernel.org \
    --cc=tom_lin@emc.com.tw \
    /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).