lkml.org 
[lkml]   [2011]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/6] Input: elantech - use firmware provided x, y ranges
    Hi,

    On Wed, Sep 7, 2011 at 3:29 AM, Chase Douglas
    <chase.douglas@canonical.com> wrote:
    >
    > On 09/06/2011 11:20 AM, Dmitry Torokhov wrote:
    > > On Tue, Sep 06, 2011 at 11:05:11AM -0700, Chase Douglas wrote:
    > >> On 09/06/2011 10:36 AM, Dmitry Torokhov wrote:
    > >>> On Tue, Sep 06, 2011 at 10:03:05AM -0700, Chase Douglas wrote:
    > >>>> On 09/04/2011 08:22 PM, JJ Ding wrote:
    > >>>>> Hi Chase,
    > >>>>>
    > >>>>> On Thu, 01 Sep 2011 11:26:32 -0700, Chase Douglas <chase.douglas@canonical.com> 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?
    > >>>>
    > >>>> The multitouch protocol doesn't require scaling of axes to match, at
    > >>>> least not according to the protocol documentation.
    > >>>>
    > >>>> I see that the current code scales the coordinates for v2, but it's only
    > >>>> half-resolution. That's not a huge deal since the resolution of modern
    > >>>> touchpads is very high. We could leave it scaled to not break abi, if
    > >>>> that was a concern. However, with new devices it makes sense to state
    > >>>> the ranges in terms of what the device actually supports. Otherwise,
    > >>>> we're just masking out useful data that userspace could be using.
    > >>>>
    > >>>
    > >>> I disagree. I believe that ST and MT ranges reported for the same
    > >>> working surface should match, especially since many devices derive ST
    > >>> data from MT.
    > >>>
    > >>> As far as devices that have ranges 0-15 in MT mode - I am not sure how
    > >>> useful such MT steam anyway and if we are better of just ignore them
    > >>> (maybe just use the data to report number of fingers on the surface but
    > >>> otherwise use standard ST protocol).
    > >>
    > >> The MT data could still be useful for pinch to zoom or potentially
    > >> rotate (though most low res devices probably are only semi-mt). I don't
    > >> want to forsake pinch to zoom just because we can't pass on the
    > >> resolution of MT data properly.
    > >
    > > How would userspace know that MT data should only be used for gestures
    > > but nothign else? By examining range? What is the "too small range"
    > > then? It would be different for different devices. I do not want
    > > userspace portions of the drivers to turn into unmanageble collection of
    > > quirks.
    >
    > I wasn't suggesting that it have a big switch that enables or disables
    > gestures. I just want userspace to be able to figure out whether ST or
    > MT data would be better for a given task. If the range of the ST and MT
    > axes could provide this data, then it makes sense to do so. The test
    > wouldn't be like "is MT range big enough", it would be "is MT range
    > better than ST or vice versa".
    >
    > However, Henrik pointed out that some devices report ranges that aren't
    > representative of how accurate or precise they really are. That
    > invalidates this approach.
    >
    > > Some hardware is just hopeless... And pinch to zoom is cute but hardly
    > > most used function on a laptop (as opposed to phone/tablet), I'd just
    > > leave it be.
    >
    > Just because a piece of hardware is imprecise does not mean it is
    > useless for gestures. Sure, it may not work that great for precision
    > zooming, but it would be good enough for threshold matching. The Unity
    > window manager uses these thresholds to fire actions like spread (or
    > "expose" in OS X terms).
    >
    > -- Chase

    As far as I can tell, when the pad reports exactly 2 fingers, it
    reports them both with half the resolution with which it would report
    a single finger (in the 1 finger or 3 fingers cases).

    It sounded like Chase was recommending to report "ST" at full
    resolution and "MT" at half resolution. Thus, if there is 1 finger,
    we would throw away 1 bit for the MT report. If there were 2 fingers,
    we would inflate the ST reported finger by one bit.

    I prefer the original behavior of this patch, which just always
    reports ST and MT using the ST scale.

    -Daniel
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-09-07 04:37    [W:0.034 / U:59.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site