Multitouch possible in theory?

[Guest xangma]

If someone wants to, they can test this boot image to confirm it doesn't work. It doesn't work for me. I'm just checking =P

boot.img.zip

[Guest AndAddict]

Ok, I'm trying to compile the kernel now and I'm getting this error

cc1: error: unrecognized command line option "-mlittle-endian"

cc1: error: unrecognized command line option "-mapcs"

cc1: error: unrecognized command line option "-mno-sched-prolog"

cc1: error: unrecognized command line option "-mabi=aapcs-linux"

cc1: error: unrecognized command line option "-mno-thumb-interwork"

kernel/bounds.c:1: error: bad value (armv5t) for -march= switch

kernel/bounds.c:1: error: bad value (strongarm) for -mtune= switch

make[1]: *** [kernel/bounds.s] Error 1

make: *** [prepare0] Error 2[/codebox]

Any ideas?

Edited January 14, 2010 by AndAddict

[Guest John Hamelink]

Ok, I'm trying to compile the kernel now and I'm getting this error

cc1: error: unrecognized command line option "-mlittle-endian"

cc1: error: unrecognized command line option "-mapcs"

cc1: error: unrecognized command line option "-mno-sched-prolog"

cc1: error: unrecognized command line option "-mabi=aapcs-linux"

cc1: error: unrecognized command line option "-mno-thumb-interwork"

kernel/bounds.c:1: error: bad value (armv5t) for -march= switch

kernel/bounds.c:1: error: bad value (strongarm) for -mtune= switch

make[1]: *** [kernel/bounds.s] Error 1

make: *** [prepare0] Error 2[/codebox]

Any ideas?

Shooting in the dark, but perhaps the options should have two dashes before them, ie: "--mlittle-endian" as is the generally accepted standard for unix shell scripts?

[Guest xangma]

I think I came across this. Use toolchain 4.3.1 or whatever ... not 4.2.1. I think that's how I got past it.

EDIT: I literally can't do it. I've tried so much. The steps I took were:

-NANDROID backup and copy it over. Extract ramdisk from boot.img

- adb pull /proc/config.gz

-Get kernel source.

-Unzip config.gz, rename to .config ... place in root of kernel directory

-Edit .config and save

-run 'make ARCH=arm CROSS_COMPILE=arm-eabi-

-get zImage file and combine with ramdisk from the NANDROID backup.

Fastboot.

No work =[

Edited January 14, 2010 by xangma

[Guest AndAddict]

Shooting in the dark, but perhaps the options should have two dashes before them, ie: "--mlittle-endian" as is the generally accepted standard for unix shell scripts?

I was using make, so I don't have a script :) I think I might be missing some dependencys

[Guest _Sebastian_]

Your kernel won't boot?

[Guest xangma]

Your kernel won't boot?

Nope =[

Oh, and I erased ... cache just in case.

Edited January 14, 2010 by xangma

[Guest AndAddict]

If someone wants to, they can test this boot image to confirm it doesn't work. It doesn't work for me. I'm just checking =P

:) confirmed not working

I'll try arm-eabi-4.3.1

[Guest _Sebastian_]

I'll compile the 1.5 environment when i am back from work tomorrow evening and post my results then

[Guest xangma]

I'll compile the 1.5 environment when i am back from work tomorrow evening and post my results then

Sounds like a plan =] Right. Back to Windows for me then =] *reboot*

[Guest McSpoon]

-NANDROID backup and copy it over. Extract ramdisk from boot.img

- adb pull /proc/config.gz

-Get kernel source.

-Unzip config.gz, rename to .config ... place in root of kernel directory

-Edit .config and save

-run 'make ARCH=arm CROSS_COMPILE=arm-eabi-

-get zImage file and combine with ramdisk from the NANDROID backup.

Fastboot.

Those instructions are correct. Perhaps the ramdisk was wrong. I think nandroid backup copies the whole partition, even though the boot image doesn't fill it entirely. So your ramdisk may also contain some void data afterwards.

You could try this: un-cpio the ramdisk then re-cpio and re-gzip it, and see if that makes any difference.

[Guest xangma]

Those instructions are correct. Perhaps the ramdisk was wrong. I think nandroid backup copies the whole partition, even though the boot image doesn't fill it entirely. So your ramdisk may also contain some void data afterwards.

You could try this: un-cpio the ramdisk then re-cpio and re-gzip it, and see if that makes any difference.

You sir may be onto something =]

EDIT: Just tried it then. You're right, it does leave some void data ... but no booting =[

Edited January 14, 2010 by xangma

[Guest BigBearMDC]

Hey guys

I got a modified Pulse kernel booting!

I added the inpput.h, input.c, synaptics_i2c_rmi.c and mod_devicetable.h from the

cyanogen github and compiled the kernel with it without errors.

It boots up fine, but multitouch seems to does not work (I only tried Dolphin Browser).

I sent cyanogen a message on XDA Developer. asking him to tell me what he did on the

G1 to get multitouch working.

Greetings,

BigBear

[Guest Spooke]

Hey guys

I got a modified Pulse kernel booting!

I added the inpput.h, input.c, synaptics_i2c_rmi.c and mod_devicetable.h from the

cyanogen github and compiled the kernel with it without errors.

It boots up fine, but multitouch seems to does not work (I only tried Dolphin Browser).

I sent cyanogen a message on XDA Developer. asking him to tell me what he did on the

G1 to get multitouch working.

Greetings,

BigBear

Awesome! I hope you get it working :D, then It could maybe be added into the Vanilla Modaco roms?

Until you get Hero/2.0 roms working ;)

[Guest McSpoon]

I briefly looked into it, but sadly I don't think that Luke Hutch multi-touch hack will work on the Pulse. Not easily anyway. The Luke Hutch MT hack is the infamous one that was widely demonstrated on the G1 last year and I think Cyanogen uses the same concept.

I took a brief look at the current touchscreen driver code. The driver is aware of how many fingers are touching the screen but it cannot obtain the co-ordinates for the other fingers. So if you're pressing 3 fingers on the screen, the U8220 hardware will report there are 3 fingers but it only provides the co-ordinates for 1 of them. Whereas the HTC G1 would provide the co-ordinates for 2 of those fingers (early versions of Android ignored the 2nd finger but the data was always available). Which is why the G1 is able to have multi-touch hacks.

Admittedly it doesn't make any sense - it knows there are other fingers but it doesn't provide their co-ordinates - that's just crazy. Maybe there is a way to ask it for those co-ordinates, but it isn't providing them in the same way that the G1 does, which is odd because the code is almost identical.

Now I only looked at the code in /drivers/input/touchscreen/synaptics_i2c_rmi_tm1319.c and I have no idea what the hardware is capable of. There may be other ways to achieve multi-touch. My point is that the Luke Hutch MT hack relies on the touchscreen driver knowing the co-ordinates for 2 fingers. And the U8220 touchscreen driver doesn't have that data, it only knows the co-ordinates for 1 finger. So that hack alone isn't enough. ;)

If Huawei release an Android 2.x update then it will be interesting to see it has multi-touch. I hope it will.

[Guest BigBearMDC]

The best thing: i took me only 10 minutes :D (without the time I needed to compile the kernel ;) )

I hope to get an answer from cyanogen... I think thats the missing part.

Edit:

If the driver doesn't provide the coordinates, why don't we just edit it to provide them?

(looking at the synaptics driver from the G1)

Stay Tuned!

Greetings,

BigBear

Edited February 11, 2010 by BigBearMDC

[Guest david_dawkins]

Hey Mr McSpoon,

do you think that the driver is just incomplete, or that the hardware itself can't report the other coordinates? I'm not sure (yet) how the hardware exchanges data with the driver, but perhaps we can start dumping buffers to see what changes and see if there are more coords. I expect you've tried this already...

By golly I've never had so much fun with a phone. Some days I actually phone people on it too.

Dave

[Guest BigBearMDC]

Hey Mr McSpoon,

do you think that the driver is just incomplete, or that the hardware itself can't report the other coordinates? I'm not sure (yet) how the hardware exchanges data with the driver, but perhaps we can start dumping buffers to see what changes and see if there are more coords. I expect you've tried this already...

By golly I've never had so much fun with a phone. Some days I actually phone people on it too.

Dave

Have you ever programmed a µC?

The driver is the part that exchanges the information between hw and sw ;)

Greetings,

BigBear

[Guest McSpoon]

I think the hardware isn't able to report the other co-ordinates.

My interpretation is they took the G1 code and changed it to make the buffer smaller to just 8 bytes because the hardware cannot provide the other co-ordinates. But I'm just guessing.

The Pulse is fed the information from a buffer of 8 bytes, which contains data for only 1 finger.

x = buf[5] | (uint16_t)(buf[4] & 0x1f) << 8; /* x aixs */

y = buf[3] | (uint16_t)(buf[2] & 0x1f) << 8; /* y aixs */

z = buf[1]; /* pressure */

w = buf[0] >> 4; /* width */

finger = buf[0] & 7; /* numbers of fingers */

gesture = buf[6]; /* code of gesture */

magnitude = buf[7]; /* enhanced data of gesture */

Whereas the G1 gets the information from a buffer of 15 bytes, containing data for 2 fingers.

x = buf[3] | (uint16_t)(buf[2] & 0x1f) << 8;

y = buf[5] | (uint16_t)(buf[4] & 0x1f) << 8;

z = buf[1];

w = buf[0] >> 4;

finger = buf[0] & 7;

x2 = buf[3+6] | (uint16_t)(buf[2+6] & 0x1f) << 8;

y2 = buf[5+6] | (uint16_t)(buf[4+6] & 0x1f) << 8;

z2 = buf[1+6];

w2 = buf[0+6] >> 4;

finger2 = buf[0+6] & 7;

dx = (int8_t)buf[12];

dy = (int8_t)buf[13];

Even if you make the buffer bigger it doesn't provide any additional data. However 'finger' will report 3 if there are 3 fingers touching the screen.

[Guest BigBearMDC]

Hmm...

x2 = buf[3+6] | (uint16_t)(buf[2+6] & 0x1f) << 8;

y2 = buf[5+6] | (uint16_t)(buf[4+6] & 0x1f) << 8;

z2 = buf[1+6];

w2 = buf[0+6] >> 4;

...y2 = buf[5+6] ... looks for me as if the G1 is also using only 8 bytes of data, but it recreates the coordinates from it...

But its true. If the HW only gives us 8 bytes of data then theres no way to get multitouch working - at least if the HW doesn't even support to send data for more than one finger...

Maybe, but just maybe, if the HW recognizes 2 fingers and gets the coordinate from 1 finger and the arythmetic mean of the second finger, you could also recreate the coordinates of the second finger.

If that doesn't work, the only way would be to reprogramm the µC that controls the touchscreen - and thats not possible i guess.

Edited February 11, 2010 by BigBearMDC

[Guest BigBearMDC]

-> Synaptics Developer Manuals

[Guest BigBearMDC]

Now thats interesting

Look at this

[Guest BigBearMDC]

I now sent Synaptics an email:

Hello Synaptics Team,

my name is Wolfram Hofmeister and i have a question about one of your Products.

The Android smartphone Huawei U8220 is using this Synaptics controller:

Synaptics RMI TM1319

Is it possible to get a detailed datasheet or at least a few more technical details about this controller?

Is this controller able to handle Multitouch?

Thanks for your help!

Greetings,

Wolfram Hofmeister

I hope to get an answer soon!

Stay Tuned!

Greetings,

BigBear

[Guest david_dawkins]

Have you ever programmed a µC?

The driver is the part that exchanges the information between hw and sw ;)

Greetings,

BigBear

I know that much! I just don't know how it's done! (eg, memory mapping, etc)

Dave

[Guest BigBearMDC]

As far as i know there are two "parts" of software.

The first part is the firmware of the µC. It handles the memory mapping, interrupts...

The second part is the driver. It receives the data from the µC and processes them.

So unless we dump the firmware from one of the µC's we won't see how the memory mapping etc. works ;)

Also its comlicated to modifiy the firmware of the µC. I guess even impossible because they may have read-only

memory that also has a read-protection. So we can just search for #defines like CONFIG_TOUCHSCREEN_GESTRUE=y

I think the controller is able to handle multitouch. Its a smartphone, and not a standard mobile phone...

Greetings,

BigBear