Hi Chase,
On Thu, 01 Sep 2011 11:26:32 -0700, Chase Douglas <chase.douglas@xxxxxxxxxxxxx> wrote:
> On 08/18/2011 12:47 AM, Dmitry Torokhov wrote:
> > On Thu, Aug 18, 2011 at 09:57:05AM +0800, JJ Ding wrote:
> >> +
> >> + i = (etd->fw_version > 0x020800 &&
> >> + etd->fw_version < 0x020900) ? 1 : 2;
> >> + *x_max = (etd->capabilities[1] - i) * 64;
> >> + *y_max = (etd->capabilities[2] - i) * 64;
> >> + *y_2ft_max = (*y_max - i) * 64 / 4;
> >
> > Hmm, we should have the same range for ST and MT data and scale MT data
> > if it has lower resolution to match ST.
>
> I saw this go by a while back and it made sense to me at the time.
> However, I've had some thoughts that give me pause.
>
> Seth Forshee has been working on getting a semi-mt driver for ALPS
> devices. The ALPS devices have an interesting mechanism for providing
> multitouch data, but it boils down to having a resolution of only 15
> values in the X axis and 11 in the Y axis (it looks possible to
> extrapolate and get double the resolution, but my point will remain).
>
> Let's take the X synaptics module as an example of the repercussions of
> in-kernel axis scaling. The X synaptics module translates two touch
> drags into scroll events. Synaptics will want to use the highest
> resolution axis for generating scroll events. If both the MT and ST axes
> have the same resolution, it might pick the MT axes for scrolling. On
> ALPS devices with in-kernel axis scaling that would be a bad choice.
I don't know about the ALPS devices, but since we already report
ABS_MT_POSITION_{X,Y} with elantech v2, we have to do the scaling in
kernel anyway to adhere to multitouch protocol. So I would say it is
still more appropriate to have the same resolution for ST and MT with
respect to elantech v2. Maybe ALPS should be considered an exception to this?
> It's trivial to project the MT and ST axes onto each other in userspace.
> I suggest we report the real range and resolution of ST and MT axes
> independently.
> -- Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
