Help Some new info on i7500 multitouch

[screaminbug]

Galaxy definitely can detect more than one finger. That's not quite the news and it has already been proven by the chaps at receptorblog.

We've yet to find a way how to read 2nd finger actual coordinates to make it useful. I spend a quite a bit of time reading data from various ts controller registers trying to find something that will give us a hint where that coordinates might be. Although didn't really find anything that could be useful.

BUT! Today Pieter discovered that in fact HTC Hero has Melfas driver in its kernel source that seems to support double touch !!

It that driver the data for 2nd finger starts at 0xD1! That's much farther than I looked, so I guess this gives us some more hope that at least doubletouch is possible on Galaxy.

Details tomorrow. Now is time for some sleep.

 

[kam187]

Good work guys! I knew you could do it

And i told you to keep reading till u get FF or it loops

 

[Andronix]

has drakaz tried to diff htc melfas sources yet? and compile them ofc

 

[Xenon]

Wow. Reverse engineering :thumbsup:

Keep at it guys and if there's anything we can do to help let us know.

 

[Yathushan]

I love this. See samsung can provides a phone with potential but leaves the software half done! Its a shame if they bothered to do something about it. They could've had more sales.

 

[screaminbug]

Unfortunately, no good news.

Still no data of 2nd finger whatsoever. Now I went to extreme, until it looped. There were some non-zero bytes there, but they are constant no matter of finger movement. And one more thing. Apart from x, y and z, this new driver expects to read something they call key_x_axis on bytes 8 and 9 of first register, and w from byte 6. However those bytes are always zero. The second register (0xD1) should give data for 2nd finger, but those are also all zero, until byte 31, until some crazy data that just repeats itself, no matter of finger position.

Here's an example:

Byte zero reads 3 when there's another finger detected (1 is when it's only one finger):

[  525.130558] FINGER 1: 3
[  525.130581] x = 166; y = 159; z = 122; w =   0
[  525.130596] buff reg 0x10:   3   0 166   0 159
[  525.130611] buff reg 0x10: 122   0   0   0   0
[  525.130623] 
[  525.130629]    3   0 166   0 159 122   0   0   0   0   0   0   0   0   0   0
[  525.130669]   51 161   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  525.130708]  128 163 149 198 252 120  65 192  47   0   0   0 128 163 149 198
[  525.130749]    3   0   0   0   0   0 157 198   0   0   0   0 228  30 157 198
[  525.130789]  208  30 157 198 196 128   6 192 156 225   5 192 136 139  64 192
[  525.130831]    0   0   0   0 252  30 157 198 232  30 157 198 188  31   3 192
[  525.130873]   36  31   3 192 204 234  67 192 255 255 255 255   0 128 161 193
[  525.130914]    2   0   0   0  96  80  65 192  32 178 176 196  52  31 157 198
[  525.130956]   16  31 157 198 192 217   7 192 156 225   5 192   0   0   0   0
[  525.130996]   32  31 157 198  28 128 161 193  96  85 174 198  21   0   0   0
[  525.131038]   32 178 176 196  76  31 157 198  56  31 157 198   8 218   7 192
[  525.131079]  124 217   7 192  96  85 174 198  64 137  73 192 156  31 157 198

At this point it goes to a block to read data for 2nd finger. First four bytes are used in the driver to determine it's position. As you can see, they are zero (in fact, first 32 bytes are all zero). And the other ones just stay the same value, no matter what's happening:

[  525.140991] FINGER 2: 1
[  525.141011] x =   0; y =   0
[  525.141026] buff reg 0xD1:   0   0   0   0
[  525.141063] 
[  525.141073]    0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  525.141128]    0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  525.141183]   12  30 157 198 240  29 157 198 120 242   5 192 156 225   5 192
[  525.141241]   80  72 152 198  19   0   0  96   0   0   0   0   0  72 152 198
[  525.141299]   28  30 157 198  16  30 157 198 228 242   5 192 252 241   5 192
[  525.141358]   60  30 157 198  32  30 157 198  84 120  31 192 156 225   5 192
[  525.141416]   96  94 171 198  19   0   0 128   0  88 152 198 208  90 152 198
[  525.141474]  164  30 157 198  64  30 157 198 208  96  31 192 156 225   5 192
[  525.141533]   84 120  31 192 156 225   5 192 224  94 171 198  19   0   0 128
[  525.141591]   48  91 152 198  36  91 152 198  32  91 152 198  20   0   0   0
[  525.141648]  208  96  31 192 156 225   5 192 224  29   3 192 140  31   3 192
[  525.141708]  180  30 157 198 128  30 157 198  48  91 152 198 128 163 149 198

The conclusion is that we probably need an updated firmware to make this work.

 

[Pieter]

I tested it as well. The key_x_axis seems to be for hardware buttons (like the ok, back and menu button), which the samsung does not have - so they are allways 0. This driver still only reports a single touch and a palm touch. It works quite well though.

Perhaps with new firmware we can do this, but so far we cannot do multitouch.

 

[screaminbug]

I tested it as well. The key_x_axis seems to be for hardware buttons (like the ok, back and menu button), which the samsung does not have - so they are allways 0. This driver still only reports a single touch and a palm touch. It works quite well though.

Guess you're right about key_x_axis.

I should, however, write what I think what that byte 0 represents, what I wrote in IRC.

So that byte 0 is probably a bitmap which holds number of fingers pressed, rather than number of fingers in binary. Coded like this (lower nibble):

0000 = 0 = no touch
0001 = 1 = single
0011 = 3 = double
0111 = 7 = palm

 

[Andronix]

it's not visible what exactly have you tried guys? just tested what receptorblog found out or played with htc hero sources???

 

[kam187]

The touchscreen uses an i2c interface that you can use to read registers. We can see from the galaxy driver that it reads the data for the first finger you press from 0x10 (or was ix 0x0). So these guys found that the hero uses the same find of driver.

They found that that driver reads its second finger data from 0xD1.

So they modified the galaxy driver to print ALL the registers from 00 to the end (you know when you get to the end becuse it loops to the beggining or returns 0xFF).

Next they pressed the finger, and second finger in various places to see where the co-ordinates for this second finger could be. Where we expect them to be is a nice block ox 00's. That means the firmware in the touchscreen itself isnt sending the data.

Since they added the possibility to update the touchscreen in the melfas driver, we can expect they will update its firmware to support multitouch at some point.

The big question here is, has the behold already got this update?

 

[informale]

The big question is, is Behold 2 supposed to get this update?

 

[Xenon]

How big of a trade secret do you guys thing is? And how big
a company is Melfas? Would it make sense to email them about
this, or try to reach one of their developers through LinkedIn or
something?

 

[Pieter]

Thanks for the clarification kam

I have a few things to add:

- the hero does not use the melfas touchscreen, but nevertheless is was in their source (probably for the droid eris, which does use a melfas screen)
- the hero driver also did some register settings during the initialization of the touchscreen - the main reason for trying if this works.

Indeed the behold has a different touchscreen firmware (verified - the behold2 contains version 33 for the galaxy, and version 17 for the behold2. They seem to address different hardware versions, hence the different version numbering. There is no higher version in the behold 2 source code. We could create a kernel for the behold users to try if their screen is different, if it's possible to flash the kernel for the behold.

 

[Terry]

I dunno if this helps but I know the milestone (The UK version of the droid) has multi touch working, I dunno if it's melfas or synaptics though.

 

[Pieter]

Terry, the HTC droid eris is like a HTC Hero for the US market (specifically one operator). It supports multitouch out of the box. It's not related to the Motorola droid.

Perhaps we could just grab the touchscreen firmware from there. Anyone with a droid eris willing to try a firmware dump?

 

[screaminbug]

Thanks for the clarification kam

I have a few things to add:

- the hero does not use the melfas touchscreen, but nevertheless is was in their source (probably for the droid eris, which does use a melfas screen)
- the hero driver also did some register settings during the initialization of the touchscreen - the main reason for trying if this works.

Indeed the behold has a different touchscreen firmware (verified - the behold2 contains version 33 for the galaxy, and version 17 for the behold2.

Do you mean the file 5S_MTH_SI7500P_RKA1_VA33_bin.c? Are you sure it's the right one. Did you notice what's inside. There is a comment which reads:
// Model name : MTH_T939

// Module revision : 10

// Firmware version : 06

About the melfas driver. I'm currently looking at the Moment kernel, and it also has melfas driver (I suppose all kernels do). The file is called melfas_m900_ts.c. It also has a separate source file for melfas firmware download (melfas_download.c)

Take a look at this git repo.

 

[lazarus101]

Perhaps we could just grab the touchscreen firmware from there. Anyone with a droid eris willing to try a firmware dump?

found this in another forum ERIS DUMP.zip

 

[ryko]

Total shot in the dark , I have noticed that if you move a widget around on the screen and and then while you still moving the widget touch the screen with another finger the widget moves towards that finger slightly. Is there a program like locat that would show you what command was used at that instant ? I am no technition but just hope that this might help in some small way

 

[spottyelephant]

I'd just like to add a strange thing i noticed on my own one - a while ago i installed dolphin browser (and then uninstalled it, but files remained in root), and since then pinch zoom kinda of works on the browser - 2 out of 3 pinch / stretch will zoom in or out - it doesn't do it gradiently though, it zooms in and the browser re-wraps the text. Maybe im seeing things, but iv played with it quite a lot and im defo not just hitting the zoom in/out buttons at the bottom.

 

[Xenon]

Total shot in the dark , I have noticed that if you move a widget around on the screen and and then while you still moving the widget touch the screen with another finger the widget moves towards that finger slightly. Is there a program like locat that would show you what command was used at that instant ? I am no technition but just hope that this might help in some small way

Similar thing happens with the keyboard. If you keep one key pressed
(say Q) and press another on the other side of the keyboard (say P),
keys start popping up towards the location of the second press... but
don't quite reach it. They stop at T or thereabouts. As if an average of
the two pressed locations is taken. Also interestingly, this only happens
on the X axis when the keyboard is in portrait mode and on the Y axis
when it is in landscape mode (that is, only on one and the same axis).

Weird, huh?

 

[Xenon]

Taking the average location makes sense as an error correction
mechanism, but only if two conditions are met:

1) the phone is not multitouch, so the keyboard is not programmed to be either
2) the keyboard can receive two sets of coordinates for one press and tries to handle it

The conditions being mutually exclusive, I don't know what to think of it.

What if the driver can't keep sending two sets of coordinates, but can instead
signal whether a finger is lifted or not. This would allow for semi-multitouch:
always broadcasting the coordinates of the finger that "landed" last, but also knowing
the last position of the finger used prior to that, and whether it has been lifted or
not.

 

[Pieter]

The average location between fingers is done on the touchscreen chip, that is easy enough to confirm. The Droid Eris dump probably won't help, we need the firmware of the screen, not the phone. Even that might not help at all and just brick phones.

I e-mailed Melfas for more information. Perhaps they will respond.

 

[screaminbug]

Yes. This averaging thing is normal and it's happening on the chip.

Pieter, I think I found something when reading from registry 0x30. There are two 16 bit numbers that change with 2nd finger movement coded on the following bytes (0x30 through 0x33). However, those numbers sometimes exceed maximum x and y, but are always below 1000. Perhaps those have nothing to do with coordinates, so the question is: what are they?

I've found who wrote a driver for MCS-5000 for recent Linux kernel. I don't think he's the same person who wrote the driver found in hero or galaxy sources (because this MCS-5000 is much nicely written), but maybe he can help somehow. Anyone with good negotiation/diplomatic/persuasion skills wants to contact him?

 

[Xenon]

Well, averaging the letters Q and P into letter T is hardly a desirable behaviour

Anyway, can firmware of the touch screen even be upgraded? Can we see the
source or at least the binary of the current screen firmware?

 

[screaminbug]

Well, averaging the letters Q and P into letter T is hardly a desirable behaviour

Sometimes it isn't desirable, but it's nevertheless normal. And this is the case on most (if not all) touchscreens (even the resistive ones). Imagine what would be like without it (remember you don't have a finger of a size of a single pixel )

Anyway, can firmware of the touch screen even be upgraded? Can we see the source or at least the binary of the current screen firmware?

In behold2 kernel there is an option of a firmware upgrade. We don't have the firmware sources. If we had it, we wouldn't be having this conversation at all.

Binaries of the various melfas firmwares are also inside behold source. However, because of the strange versioning conventions (or just plain sloppiness) Samsung uses, we cannot know for sure which of those is running on Galaxy (or Behold). Two of those which we believe are running on Galaxy and Behold were 8051 disassembled (we have some reasons to believe the touchscreen MCU is 8051). ASM sources we've got are quite large (about 50k lines each) and it will take quite a lot of time and patience to go through it, especially for someone not familiar with 8051 assembly.

But, of course, no one wants to put those firmwares on their phones, and for a reason. A lot of this is based on a lot of assumptions. That's why we need behold firmware (actual dump). If we had the actual firmware dump, we'd know with more certainty that it'll work on Galaxy, and then we could test if it gives us something better than what we currently have.