Question about kernel

[Guest GuyOverThere]

Hello all,

Is this really vamshi's kernel source? (github) If so, is this the latest? (meaning, #68 for gen1 devices)

Also, if this is vamshi's kernel, can someone tell me why the lack of msm_ts.c? I think I read somewhere that vamshi's seems to use msm_touch.c but I've also read that msm_touch.c is a different driver.

If the github link I posted isn't vamshi's kernel source, can someone point me to it? assuming of course he released the source :P

[Guest equiliym]

yeah thats the source someone gave me so i do think its vamshi's kernel src.. as for msm_ts, vamshis kernel goes with touch_to_key so he just uses msm_touch.c for touch driver and not for any softkeys.. not really sure what he did with that kernel, he made his mods and hacks for screen and v2 governor.. you can take a look at deadlinks source tho

[Guest GuyOverThere]

yeah thats the source someone gave me so i do think its vamshi's kernel src.. as for msm_ts, vamshis kernel goes with touch_to_key so he just uses msm_touch.c for touch driver and not for any softkeys.. not really sure what he did with that kernel, he made his mods and hacks for screen and v2 governor.. you can take a look at deadlinks source tho

Thanks mate, now, if I'm not mistaken, touch_to_key was written (or rewritten?) by deadlink but I believe deadlink uses msm_ts.c (or his custom msm_ts_racer.c), is it correct? does deadlink uses touch_to_key also? are there any source for touch_to_key? (I read that deadlink said there were not, but in the same post he said he was rewritting it, very confusing!)

Also, I know you tried with kernel .35 at some point before your pc went off, did you ever tried again?

Sorry to bother, really, I'm doing my best to gather info with what's already posted but everything is so dispersed between different threads and posts and people.... is all madness xD

[Guest equiliym]

touch_to_key was written by rexchun and he never gave any source for it.. deadlink doesnt use it, he goes via msm_ts to use softkeys, all other kernels use touchtokey for softkeys, thats added in init in ramdisk (boot.img)

um.. i was thinking of messing with kernels these days, i even forked some .35 and installed sdk and ndk but somewhat just.. dunno, less and less racer users so i dont feel like coding much >.>

no worries tho, do ask anything you need :)

[Guest GuyOverThere]

touch_to_key was written by rexchun and he never gave any source for it.. deadlink doesnt use it, he goes via msm_ts to use softkeys, all other kernels use touchtokey for softkeys, thats added in init in ramdisk (boot.img)

Ahhhh much appreciated, a shame there are no sources, although many source files that do exist from mods and hacks aren't documented at all so possibly my brain will just explode anyway :P but if I can learn anything is worth it

um.. i was thinking of messing with kernels these days, i even forked some .35 and installed sdk and ndk but somewhat just.. dunno, less and less racer users so i dont feel like coding much >.>

Understandable :)

but that means that I should hurry to learn everything I can of this things because you'll forget about the few racer guys left then? :c

no worries tho, do ask anything you need :)

Oh.... don't taunt me ;)

[Guest equiliym]

source of touchtokey isnt really needed, thats just a bin that makes softkeys work (home back menu), deadlink removed that and wrote his msm_ts to use those keys, chun did that too on his B02 rom which was quite nice if you dont include battery drainage >.>

meh, im happy with what i have atm, i would like 4.x too but its not a one man job to edit cm10 source to make it work, blade guys have a whole bunch of devs working on it and they still have errors.. cant even compare with me and my tryouts

[Guest GuyOverThere]

source of touchtokey isnt really needed, thats just a bin that makes softkeys work (home back menu), deadlink removed that and wrote his msm_ts to use those keys, chun did that too on his B02 rom which was quite nice if you dont include battery drainage >.>

But the battery drainage was because of msm_ts?

meh, im happy with what i have atm, i would like 4.x too but its not a one man job to edit cm10 source to make it work, blade guys have a whole bunch of devs working on it and they still have errors.. cant even compare with me and my tryouts

I'm not unhappy but I'm interested in seeing if I can somehow merge mods/hacks from vamshi's and deadlink's kernels, also, if I can upgrade to .35 or .37 even I'll be more happy :P not easy for me, I'm no dev but nobody is doing it and I got time so... ;)

Last night I started playing with .35-11 based on t0mm13b github's, I think that's the one you used last time. There have been errors everywhere, kittens have cried... but I'm fixing (?) things as I go, the real nightmare have been board-zte-mooncake.c :o editing includes, modifying pointers prototypes, changing declarations that have been modified (apparently) in .35, e.g. GPIO_ENABLE, GPIO_PULL_UP and the like are now GPIO_CFG_ENABLE, GPIO_CFG_PULL_UP ... at least that's what I understand from the files, I may be utterly wrong and even if I manage to compile it and flash it it's possible my phone explodes :P let's hope my gentoo years taught me anything :|

Edited August 10, 2012 by GuyOverThere

[Guest equiliym]

oh lol.. yeah that .35 is messed up badly, i really suggest you try a different one.. gsmarena says that racer is on msm7227 qualcomm and i tought it was on msm7627 so i dunno but i still suggest you try one of those .35 for msm7x27.. i forked konstat's kernel source for jellybean, i think its .35 and started editing it slowly, no rush.. its 7x27 so i think it should work on racer with proper editing.. not sure about ramdisk tho, might be worth decompiling konstats ramdisk and comparing it with vamshi's if you try to merge those two kernels..

and yeah, some strings were changed in .35 which suck badly for older configs -.-

[Guest GuyOverThere]

Yeah I saw it, forked it too. When I went to github searching for zte-kernel-msm7x27 I found several repos, seems various people have forked from everyone xD.

Now I've a question, KonstaT is going for jellybean, in the unlikely scenario I can compile that kernel porting things for mooncake, that kernel would still work under gingerbread?

I'll see what happens tonight when I get home with the one I started already then check konstat more indeep, at least it'll make my weekend fun :)

And yes, it seems at least according to the makefile that konstat is .35.7

Edited August 10, 2012 by GuyOverThere

[Guest equiliym]

i dont think there should be any problems, just needs to be coded properly, that kernel i think was coded for 2.3.x firstly then just had patches and stuff for it to work with 4.x android.. and being .35-7 it actually nice, i heard .35-11 had some issues, dunno

[Guest GuyOverThere]

Well, don't know if .35-11 had issues because of mainstream, custom patches and modifications or the like, but I dropped off that kernel completely, it was a nightmare, too many weird stuff in many places. Also it seems that deadlink uses heavily modified files like board-msm7x27.c and devices-msm7x27.c which make merging even worse O:

I started then with konstat msm7x27, also using vamshi's kernel source instead of deadlink's for porting and it has been much more easy, they're pretty compatible actually, and when merging isn't an option, adapting board-mooncake to .37 api changes have been simpler.

Right now I'm stuck at kgsl, the structure is very different between .37 and .32, let's see how that goes :P

Edit:

Well, I managed to compile it but it doesn't boot (given it's my first try this is expected lol). I can't get the logcat using adb because the phone starts, green android logo, the led is stuck in red and that's it so not really sure how am I gonna see what is wrong :P guess I'll spend few google-hours before I can report anything new

In the meantime, is there a way to get some debug info in this case? I don't know, is there a file or something created somewhere with info even if the phone doesn't boot? (unlikely I know, but miracles happen)

Edit 2:

Forgot to add, I've also had this bootloop using blade roms with our functional kernels (vamshi's or deadlink's) so don't know if there's only kernel error or maybe something else, perphaps something from ramdisk. I used racer kitchen (from tigex or ricky, don't remember) to change the kernel from vamshi's 2.6.32#68 boot.img, maybe I did something wrong there or who knows.

Anyway, I'm going to try to use the android emulator from the sdk to see if I can get some info while I keep googling :P

Edited August 11, 2012 by GuyOverThere

[Guest GuyOverThere]

Well it has to be a driver issue, made a few changes, compiled and flashed. Still hangs on boot but now the screen start to fade until it reach a palid grey color :P I still think I need to recompile something besides the kernel but don't know what lol

Also, anyone knows if vamshi posted his config somewhere? I'm unable to get it from /proc, is not there D:

[Guest GuyOverThere]

Well, there's somewhat progress I think D: sadly not with .35, although I think the related problems with that kernel not booting where because bad PHYS addresses (as related to kernel and as related to android ram management).

Since porting was a pain (given that I ain't no dev it isn't easy for me to change things...) I concentrated in getting first the sources for .32 compiled and working. With vamshi's there's no luck yet D: but seems there's in part problems with the config. Using deadlink's one gave me a really hard time but I've manage to compile his sources and boot with them. Seems the sources in his github aren't complete or at least updated to the 186/187 kernel we're able to use, he started the gen2 support but is not finished on those sources and the msm_ts.c isn't the correct driver either, the one he uses is quite different actually, I was lucky enough to find it in one of his posts.

Anyway, I have this .32 booting and seems that most things are working, there's something that it is not and that is virtualkeys, menu/home/back are completely dead, not really sure why yet.

I'm mostly trying to understand how .32 works to make my tests with .35 easier and possible even improve .32, right now I'm blocked by the virtualkeys thing but while I google more, if someone has any tips or clue or something I should be looking for it'll be appreciated, thanks! :D

[Guest Racerboy]

hi, well regards vamshi`s latest kernel config i guess he choose not to include the .config...........luckily vamshi`s earlier kernel does have a config that is accessible (#1) which can be found in my older 224 rom....

as for touch_to_key i think the cmd for it needs to be added in source of kernel, i`ve seen it around on another device... raise i think

best way forward would be to download blade source from Tom G on github (complete) then use config from vamshi #1 to boot/drivers/blah blah.....see what happens from that......

[Guest equiliym]

um.. touch_to_key is added to ramdisk, you can check it in vamshi or even old rexchun and tigtex? kernel.. here is the last edit in init.rc

#by geno

service geno /sbin/geno

    oneshot

service optimize /sbin/odex

    disabled

    oneshot

service timing /sbin/timing

    disabled

    oneshot

service touchtokey /system/bin/touch_to_key

    disabled

service vibrokeys /system/bin/vibrokeys

    disabled

on property:dev.bootcomplete=1

    start optimize

    start timing

    start touchtokey

    start vibrokeys

#by geno

[Guest GuyOverThere]

hi, well regards vamshi`s latest kernel config i guess he choose not to include the .config...........luckily vamshi`s earlier kernel does have a config that is accessible (#1) which can be found in my older 224 rom....

aha!!! I knew it wasn't my imagination!, I'll check that rom a get the config from there then :P many thanks racerboy!

um.. touch_to_key is added to ramdisk, you can check it in vamshi or even old rexchun and tigtex? kernel.. here is the last edit in init.rc

#by geno

service geno /sbin/geno

	oneshot

service optimize /sbin/odex

	disabled

	oneshot

service timing /sbin/timing

	disabled

	oneshot

service touchtokey /system/bin/touch_to_key

	disabled

service vibrokeys /system/bin/vibrokeys

	disabled

on property:dev.bootcomplete=1

	start optimize

	start timing

	start touchtokey

	start vibrokeys

#by geno

Ahhh that explains it xD my bad for not checking, although it always bother me... "how the kernel is going to call touch_to_key, it is like it magically knows is in /system/bin!"

I'll check those things, that should be enough to get vamshi's sources working I think. However, the dead virtualkeys are happening with deadlink sources :c they're defined by board-zte-mooncake-keypad.c and there's nothing wrong with that file as far as I can see... many things to check today, oh the joy :)

[Guest GuyOverThere]

Well, this is a bummer, thanks to the config from racerboy's rom I could get the kernel from vamshi's sources to boot, but... touchscreen doesn't work.

Now, I was asking why msm_ts.c was missing from his sources and while I don't know the reason I do think is needed, the only file related to msm touchscreen driver in vamshi's sources is drivers/input/touchscreen/msm_touch.c but this is a different driver, one that we don't use or need.

There's this defined in drivers/input/touchscreen/Kconfig at line 303:

config VAMSHI_TOUCHCAL

default n

depends on TOUCHSCREEN_MSM

bool "Touch calibration by vamshi"

help

   Say Y here if Calibration is to be done

Now, to this be usefull in anyway there has to be a corresponding:

#ifdef VAMSHI_TOUCHCAL

...calibration code...

#endif

in a .c file which is not and since msm_ts.c is missing my guess would be that it was in his msm_ts.c that this was used but that file isn't in his sources. I would believe that he decided to use his own modified driver with a different name and all but then again this is defined in the drivers/input/touchscreen/Makefile at line 31:

obj-$(CONFIG_TOUCHSCREEN_MSM) += msm_ts.o

and to this be compiled, msm_ts.c is required... and is missing... I tried to use another msm_ts.c but it didn't work. Also, don't know why but with this kernel, beyond the touchscreen not working, the phone boots in Safe mode...:

I/WindowManager(  866): SAFE MODE ENABLED (menu=1 s=-1 dpad=-1 trackball=-1)

when this should be the expected result:

I/WindowManager(  845): SAFE MODE not enabled

So yeah... the kernel boots, touchscreen doesn't work most likely due to msm_ts.c missing and it boots in safe mode...

Now if you'll excuse me, I think I'm gonna go cry under my bed now

[Guest equiliym]

yeah thats vamshis hack alright.. lemme check that file on his git for a sec..

his kconfig is totally different than the one i have.. i have a file with bunch of zte screens.. dunno where he pointed his driver since i didnt really mess with his sources much, i was mostly trying .35..

here, ill just quickly copy some conf on pastebin for you to add to your kconfig while this page idle's :P

aaand here it is, just copy the whole list to your kconfig file at the end but above endif tag.. after that try compiling again or even adding custom msm_ts but not sure if new msm_ts is needed since these arent really a msm configs.. anyway, you could try this msm_ts.c file.. not sure about source since i have few kernels i experimented with but worth a shot

note that all my pastebin links are set for 30 days

edit:

oyea for pointercal try using these offsets

17388 -76 -871728 119 25403 45240 65536

and for virtualkeys.msm-touchscreen these

0x01:102:30:350:40:60:0x01:139:120:350:50:60:0x01:158:210:350:40:60

might give a different sensitivity and touchy thing, cant remember the word on english at the moment >.>

Edited August 19, 2012 by equiliym

[Guest GuyOverThere]

Hold your horses!!! that msm_ts.c did work!!!! :D I had to add:

#ifdef CONFIG_TOUCHSCREEN_VIRTUAL_KEYS

struct kobject *android_touch_kobj;

static void touch_sysfs_init(void)

{

android_touch_kobj = kobject_create_and_add("board_properties", NULL);

if (android_touch_kobj == NULL) {

printk(KERN_ERR "%s: subsystem_register failed\n", __func__);

}


}

#endif

to his board-mooncake.c file to support the virtualkeys otherwise msm_ts.c wouldn't compile but is a progress! :o

Still is booting in safe mode and I don't know why but I'll check that in a momment

Also, what's the deal with the pointercal values? I see those used on deadlink's msm_ts.c but I don't see them in vamshi's... where are those defined do you know?

Anyhow, thank you very much!

Edit://

and vol+, vol- and menu doesn't work :P

Edit 2://

So, safe mode is accessed while pressing menu button while powering on the device, this makes me think that menu is being reported as active (pressed) the hole time during boot from the driver causing this safe mode boot, will check out :|

Edit 3://

Finally keys are working, bad definitions from mooncake-keypad.c

Edited August 19, 2012 by GuyOverThere

[Guest equiliym]

wait, those exact pointercal values are in deadlinks kernel?? i didnt know that D: well its possible when i think about his sensitivity a bit.. those are rexchuns values from his kernel that made calibration and sensitivity almost perfect p; not sure why vamshi doesnt have those, who knows how he calibrated the screen

just checked, deadlink uses different values for virtualkeys, i couldnt find any pointer values there :o

um.. have you checked key values? im not sure if they are in the kernel but i know rom does have them in /system/usr/.. i have a mooncake_keypad.kcm.bin in /system/usr/keychars and mooncake_keypad.kl in /system/usr/keylayout..

here's the keylayout file:

##########################################

#History:

#when	   who		 what, where, why

#--------   ----	    ---------------------------------------------------

#2010-01-27 zhangxian   new file for moonckae bord config

#2010-2-2   huoliping   Modify for Eclair. ZTE_KEYL_HLP_001

#2010-04-26 yeganlin    Modify for CAMERA side key

#...

##########################################

key 115   VOLUME_UP		 WAKE_DROPPED

key 114   VOLUME_DOWN	   WAKE_DROPPED

key 231   CALL			  WAKE_DROPPED

key 107   ENDCALL		   WAKE_DROPPED

key 102   HOME			  WAKE_DROPPED

key 59    MENU			  WAKE_DROPPED

key 158   BACK			  WAKE_DROPPED

key 226   HEADSETHOOK	   WAKE

[Guest GuyOverThere]

Yay!!!!... is working! is working! :D

[Guest GuyOverThere]

wait, those exact pointercal values are in deadlinks kernel?? i didnt know that D: well its possible when i think about his sensitivity a bit..

Yeah, I think they're same, this is what deadlink uses:

// values from pointercal (stock 2.2.2)

static int32_t msm_tscal_xscale = 17388;

static int32_t msm_tscal_xoffset = -871728;

static int32_t msm_tscal_yscale = 25403;

static int32_t msm_tscal_yoffset = 45240;

static int32_t msm_tscal_gesture_pressure = 1375; // optimized value

static int32_t msm_tscal_gesture_blindspot = 30;

static int32_t msm_tscal_pressure_limit = 200;

static int32_t msm_haptic_feedback = 1;

static int32_t msm_virtual_key_pressed = 0; // if virtual key pressed

static int32_t msm_zoomhack_enabled = 1; // enable zoomhack

static int32_t msm_tscal_min_jump = 30; // for dejitter

static int32_t msm_tscal_max_jump = 70; // for variance

but again, this is not from the msm_ts.c hi have in his github, is from another msm_ts.c hi posted about his zoomhack patch

Here's the complete file from deadlink http://pastebin.com/f2sLQDV4

Well, I don't know if "complete", with that stock file virtualkeys doesn't work, it is not because ts_keys_size array (I tested those values and they work with vamshi's kernel) but you can see many of his implementation of virtualkeys depends on not having config_touchscreen_virtual_keys enabled, is not entirely different from what other use, however most don't require you to have touchscreen_virtual_keys off

Edited August 19, 2012 by GuyOverThere

[Guest equiliym]

well it doesnt really matter, what matter is that it now works.. gratz ^_^

[Guest GuyOverThere]

yeah, calibration is wonky xD but I'll see what to do about that, I'm uploading the sources to my github in case of disaster from my part :P and if I get calibration less wonky then I can try again with .35 :D

[Guest equiliym]

lol yeah, newer kernel is somewhat of a good thing to have :P