I've come up with a few algorithms for translating unitouch input, as well as a combo of unitouch input and accelerometer input, into specific uses of dualtouch input (each is more suited to one or another situation).


But for those algorithms to be of any use with programs made for multitouch, we need a scriptable way to provide multitouch input, somthing that would trick programs into bdelieving true multitouch is happening, and which you could program to suit the different use cases. Do you know of anything like that?

I think Lcuk was fooling around with this for awhile and he actually had a workable demo.

Lcuk's youtube multitouch demo:

http://www.youtube.com/watch?v=dJWvvn_cePM

You can achieve the same result with Qt with really few lines of code, but you have to insert multitouch emulation directly into the code of your application.

@Tiago
Since Maemo's X server does not support multitouch I don't know if what you want to do is possible. I mean, you can send two input signals simultaneously, but I think they will be processed one after the other.
Atm, I think that the only possible solution is to implement multitouch emulation directly into applications' code.

I imagine it would involve a driver for the virtual multitouch device

Question: The way Stantum screens detect multitouch is they are able to get contact data from every grid point on the screen individually and based on pressure/distribution are pretty easily able to figure out what spot is one touch, and which is another.

Is there something about the actual physical make up of the N900 screen that makes it incapable of this? Or is it just that whatever hardware does the processing of the inputs isn't meant to figure this stuff out? If the latter, what level of access, if any, can the operating system get to the raw outputs of the screen hardware? (Now, stantum screens have their own preprocessor that does the calculations/whatever to tell the device where the touches are, so if this was even remotely possible, it would probably rape the CPU and be practically useless. But I am still curious, is there something inherent about how most resistive screens are built that makes them incapable of detecting presses the same way, at the very very fundamental level? Or is it that Stantum was the only one that bothered to figure out how to calculate separate touches from all the inputs?)

I think that there are different methodes to formulate dualtouch on a singletouch device. (My propositon is still touch&swipe).

The problem for the moment is only how to make believe the n900 that he is a multitouch device.
Then you can send emulated multitouch events to the n900.

Probably you need to find a multitouch driver for the n900.
That should be no problem. Because there exist usb-multitouch touchpads that can be used with arm-linux.

Like i said, there are different algorithms, some better for some situations and others for others.

Imagine the Stantum resistive screen as a lot of small finger-sized N900-like resistive screens layered out on a grid.

You wouldn't be far from the real thing. Also, you can guess why this is different from what the N900 has.

fingersized? I thought they had hyperpixel resolution sensing of multitouch...though from what i remember from the videos perhaps they just did a bit of plausibly deniable slight of hand, in a moment showing all ten fingers touching the screen at once all enough apart from each other to not trigger artifacts and then switching to talking about the high precision of a single pointy thing against the screen....dunno what to believe...