23 replies to this topic

[GuyOverThere]

Hi all,

So after a lot of gathering around, googling and bothering people, I've sources for the kernel 2.6.32.9. I've created a repo on my github for posterity and in case I can't get working sources anymore xD Please note that this sources are missing some changes needed to support gen2 devices, I'll add them in a none distant future (is actually easy) (done)

Github: Kernel Sources 2.6.32.9 - ZTE Racer

Now, I know this kernel is somewhat old, many would like to have 2.6.35 or even 3.x (yeah right xD), but right now there are only two kernels working for racer owners, vamshi's 2.6.32.9 #68/#70 and deadlink's 2.6.32.9 #186/#187.

There are sources on github of vamshi's kernel and deadlink's kernel... well, it turn's out that in both cases, the sources are incomplete vamshi didn't include his touchscreen driver or a config to compiles a kernel that boots (and you can't even get it from /proc in his latest kernels!), deadlink didn't include a valid config, the touchscreen driver is not his latest and gen2 support is started but not finished


With the ones already compiled that do exist there's always a trade off between what of those to choose, very quick:

- vamshi's has smartass v2, deadlink's not (if you like that governor or not is another thing).
- calibration and touch sensitivity differ, vamshi's doesn't have jump-to-left ghost clicks and uses high sensitivity (very high for some, like me), deadlink's has ghost clicks (not a lot, but they're there) and low sensitivity. So... what if you want a kernel that has smartass v2 and less sensitivity?

Also, there are things that can only be changed at kernel level or are more efficient to change it there instead of using user level applications, you want to change calibration? you need to edit the touchscreen driver, you want to support a new file system for whatever reason? you need to recompile the kernel with support for it, you want to make the kernel more efficient, smaller or bigger with full debug support when things go wrong, you need to recompile...

Want to try a newer kernel? is easier when you can check your old kernel to see how things were done there when your most needed macro doesn't exists in your new kernel....

So for all the reasons above and if you'd like to mess with it, try your own modifications, learn something, have something to "buuuh" at or whatever I'm putting the kernel source tree that compiles and boots (calibration is not the best, be warned)

Edit:// typos

Edited by GuyOverThere, 22 August 2012 - 02:00 AM.

[GuyOverThere]

Just to let you know, made few changes, nothing big, haven't break anything yet D:, the changes for GEN1 and GEN2 support is done.

Also removed/changed few things from msm_ts.c (touchscreen driver). It's now more stable, still isn't perfect calibration but I think is stable enough to be usable, serve as educational resource or whatever (you had to see how it was before xD)

I'm using a kernel compiled from those sources, things I haven't tested are vpn, wifi tethering, radio and haven't tested bluetooth extensibly either (this are things I don't use and I don't have a good way to test the vpn thing).

I think I won't change much from master branch unless I learn a lot about this stuff xD I'll work my experiments on another branch or something or maybe since this sources seem stable enough I'll try again with .35 kernel

Edited by GuyOverThere, 22 August 2012 - 02:05 AM.

[massacre^]

Way to go ! congo :]

[mikeioannina]

Which kernel sources did you use as a base? vamshi or deadlink's? Also have you changed any files except the ones you commited in your github?

[GuyOverThere]

 mikeioannina, on 10 October 2012 - 12:20 PM, said:

Which kernel sources did you use as a base? vamshi or deadlink's? Also have you changed any files except the ones you commited in your github?

The sources are based on vamshi's kernel, however msm_ts.c (touchscreen driver) and board-mooncake.c are based on deadlink's sources (since board-mooncake.c from deadlink have more hardware definitions) and I've only changed the files I've commited.

[mikeioannina]

Thanks, I tried equiliym's latest cm7 nightly on ZTE Carl and everything works except Wifi, Camera and Accelerometer...
I successfully built my own kernel from your sources and now I'm checking the differences between the default .config of my stock rom and the defconfig on your github... maybe the camera, wifi and accelerometer are different in my phone and I just have to enable them in the kernel .config

[GuyOverThere]

 mikeioannina, on 10 October 2012 - 05:03 PM, said:

Thanks, I tried equiliym's latest cm7 nightly on ZTE Carl and everything works except Wifi, Camera and Accelerometer...
I successfully built my own kernel from your sources and now I'm checking the differences between the default .config of my stock rom and the defconfig on your github... maybe the camera, wifi and accelerometer are different in my phone and I just have to enable them in the kernel .config

Equilyim's roms by default uses vamshi's kernel so you could try deadlink's kernel with that rom and see if camera, wifi, etc works.

[mikeioannina]

I tried that but no change... they still don't work. I noticed that the stock wifi module has different size than the prebuilt we use. I swapped them but still doesn't work. Do we have sources to build the wifi module?

[GuyOverThere]

 mikeioannina, on 11 October 2012 - 12:43 AM, said:

I tried that but no change... they still don't work. I noticed that the stock wifi module has different size than the prebuilt we use. I swapped them but still doesn't work. Do we have sources to build the wifi module?

wifi module?

just in case, wifi is handled by a kernel driver, netd is a network daemon in charge of setting configurations like ip address, netmask, dns... so, if you need the wifi kernel driver source, I don't have it if it's not part of the kernel sources we already have, meaning that you'll need Carl's kernel source to have access to the wifi driver (or sources from another kernel that has the same wifi as your phone)

Edited by GuyOverThere, 11 October 2012 - 12:49 AM.

[mikeioannina]

As I can see, wifi is handled by a kernel driver which is compiled as a module (/system/wifi/ar6000.ko). The same driver is used by Carl, meaning they don't have a totally different wifi chipset. I searched in the forums and I saw that ZTE Blade users also had problems with wifi because there was no source available, but it was added from another device's kernel source at some point. Blade uses the same wifi chip as Racer and Carl.

I'm trying to find the kernel source that vamshi used as a base for his sources all day... they are a lot different than deadlink's(which are based on TomGiordano's sources, which now are part of official CM sources)

I'll post a logcat with my wifi problem

[GuyOverThere]

 mikeioannina, on 11 October 2012 - 01:06 AM, said:

As I can see, wifi is handled by a kernel driver which is compiled as a module (/system/wifi/ar6000.ko). The same driver is used by Carl, meaning they don't have a totally different wifi chipset. I searched in the forums and I saw that ZTE Blade users also had problems with wifi because there was no source available, but it was added from another device's kernel source at some point. Blade uses the same wifi chip as Racer and Carl.

I'm trying to find the kernel source that vamshi used as a base for his sources all day... they are a lot different than deadlink's(which are based on TomGiordano's sources, which now are part of official CM sources)

I'll post a logcat with my wifi problem

Ahhhh now I gotcha, I haven't seen that module source (nor I have search for it to be honest since it hasn't gave me problems), from 2.3 roms I've always saw that people just moved ar6000.ko around. With devices files for mooncake you can see it's used from prebuilt, never compiled, so don't know =/ if I find anything about I'll let you know

As for vamshi, I've no idea where he got his sources, I remember reading that he modified alot of things, including gpios, structs, and the like but beyond that I don't know. It's indeed different from deadlink's sources, deadlink for instance used synaptics-rmi driver to handled virtualkeys/keypad while vamshi didn't, deadlink also didn't change much beyond what Tom had in his sources, if I remember correctly deadlink at one point said that he only integrated board-mooncake, modified one kconfig, one makefile and msm_ts.

Edit:// Found this, see if it helps you out somehow

Edited by GuyOverThere, 11 October 2012 - 02:33 PM.

[mikeioannina]

I also found this repo: https://github.com/Z...TE-BLADE-2.6.32

With these commits they added ar6000 support:
https://github.com/Z...3eb26300f6d629c
https://github.com/Z...100ff72b6e7f0ab
https://github.com/Z...575e245bcbdeab4

I'm going to do some experiments in the next few days....

[mikeioannina]

The sources we use are based on blade's sources so they are a bit old and they don't include all the mooncake board variants and there are also camera/accelerometer/etc sources missing.

Interesting news, I just downloaded the last 2.6.32 that ZTE has on its website http://support.zte.c...?newsId=1001322
I found that there are a lot more defconfigs available, more accelerometer/camera drivers available (including the ones used in Carl) and I compared one of the defconfigs with my original froyo kernel config. They are nearly identical. Now I'm testing and compiling to see If the new sources work

[mikeioannina]

I compiled the sources with a .config similar to stock 2.2. It boots successfully but touchscreen isn't working. In dmesg I can see that compass is working.

[GuyOverThere]

The problem with official zte releases is that zte is popular for giving mangled, incomplete or otherwise broken sources since they remove binary blobs and other propietary things :-\ be careful with that.

Regarding touchscreen, check if it's really touchscreen not working or if it's a miscalibrated touchscreen, I mean, I've made tests where I though touchscreen wasn't working but it actually was, the problem being that x or y axis would give ridiculous numbers (like x:1256;y:8658) so android wasn't able to register the input. This is a problem with msm_ts.c, also check that it was indeed compiled (you have a msm_ts.o file).

board-mooncake.c can also affect calibration with this struct:

#if defined( CONFIG_TOUCHSCREEN_MSM_LEGACY)
struct msm_ts_platform_data msm_tssc_pdata ={
	.x_max = 239,
	.y_max = 319,
	.pressure_max =255,
};
#elif defined( CONFIG_TOUCHSCREEN_MSM)
struct msm_ts_platform_data msm_tssc_pdata = {
	.min_x = 0, 
	.max_x = 239, 
	.min_y = 0,
	.max_y = 319, 
	.min_press = 0, 
	.max_press =255,
	.inv_y = 955,
	.can_wakeup = false,
};
#endif

What it does is to define usable touchscreen area (it doesn't account keypad space because it doesn't have to) which is later used by msm_ts.c via TSSC_AVG_STATUS, TSSC_AVG_12, TSSC_AVG_34 and the like from msm_ts_platform_data. Now, bad offsets defined here can screw big time calibration, whatever it's used beyond "real" limits (the real size of the screen) needs to be accounted for and corrected in msm_ts.c before or while reporting via input_report_key();

[mikeioannina]

 GuyOverThere, on 16 October 2012 - 11:56 PM, said:

board-mooncake.c can also affect calibration with this struct:

What it does is to define usable touchscreen area (it doesn't account keypad space because it doesn't have to) which is later used by msm_ts.c via TSSC_AVG_STATUS, TSSC_AVG_12, TSSC_AVG_34 and the like from msm_ts_platform_data. Now, bad offsets defined here can screw big time calibration, whatever it's used beyond "real" limits (the real size of the screen) needs to be accounted for and corrected in msm_ts.c before or while reporting via input_report_key();

The touchscreen driver is compiled and loaded so the problem is incorrect calibration.

The quoted code from board-mooncake.c is exactly the same as mine, but in your sources they are way different

#elif defined( CONFIG_TOUCHSCREEN_MSM)
struct msm_ts_platform_data msm_tssc_pdata = {
	.min_x = 60,
	.max_x = 940,
	.min_y = 0,
	.max_y = 830,
	.min_press = 0,
	.max_press =255,
	.inv_y = 955,
	.can_wakeup = false,

I'm compiling now using msm_ts.c from and the above values from your repository

[GuyOverThere]

Yeah, that's because deadlink used the same offsets as tigex for board-mooncake.c (for the number they used, based on blade phones I think) which deadlink later accounted for in msm_ts.c, that's why you later see in msm_ts.c things like this:

#define TS_OFFSET_X -60
#define TS_OFFSET_Y 0
...



// > by deadlink
input_report_abs(ts->input_dev, ABS_X, x + TS_OFFSET_X);
input_report_abs(ts->input_dev, ABS_Y, y + TS_OFFSET_Y);
// < by deadlink

However, the driver I use for my phone doesn't use those values since to me it doesn't make sense when you can have the stock values in board-mooncake.c (min_x = 0; max_x = 239; max_y = 319) and later use something like:

input_report_abs(ts->input_dev, ABS_X, x);
input_report_abs(ts->input_dev, ABS_Y, y);

and even define x and y with values obtained from pointercal files from stock roms.

Set msm_tsdebug as 2 from a root console and check the values reported for x and y axis, that can gives you a hint at values currently used.

Edited by GuyOverThere, 17 October 2012 - 04:48 PM.

[mikeioannina]

Touchscreen is working correctly now using my earlier post... however I'll adapt the code again using your latest post to make it cleaner.
Thanks for helping me so far, I'm not a dev but I've been tinkering with android for a year... this phone was given as a gift to me so I decided to have some fun learning more about android & linux kernel things

EDIT: Camera is working now with the new sources too!

EDIT 2: Compiled new kernel with the modifications you mentioned, touchscreen doesn't work again

Edited by mikeioannina, 17 October 2012 - 08:00 PM.

[GuyOverThere]

If you're using "only" the stock values for board-mooncake.c but not pointercal values for msm_ts.c calibration won't work correctly, check this driver (is deadlink's) http://pastebin.com/f2sLQDV4

[mikeioannina]

I saw that msm_ts.c from pastebin earlier today but the soft buttons don't work with it. I'm working on the touchscreen all day... I hope something comes out of this, found lots of interesting stuff through my research.

EDIT: After looking & porting a lot of code I successfully use msm_ts.c from deadlink with some modifications to board-zte-mooncake.c with working virtual buttons/pinch-zoom/calibration except the virtual buttons don't vibrate. It seems that deadlink used kalltkaffe's sources for touchscreen & virtual buttons. Now I'm working on porting kalltkaffe's screen calibration and include it in RacerParts, almost done

Edited by mikeioannina, 18 October 2012 - 02:23 AM.