Guest GuyOverThere Posted August 20, 2012 Report Share Posted August 20, 2012 (edited) 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 :P 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 August 22, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted August 22, 2012 Report Share Posted August 22, 2012 (edited) 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 :P (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 :mellow: Edited August 22, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest massacre^ Posted August 22, 2012 Report Share Posted August 22, 2012 Way to go ! congo :] Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 10, 2012 Report Share Posted October 10, 2012 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? Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 10, 2012 Report Share Posted October 10, 2012 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. Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 10, 2012 Report Share Posted October 10, 2012 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 Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 11, 2012 Report Share Posted October 11, 2012 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. Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 11, 2012 Report Share Posted October 11, 2012 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? Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 11, 2012 Report Share Posted October 11, 2012 (edited) 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 October 11, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 11, 2012 Report Share Posted October 11, 2012 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 Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 11, 2012 Report Share Posted October 11, 2012 (edited) 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 October 11, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 11, 2012 Report Share Posted October 11, 2012 I also found this repo: https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32 With these commits they added ar6000 support: https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32/commit/39e4ddf8859ff8fef42816f703eb26300f6d629c https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32/commit/78cd24c46e070d16ac206dff1100ff72b6e7f0ab https://github.com/ZTE-BLADE/ZTE-BLADE-2.6.32/commit/ab0faf82a214c4c141d9c1da0575e245bcbdeab4 I'm going to do some experiments in the next few days.... Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 16, 2012 Report Share Posted October 16, 2012 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.com.cn/support/news/NewsDetail.aspx?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 Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 16, 2012 Report Share Posted October 16, 2012 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. Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 16, 2012 Report Share Posted October 16, 2012 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(); Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 17, 2012 Report Share Posted October 17, 2012 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 Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 17, 2012 Report Share Posted October 17, 2012 (edited) 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 October 17, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 17, 2012 Report Share Posted October 17, 2012 (edited) 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 :P 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 October 17, 2012 by mikeioannina Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 17, 2012 Report Share Posted October 17, 2012 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 Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 18, 2012 Report Share Posted October 18, 2012 (edited) 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 October 18, 2012 by mikeioannina Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 18, 2012 Report Share Posted October 18, 2012 (edited) 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 :) deadlink used synaptics-rmi for the keypad however is not needed, what I did for my driver was to add the following in msm_ts.c in function msm_ts_probe: input_set_capability(ts->input_dev, EV_KEY, BTN_TOUCH); set_bit(EV_ABS, ts->input_dev->evbit); #if defined(CONFIG_TOUCHSCREEN_VIRTUAL_KEYS) set_bit(EV_KEY, ts->input_dev->evbit); set_bit(KEY_HOME, ts->input_dev->keybit); set_bit(KEY_MENU, ts->input_dev->keybit); set_bit(KEY_BACK, ts->input_dev->keybit); #endif input_set_abs_params(ts->input_dev, ABS_MT_POSITION_X, pdata->min_x, pdata->max_x, 0, 0); ... Also, you need to be sure (if you use the virtualkey support) that you have the correct values for the array_size: #if defined(CONFIG_TOUCHSCREEN_VIRTUAL_KEYS) #define virtualkeys virtualkeys.msm-touchscreen #if defined(CONFIG_MACH_MOONCAKE) static const char ts_keys_size[] = "0x01:102:30:350:40:60:0x01:139:120:350:50:60:0x01:158:210:350:40:60"; #elif defined(CONFIG_MACH_V9) static const char ts_keys_size[] = "0x01:102:70:850:60:50:0x01:139:230:850:60:50:0x01:158:390:850:60:50"; #endif Of course, in my case I need to compile the kernel with virtualkeys support (which deadlink didn't need since he used synaptics-rmi), also, this would allow to use touch_to_key to get haptic feedback on the keys, so for my kernel I have initramfs with touch_to_key support enabled and touch_to_key in /system/bin. I don't know yet however how to implement haptic feedback without touch_to_key, never really bother with it to be honest. Also, thanks for reporting, this has reminded me that I need to update that fricking msm_ts driver in my github xD Edited October 18, 2012 by GuyOverThere Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 23, 2012 Report Share Posted October 23, 2012 (edited) I was trying for many days to port 2.6.35.7 and today for the first time the device boots to lockscreen but touchscreen isn't working yet EDIT: Touchscreen is working (it was just a calibration issue), now I'm having some framebuffer bugs (screen doesn't refresh, artifacts appear) Edited October 23, 2012 by mikeioannina Link to comment Share on other sites More sharing options...
Guest GuyOverThere Posted October 24, 2012 Report Share Posted October 24, 2012 I was trying for many days to port 2.6.35.7 and today for the first time the device boots to lockscreen but touchscreen isn't working yet EDIT: Touchscreen is working (it was just a calibration issue), now I'm having some framebuffer bugs (screen doesn't refresh, artifacts appear) Awesome!!! :D Is wifi still dead? Link to comment Share on other sites More sharing options...
Guest mikeioannina Posted October 24, 2012 Report Share Posted October 24, 2012 I can't test wifi (or anything else) because the screen is distorted as you can see in the screenshot I posted in my other thread Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now