On 4/3/07, adrian cockcroft <[EMAIL PROTECTED]> wrote:
This is key:- "Pressure has almost no effect on a single touch, but not so on a double touch. The relative pressures will cause a significant skewing effect towards the harder touch. You can easily move the pointer along the line between your two fingers by changing the relative pressure."
So we will not see clearly defined bounding box limits. The point will
skate around within the limits depending on relative pressure.
So I guess we need someone with a device to test this and see how much pressure actually affects the neo touch screen. With that information I think we could see how easy it would be to get an average bounding box approximation.. The first finger will set a clear start point, the second finger will
make that point shoot off towards it, but it will not go all the way to the second touch. The effect should be to oscillate along the line between the two end points, and it wont return to the position of the first touch. If we capture a clear single touch, and an average position of oscillation, then we can take the average oscillation to be the center of the bounding box, and project an estimate of the opposite corner where the second touch should be. With the right filtering and limiting algorithm it should be possible to get the effect we want. If we can give visual feedback on the screen showing the touch points and bounding box it may help the user control the input better.
Ok so what if this feature was disabled by default. Since enabling it might slow some functionality. When the user enables the feature he/she will have to go through a config which does a calibration. The user runs through several scenarios where the program can gather the relative pressure difference in known circumstance with the desired result known as well. It could then store that information in a database based on which user is using it, if there are multi users, if not just store it in a config file. Challenges: In comparison with a true dual touch input device, its
going to react more slowly as the algorithm will need to gather more data to decide where the pointer should be. Some of the faster moving single touch gestures may be hard to distinguish from multi touch. Adrian
I agree, but it would still be a nice feature to have and I could deal with a little lag for added feature especially if I could enable it or disable it. With the single touch fast gestures we could set that up inside of the calibration also. That way if it thinks it's multi touch it compares it with it's database which links it to the single touch fast gesture instead. It would be slow but you could disable the multi touch option and then single gestures would be fast again. Or we could have the multi touch be enabled in certain programs like web browsing or picture viewing, and disabled for the rest. But I think a simple button in the header or footer should work alright. You could have it turn green when active and red when deactivated.
_______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
