XInput single-touch events aren't always filtered

Bug #637106 reported by Chase Douglas
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Grail
Fix Released
Medium
Unassigned
utouch-grail (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

When performing a gesture, single touch events are not always filtered out. This appears to be because one of the touches has moved far enough to cause a single touch event before all touches have hit the screen and force recognition for gestures.

Related branches

Changed in utouch-grail:
status: New → Triaged
Changed in utouch-grail (Ubuntu):
status: New → Triaged
Changed in utouch-grail:
importance: Undecided → Medium
Changed in utouch-grail (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Chase Douglas (chasedouglas) wrote :

Right now, when grail receives a complete touch frame it either passes through the touch data or it sends a gesture event. While a gesture is still being recognized, the touch data is sent.

The issue may be resolved by implicitly subscribing to single-touch gestures inside grail. When a single-touch gesture is recognized but not subscribed by any clients, the gesture is then transformed into traditional evdev input events for processing by X.

There are two issues with this approach:

1. This will add a small delay to all single-touch movements, even for non gesture aware clients, while they are still being recognized. Although that sounds bad, this delay is actually the entire point of this issue, and I think it's inevitable. We need to ensure we tune the parameters properly to make this reasonable.

2. The change would require a substantial reworking of the input event pass-through mechanism in grail. This could be a cause for regressions, and we are very late into the Maverick cycle.

Revision history for this message
Vincent Gerris (vgerris) wrote :

I might have a problem related to this issue.
I have a mulittouch screen, which has no trouble in X when the Multitouch X and Y coordinates are not enabled in the driver: a touch gives an instant move of the cursor to that place.
When only X or Y is enabled all still goes well, but when X and Y are send (so mtdev sees them) my cursor does not respond to a single touch properly sometimes.

I hope this is understandable, I am just a user, not a kernel developer :).
Is there a way to fix this?

Revision history for this message
Duncan McGreggor (oubiwann) wrote :

Hey Vincent, thanks for your comment. I had similar issues to this at one point that were addressed by calibrating my device. But I have an important question for you first: What device do you have?

Once we get that info, we can start the conversation in the right direction (possibly creating a new bug).

Thanks!

Revision history for this message
MacRules (macrules) wrote :

Hi Duncan,

My device is identified as a GeneralTouch Win7 TwoFinger device.
The hardware ID is 0dfc:0001 . I am using a driver developed by Stephane Chatty from enac.fr .

I am running Ubuntu 10.10 where I have this issue, but I have also a 10.04 install with the 2.3.35 kernel from 10.10 running with the same driver, and I do not have the issue there.

About calibration: the pointer is very accurate compared to where I put my finger, so I have not had the need to calibrate it yet.
Could you explain how I should do that?
I'd be happy to try it out and post back.
I also had a reply from Chase Douglas for some more device info.

Just tell me what you need to know and I'd be happy to help to fix this :).

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

Hi Vincent,

Can you describe in more detail what occurs when your cursor does not properly respond? We need all the detail we can get since this is a new device you are working with.

Thanks!

Revision history for this message
Vincent Gerris (vgerris) wrote :

Hi Chase,

What happens is, that if I touch the screen, the cursor does not move from the previous position sometimes.
For example when I touch 6 different places on the screen, the cursor would follow 3 times and the other 3 not (it would remain at the 3rd position).

Things that effect this: when I press harder on the screen, sometimes the cursor does appear on that spot.
When I touch and then drag, the cursor always follows.

Please not that this does not happen on Ubuntu 10.04, so this is related to X/evdev.
Besides all this, I have PyMT om my device.
When that is configured to use the mtdev driver, the demo works fine for two fingers, meaning while X has trouble following, PyMT shows no trouble.
That would make me think it is not a driver issue, but that is just my point of view :).

The other thing is, when I use the driver that does not send the mtY and mtX (both) then this issue also does not occur.
So linking all that, I would think that when a touch is performed, some mechanism checks if both mtX and mtY are there and if so, tries to determine something about a simple touch that couses a different interpretaton to X then expected.

Hope this helps :).

Revision history for this message
MacRules (macrules) wrote :

Hi folks,

anything new on the matter?
Please let me know if you need some more info.
I thought all this would be in 10.10 but it seems it will be 11.04 now.
Can we try to make it in that release :)?

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

Hi MacRules,

Yes, this is targeted for Natty. The change to make it work 100% correctly in 10.10 would require a large overhaul of parts of utouch-grail, so it's probably best to think of this as an errata for the current release. Future revisions in this area will also be XInput dependent, so the requisite change to 10.10 would not be forward compatible either.

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

Actually, it seems people are talking about different problems in this thread. First of all, if a single finger is put down to move some time before a second finger, the single-finger move is intentional so we end up in a grey zone where latency and finger grouping have to be balanced. In particular the timings in conjunction with finger release could possibly change to remedy this. Secondly, there is no longer any need to subscribe to single-touch gestures; the emulated events are suppressed on the same footing anyways.

Revision history for this message
MacRules (macrules) wrote :

Thank you for your reply.
I posted here because I consider the current behaviour for my device in 10.10 a bug, since the cursor does not repond to a single touch on the screen with one finger.
I am looking for a workable multitouch solution, hoping to find it in 10.10.

Reading these comments I guess I better update to Natty to start testing multitouch stuff on my tablet.
Is that correct and if so, where do I post bugs?

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

Ahh, yeah, I forgot that this bug report became two issues in one. I suggest we create a new bug report for what Vincent Gerris sees, as I don't think it's the same issue as I reported.

MacRules, if your symptoms are different than what I reported in the bug summary, please make a new bug as well or follow Vincent if he does.

Thanks

Revision history for this message
MacRules (macrules) wrote :

Hi people,

Sorry for the confusion, it seems I have 2 launchpad accounts. Vincent is also me :).

Can anyone please point out where I should file this issue I am having?
Just file a new bug for this package with the same description.
At first I thought my issue had the same cause as the one Chase Douglas had.

If that is definitely not the case, I gladly upgrade to 11.04 and start from there.

Revision history for this message
Duncan McGreggor (oubiwann) wrote :

Chase, I'm a little unclear on what the two distinct issues are: could you explicitly state them? And indicate which issue this ticket should be addressed to? We can then create a second ticket for the other one.

At least partially, it sounds to me that the issue that MacRules/Vincent is having may be driver/firmware-related? I haven't seen this problem on supported hardware list at all (since I calibrated my N-trig-based Lenovo); have you? Every touch I make one the screen with one finger results in a movement of the cursor to the new touch point.

However, Chase you mentioned a fix that is targeted for Natty. Was that in response to this part of MacRules/Vincent's comment:

"The other thing is, when I use the driver that does not send the mtY and mtX (both) then this issue also does not occur.
So linking all that, I would think that when a touch is performed, some mechanism checks if both mtX and mtY are there and if so, tries to determine something about a simple touch that couses a different interpretaton to X then expected."

Chase, to be explicit:
 * do you think that MacRules/Vincent's issue is grail-related?
 * if there are two issues at play in his comment, is one of them appropriately associated with this bug?
 * if so, which one?
 * if one or more of his issues aren't grail-related, where should they be filed?
 * are there files or any command output that

MacRules/Vincent: on the calibration side of things, my N-trig device was also consistent with the placement of the cursor (position-wise). However, many (most) times it would simply not interpret a touch unless I pressed very hard. Calibrating with our N-trig calibration tool (written by Rafi Rubin) fixed all of that for me. Does your "GeneralTouch Win7 TwoFinger device" have a calibration tool for Linux? If they only have a Windows calibration tool and you have a Windows partition, I'd highly recommend running it. If there's even a chance that it could fix this issue, it's worth pursing.

If after calibration you are still experiencing the issue, and it's a problem with grail, once grail is fixed, you'll be able to test it out simply by adding the appropriate PPA to your apt sources. No need to upgrade your whole system (which isn't actually an option right now, since the debian sync doesn't finish until December... though it should be starting nowish).

To be clear, though: our target for Maverick was publicly announced to a very limited initial set of 4-touch hardware. This list of devices has already doubled in size (including several 10+ touch devices), so we're making great progress. For supported devices, uTouch is most definitely working.

Let's see if we can get your hardware supported as well :-) (Henrik and Chase have been working to get other 2-touch devices supported).

Revision history for this message
Chase Douglas (chasedouglas) wrote : Re: [Bug 637106] Re: XInput single-touch events aren't always filtered
Download full text (3.8 KiB)

On Thu, 2010-10-14 at 16:13 +0000, Duncan McGreggor wrote:
> Chase, I'm a little unclear on what the two distinct issues are: could
> you explicitly state them? And indicate which issue this ticket should
> be addressed to? We can then create a second ticket for the other one.

I initially reported this issue, and the issue is best summarized in the
bug summary at the top and in comment #1 providing more detail.

Vincent's issue is best summarized in comment #6.

> At least partially, it sounds to me that the issue that MacRules/Vincent
> is having may be driver/firmware-related? I haven't seen this problem on
> supported hardware list at all (since I calibrated my N-trig-based
> Lenovo); have you? Every touch I make one the screen with one finger
> results in a movement of the cursor to the new touch point.

Correct, I think Vincent's issue may be driver related.

> However, Chase you mentioned a fix that is targeted for Natty. Was that
> in response to this part of MacRules/Vincent's comment:

That's in response to Vincent's comment #7, but I didn't realize he was
commenting on his issue outlined in comment #6. I was answering his
question in comment #7 as though it were about the original issue I
filed the bug for.

> "The other thing is, when I use the driver that does not send the mtY and mtX (both) then this issue also does not occur.
> So linking all that, I would think that when a touch is performed, some mechanism checks if both mtX and mtY are there and if so, tries to determine something about a simple touch that couses a different interpretaton to X then expected."
>
> Chase, to be explicit:
> * do you think that MacRules/Vincent's issue is grail-related?
> * if there are two issues at play in his comment, is one of them appropriately associated with this bug?
> * if so, which one?
> * if one or more of his issues aren't grail-related, where should they be filed?
> * are there files or any command output that

I think it's most likely driver related. I don't think it's related to
my initial bug report in any way.

I would file the bug against the utouch project since that's where we
seem to dump bugs that aren't obvious as to which package they truly
belong.

> MacRules/Vincent: on the calibration side of things, my N-trig device
> was also consistent with the placement of the cursor (position-wise).
> However, many (most) times it would simply not interpret a touch unless
> I pressed very hard. Calibrating with our N-trig calibration tool
> (written by Rafi Rubin) fixed all of that for me. Does your
> "GeneralTouch Win7 TwoFinger device" have a calibration tool for Linux?
> If they only have a Windows calibration tool and you have a Windows
> partition, I'd highly recommend running it. If there's even a chance
> that it could fix this issue, it's worth pursing.
>
> If after calibration you are still experiencing the issue, and it's a
> problem with grail, once grail is fixed, you'll be able to test it out
> simply by adding the appropriate PPA to your apt sources. No need to
> upgrade your whole system (which isn't actually an option right now,
> since the debian sync doesn't finish until December... though it should
> b...

Read more...

Revision history for this message
MacRules (macrules) wrote :

hi,

Since I did not experience any wrong positions, I never thought of calibrating.
The reason I called it a evdev-grail issue, is because in 10.10 in the
I mailed Stephane to ask how to calibrate and will post if I know more.
I will stay on 10.10 and it would be great if this device is supported!
Thank you

Revision history for this message
Duncan McGreggor (oubiwann) wrote :

I've created a ticket for Vincent/MacRules' issue here: bug #662621.

Revision history for this message
MacRules (macrules) wrote :

As I posted in the new bug, I am not sure about how to calibrate.
I will post my information in the bug, thank you for creating it!

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

This has been fixed as part of utouch-grail 1.0.20.

Changed in utouch-grail:
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package utouch-grail - 1.0.20-0ubuntu1

---------------
utouch-grail (1.0.20-0ubuntu1) natty; urgency=low

  [ Henrik Rydberg ]
  * New upstream release.
  * Fixes bug LP: #637106
 -- Chase Douglas <email address hidden> Wed, 09 Mar 2011 12:14:40 -0500

Changed in utouch-grail (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.