Jump to content

Multitouch possible in theory?


Guest lemmyc

Recommended Posts

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?!

Link to post
Share on other sites
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 by BigBearMDC
Link to post
Share on other sites
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

Link to post
Share on other sites
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 =]

Link to post
Share on other sites
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 by BigBearMDC
Link to post
Share on other sites
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?

Link to post
Share on other sites
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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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

Link to post
Share on other sites
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 by AndAddict
Link to post
Share on other sites
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

Link to post
Share on other sites
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 ...

Link to post
Share on other sites
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?

Link to post
Share on other sites
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?

Link to post
Share on other sites
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.

Link to post
Share on other sites
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?

Link to post
Share on other sites
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 by _Sebastian_
Link to post
Share on other sites
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 by xangma
Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.