Multitouch possible in theory?

[Guest xangma]

Sorry for digging in old Topics ... but i just found a kernel config regarding multitouch for those who want to take a look it's in msm/include/linux/input.h

Within the menuconfig you might activate it via:

Device Drivers --> Input device support --> touch screen gesture suport (NEW)

A picuture of the menuconfig in the attachment

Oh and did you check this out in the end? I'm terrible with Kernel stuff otherwise I would have a look. I don't even know how you go to that program to generate a config using a GUI?!

[Guest BigBearMDC]

I learn to programm µControllers in my school...

I know theres a big difference between a simple µC and a mobile phone but I'll have a look at the differences between the file from the G1 and the Pulse as soon as i can :)

EDIT:

seems to be a simple copy/past job.

I'll edit the file for the Pulse and upload it.

But somebody else has to recompile the kernel please :)

Stay Tuned!

Greetings,

BigBearMDC

Edited January 14, 2010 by BigBearMDC

[Guest xangma]

I learn to programm µControllers in my school...

I know theres a big difference between a simple µC and a mobile phone but I'll have a look at the differences between the file from the G1 and the Pulse as soon as i can :)

EDIT:

seems to be a simple copy/past job.

I'll edit the file for the Pulse and upload it.

But somebody else has to recompile the kernel please :)

Stay Tuned!

Greetings,

BigBearMDC

Awesome. I'll give it a go tonight =] Maybe? If I can figure out how and where to find and put a config file =P

[Guest BigBearMDC]

So, here's the patched synaptics_i2c_rmi.c.

Somebody has to recompile the kernel with this file.

I would do it myself but unfortunately i can't.

Greetings,

BigBearMDC

synaptics_i2c_rmi.rar

[Guest xangma]

So, here's the patched synaptics_i2c_rmi.c.

Somebody has to recompile the kernel with this file.

I would do it myself but unfortunately i can't.

Greetings,

BigBearMDC

There was a patch file in the original zip I uploaded ... where has that gone and do we need it? Sorry, I didn't really read any of the file or anything yet, just thought it might be interesting and so far it may well be =]

[Guest BigBearMDC]

In the other file there only stood what code and where you have to copy it :)

Greetings,

BigBearMDC

[Guest xangma]

In the other file there only stood what code and where you have to copy it :)

Greetings,

BigBearMDC

Wait, so I still have to use the patch yeah?

[Guest BigBearMDC]

Wait, so I still have to use the patch yeah?

I don't think so.

The file only contains the code that has to be edited in the synaptics_i2c_rmi.c file.

(with line numbers etc.)

The synaptics_i2c_rmi.c from the KernelPatch zip is already patched, but i don't think it would work on the Pulse.

Thats why i edited the file from the Pulse kernel.

Greetings,

BigBearMDC

Edited January 14, 2010 by BigBearMDC

[Guest xangma]

I don't think so.

The file only contains the code that has to be edited in the synaptics_i2c_rmi.c file.

(with line numbers etc.)

The synaptics_i2c_rmi.c from the KernelPatch zip is already patched, but i don't think it would work on the Pulse.

Thats why i edited the file from the Pulse kernel.

Greetings,

BigBearMDC

Ohhhhhhh I get it. Do we also have to enable it in the config file?

[Guest BigBearMDC]

hmm i don't think so as the structure of the file hasn't really changed (there are only 2 variables added: int x and int y)

The rest stays the same.

Only the way that the input gets processed changed a little bit.

Greetings,

BigBearMDC

[Guest xangma]

hmm i don't think so as the structure of the file hasn't really changed (there are only 2 variables added: int x and int y)

The rest stays the same.

Only the way that the input gets processed changed a little bit.

Greetings,

BigBearMDC

Ok. Sorry for all the questions =P So the kernel knows to compile from this file anyway? So the steps I shoudl take are. Get kernel source. Get existing config file. Replace config file. Replace this touchscreen thing file. Compile.

[Guest BigBearMDC]

Get kernel source. Get existing config file. Replace config file. Replace this touchscreen thing file. Compile.

I think so but i have not yet recompiled a kernel on my own so I'm not 100% sure :)

Greetings,

BigBearMDC

[Guest AndAddict]

I asked the guys on cyanogen about a week ago what they actually did to get multitouch on the G1, and they said they backported it from Android 2.0. The multitouch code for the cypress chip is already there,

the input.c and input.h are changed too, but its a copy/ paste job too.

I'm trying to get a working compile of vanilla code though, I'll see if i can find and post my edited input.c

Edit: I just copy and pasted the input.c from cyanogen

Edited January 14, 2010 by AndAddict

[Guest xangma]

I asked the guys on cyanogen about a week ago what they actually did to get multitouch on the G1, and they said they backported it from Android 2.0. The multitouch code for the cypress chip is already there,

the input.c and input.h are changed too, but its a copy/ paste job too.

I'm trying to get a working compile of vanilla code though, I'll see if i can find and post my edited input.c

Edit: I just copy and pasted the input.c from cyanogen

Keep us updated. Could you upload the files you are using?

In other news ... BigBear ... Unfortunately HUAWEI have customised the synaptics and use their own. It is attached. Any chance of it being put in there?

synaptics_i2c_rmi_tm1319.c.zip

[Guest AndAddict]

Input.c

It was just this, some functions are changed and others have been added, these are for donut though

[Guest _Sebastian_]

Sorry people i am short in time atm ... You don't need to exchange anything in the kernel just active the Setting ... here is a short piece of the input.c provided by huawei:

static void input_handle_event(struct input_dev *dev,

				   unsigned int type, unsigned int code, int value)

{

	int disposition = INPUT_IGNORE_EVENT;


	switch (type) {


	case EV_SYN:

		switch (code) {

		case SYN_CONFIG:

			disposition = INPUT_PASS_TO_ALL;

			break;


		case SYN_REPORT:

			if (!dev->sync) {

				dev->sync = 1;

				disposition = INPUT_PASS_TO_HANDLERS;

			}

			break;

		}

		break;


	case EV_KEY:

		if (is_event_supported(code, dev->keybit, KEY_MAX) &&

			!!test_bit(code, dev->key) != value) {


			if (value != 2) {

				__change_bit(code, dev->key);

				if (value)

					input_start_autorepeat(dev, code);

			}


			disposition = INPUT_PASS_TO_HANDLERS;

		}

		break;

#ifdef CONFIG_TOUCHSCREEN_GESTRUE	

	case EV_GESTURE:

		if (is_event_supported(code, dev->gesturebit, GESTURE_MAX) ) {

			disposition = INPUT_PASS_TO_HANDLERS;

		}

		break;

#endif/*CONFIG_TOUCHSCREEN_GESTRUE*/

...

So as soon you activate CONFIG_TOUCHSCREEN_GESTRUE it will be compiled into the kernel ...

[Guest xangma]

Sorry people i am short in time atm ... You don't need to exchange anything in the kernel just active the Setting ... here is a short piece of the input.c provided by huawei:

static void input_handle_event(struct input_dev *dev,

					unsigned int type, unsigned int code, int value)

 {

	 int disposition = INPUT_IGNORE_EVENT;


	 switch (type) {


	 case EV_SYN:

		 switch (code) {

		 case SYN_CONFIG:

			 disposition = INPUT_PASS_TO_ALL;

			 break;


		 case SYN_REPORT:

			 if (!dev->sync) {

				 dev->sync = 1;

				 disposition = INPUT_PASS_TO_HANDLERS;

			 }

			 break;

		 }

		 break;


	 case EV_KEY:

		 if (is_event_supported(code, dev->keybit, KEY_MAX) &&

			 !!test_bit(code, dev->key) != value) {


			 if (value != 2) {

				 __change_bit(code, dev->key);

				 if (value)

					 input_start_autorepeat(dev, code);

			 }


			 disposition = INPUT_PASS_TO_HANDLERS;

		 }

		 break;

 #ifdef CONFIG_TOUCHSCREEN_GESTRUE	

	 case EV_GESTURE:

		 if (is_event_supported(code, dev->gesturebit, GESTURE_MAX) ) {

			 disposition = INPUT_PASS_TO_HANDLERS;

		 }

		 break;

 #endif/*CONFIG_TOUCHSCREEN_GESTRUE*/

 ...

So as soon you activate CONFIG_TOUCHSCREEN_GESTRUE it will be compiled into the kernel ...

Just seen that. Now to compile. I've got the .config in place. Do I really need to CROSSCOMPILE it with the source? That means downloading the source for me. That sucks. Help?

[Guest _Sebastian_]

Depending on your way to build the kernel add to your .config or /arch/arm/configs/msm7201a-perf_defconfig following

line :

CONFIG_TOUCHSCREEN_GESTRUE=y

That's all.

[Guest xangma]

Depending on your way to build the kernel add to your .config or /arch/arm/configs/msm7201a-perf_defconfig following

line :

CONFIG_TOUCHSCREEN_GESTRUE=y

That's all.

Oh yes. Done that =] Just compiling now. Do toolchains change between say 1.5 and 1.6?

[Guest BigBearMDC]

If you finished that i would like to test it :)

Greetings,

BigBearMDC

[Guest xangma]

If you finished that i would like to test it :)

Greetings,

BigBearMDC

I would love to finish it to test it. No idea what i'm doing so far =P

[Guest _Sebastian_]

Nope, still gcc-4.2.1, 4.3.1 and 4.4.0 available. I like gcc-4.3.1 it's not as strict then 4.4.0 and there are less strange compiler errors as in 4.2.1. But that's my personal opinion :)

@xangma

I hope i'll get some "play time" at the weekend. FYI I've took a look at the code aurora stuff the best fitting 1.6 project seems to be the donut-cinnamon branch.

[Guest xangma]

Nope, still gcc-4.2.1, 4.3.1 and 4.4.0 available. I like gcc-4.3.1 it's not as strict then 4.4.0 and there are less strange compiler errors as in 4.2.1. But that's my personal opinion :)

@xangma

I hope i'll get some "play time" at the weekend. FYI I've took a look at the code aurora stuff the best fitting 1.6 project seems to be the donut-cinnamon branch.

Awesome, thanks for that info.

And why do you say that about the cinnamon branch?

[Guest _Sebastian_]

Awesome, thanks for that info.

And why do you say that about the cinnamon branch?

The next "target" for an 1.6 build environment

But this will be a massive workload. Manual Kernel patching (And i am not a kernel hacker ... )

Edited January 14, 2010 by _Sebastian_

[Guest xangma]

The next "target" for an 1.6 build environment

But this will be a massive workload. Manual Kernel patching (And i am not a kernel hacker ... )

I'm sure we can do it. We might have to now if no more updates are going to be released =/

This kernel compiling is going well for once =/

EDIT: Got the hang of it now. Only problem is, the last one didn't boot. This one is looking more promising.

Edited January 14, 2010 by xangma