Grail

Merge lp://staging/~oif-team/grail/trunk.v1.0.13 into lp://staging/grail

  1. trunk.v1.0.13
  2. Merge into trunk
Proposed by Henrik Rydberg
Status: Superseded
Proposed branch: lp://staging/~oif-team/grail/trunk.v1.0.13
Merge into: lp://staging/grail
Diff against target: 349 lines (+160/-9)
7 files modified
configure.ac (+1/-1)
include/grail-touch.h (+1/-0)
src/gestures-tapping.c (+1/-1)
src/grail-gestures.c (+27/-4)
src/grail-gestures.h (+2/-1)
src/touch-caps.c (+37/-0)
src/touch-dev.c (+91/-2)
To merge this branch: bzr merge lp://staging/~oif-team/grail/trunk.v1.0.13
Reviewer Review Type Date Requested Status
Chase Douglas (community) Needs Fixing
Review via email: mp+34963@code.staging.launchpad.net

This proposal supersedes a proposal from 2010-09-08.

This proposal has been superseded by a proposal from 2010-09-09.

Description of the change

The changes needed to support non-MT devices through the utouch stack.

To post a comment you must log in.
Revision history for this message
Chase Douglas (chasedouglas) wrote : Posted in a previous version of this proposal

Commit 79 makes sense, so no issues there.

However, I'm not sure what to do about commit 80. I think it looks good and it probably can introduce some interesting support for synaptics trackpads. However, it's also really late in the cycle to be adding this much new code.

I know it would be a bit of extra work, but can we keep commit 80 in a separate branch for now and not package it up for Maverick? By strict definition it is clearly out of scope at this point in the development cycle, and it likely won't actually add any new features since synaptics will be used for most of these devices anyways. However, I worry that there could be regressions in the single-touch touchscreen use case.

I guess the most appropriate review state for this is resubmit to include only commit 79. If you aren't meaning to push this into maverick, perhaps this could be merged as 1.1.0 and we would keep maverick on the 1.0.x series that would not include commit 80?

review: Needs Resubmitting
Revision history for this message
Henrik Rydberg (rydberg) wrote : Posted in a previous version of this proposal

Well, I was thinking maverick for this, since there has already been bug reports about it. I see your point clearly, but I also see the conflict between the normal maverick procedure and the interests to make gestures work for as broad an audience as possible.

Revision history for this message
Henrik Rydberg (rydberg) wrote : Posted in a previous version of this proposal

Code now replaces the "has_mtdata" with "is_supported" logic, and lets some non-MT devices
through. That should take care of the risk of regression for other devices.

Revision history for this message
Chase Douglas (chasedouglas) wrote : Posted in a previous version of this proposal

It sounds like we're going to try to push this into maverick. I'm going to do some testing on it to be sure it doesn't kill my cat :).

Revision history for this message
Duncan McGreggor (oubiwann) wrote : Posted in a previous version of this proposal

Yeah, we try to support animal-friendly products. Thanks for keeping that in mind, Chase.

Revision history for this message
Chase Douglas (chasedouglas) wrote : Posted in a previous version of this proposal

Well, it didn't kill my cat, but it did kill my single touch cursor motion.

In lines 148, 153, and 158 in the big diff below, the return value should be 0 instead of 1 (according to Henrik). This fixed my issues.

review: Needs Fixing
Revision history for this message
Henrik Rydberg (rydberg) wrote :

Pacthes for two problems have been folded into the originals: 1) set minor when not available from the device, and 2) let grail-touch be transparent when driving a non-mt device. The latter caused the pointer position in the legacy emulation in grail-gesture to not be updated.

Revision history for this message
Chase Douglas (chasedouglas) wrote :

The synaptics functionality seems to work right for me now. However, I noticed another issue: four finger pinches are often recognized as taps. I believe the issue lies in the fact that the motion of the focus point inhibits a tap, but a pinch may not move the focus point. I have a proposed patch to fix this, and I'd like to see a fix end up in 1.0.13.

review: Needs Fixing
lp://staging/~oif-team/grail/trunk.v1.0.13 updated
79. By Henrik Rydberg

Make sure contact area is always defined

Some devices do not always send touch_minor after touch_major
has been set. According to the MT protocol, this case should
be treated as if minor is equal to major. This patch makes sure
touch_minor is never zero when touch_major is set.

80. By Henrik Rydberg

Support legacy devices

Simulate MT touch events for legacy devices that support the
DOUBLETAP, TRIPLETAP and QUADTAP events. This allows multi-finger
tap and drag gestures to be emitted, providing a basic level of
MT functionality for legacy devices.

81. By Henrik Rydberg

Discard tapping even when there are zero events between dow
n and up

The current logic assumes there will be at least one frame with
between touch up and touch down or the tap will not be properly
timed out. Fixed with this patch.

Reported-by: Chase Douglas <email address hidden>

82. By Henrik Rydberg

Cancel tapping also on zoom events

The current code cancels tapping when dragging is active. This
patch adds zooming to the set, to inhibit tapping also when a
perfect zoom without dragging is performed.

Reported-by: Chase Douglas <email address hidden>

83. By Henrik Rydberg

Only emit abs events when motion is active

This bug was hidden behind the motion inhibit during tapping,
but resurfaced when tapping from resting finger was introduced.
With this patch, pointer movement is inhibited also when lifting
fingers from the surface.

Ideally, tapping should be treated as a transient event, which would
allow zero pointer event also _before_ the tap, but presently unity
seems to depend on the initial pointer movement as a touch-down event.

84. By Henrik Rydberg

Inhibit taps immediately after a finger is lifted

The intentional tap starts with a finger in the air. This patch
treats the sequence up-down-up as unintentional, unless performed
with a single finger. Fixes the problem with accidental taps during
multi-finger gestures.

85. By Henrik Rydberg

Allow slow tapping

For the benefit of hardware that cannot accurately meet the desirable
response times, allow for tapping times up to 300 ms.

86. By Henrik Rydberg

grail v1.0.13

Unmerged revisions

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches

to all changes: