23/Sep: Kernel Source

[Guest Frankish]

Then get back on at them about it.

[Guest rjm2k]

ok, didnt read and comprehend that in full. so if the term "newest sources" is true, then we are back to a gpl violation. they need to provide the sources for the binary they ship, exactly those and not somehow modified sources.

and you actually believe the crap about using one kernel for all phones? you can't be serious. that would mean they wouldn't be able to compile a new blade kernel right now. imagine an oem shortage, they need to replace a random piece of hardware. how would they implement that in the kernel, go back to start and do it all again? or just get an tarball from the kernel archives storage, patch the sources for the changed hardware, and compile the kernel... and exactly this tarball is what we want, and what they are obliged to give to us. not the latest source, but the sources they compiled the kernel shipped on the phones from. down to the last character.

Yes I believe them about one kernel, there is no reason why that can't be the case, after all the same linux kernel is used for many many different bits of hardware, it's just a matter of switching on the correct flags. The configs directory (kernel\kernel\kernel\arch\arm\configs) contains default configs for many ZTE devices eg

msm7627_blade_P330_defconfig

msm7627_blade_P729B_defconfig

msm7627_defconfig

msm7627_joe_defconfig

msm7627_mooncake_defconfig

msm7627_mooncake_P726CU_defconfig

msm7627_mooncake_P726C_defconfig

msm7627_mooncake_P726G_defconfig

msm7627_mooncake_P726N_defconfig

msm7627_mooncake_P726US_defconfig

msm7627_mooncake_P726VV_defconfig

msm7627_mooncake_R750_defconfig

msm7627_r750_defconfig

msm7627_raise_defconfig

msm7627_smooth_P728H_defconfig

I think that unfortunatly they are just pretty poor at code management, making the kernel work for a new phone has broken it for old ones. From what they have told me, the second attempt at releasing source actually was an attempt to re-create the source that they had used and since lost through modification.

There really is nothing we can do at the moment other than keep on good terms with them, gpl violations may have happened but we can't do anything about it, even if you set the lawyers onto them they simply appear to no longer have the correct source! The V880 gets released in a months time so I'm hoping that when they release the source for that it will be the correct source, since they know in advance that we are expecting it.

[Guest oh!dougal]

....

I think that unfortunatly they are just pretty poor at code management, making the kernel work for a new phone has broken it for old ones. From what they have told me, the second attempt at releasing source actually was an attempt to re-create the source that they had used and since lost through modification.

There really is nothing we can do at the moment other than keep on good terms with them, gpl violations may have happened but we can't do anything about it, even if you set the lawyers onto them they simply appear to no longer have the correct source! The V880 gets released in a months time so I'm hoping that when they release the source for that it will be the correct source, since they know in advance that we are expecting it.

I think its important that they understand that their obligation is to retain (and publish) "snapshots" taken at the particular time that a product is "signed off" to production.

They can continue to tinker with it as they develop new products, but their obligation is to publish what the product has.

Not what their combo-source looked like when the product eventually went on public sale, but what it looked like when they said "good enough, lets go with that".

And the IMPORTANT consequence of that is that, if 2.2 is due out in a matter of weeks, they may already have passed the stage of finalising the 2.2 Blade code. What worries me is that they might already be cannibalising the 2.2 source for their next product.

We need to be ensuring that someone with compliance responsibility (there must be someone at ZTE, surely?) makes certain that a snapshot is taken at the time when the code is frozen for production.

Sure it doesn't need to be published until sales start, but the snapshot needs to have been taken in advance of production and sales.

Edited November 17, 2010 by oh!dougal

[Guest oh!dougal]

reply from zte re wifi sleeping, not sure it really helps!

That's comes from our developers. for you issue about the " Blade Sleeping "

In most cases it's not a hardware limitation. It's about power consumption. Power consumption is a very important aspect of user experience. If you keep everything working when the phone goes to sleep, you will definitely suffer a battery drain. I think Android has provides you UI interfaces to control the behaviour of some hardware modules when the phone goes to sleep (if it makes sense to have that module on during sleeping). For example, you can have the bluetooth module working when the phone sleeps. But surely it will incur a power consumption penalty. It's up to you. For many other haredware modules, We don't see any reason to have them on when the phone is suspended. ...

Strangely enough, I can't find where on the phone I have any control of the behaviour of Bluetooth while sleeping! (I think it stays on while sleeping, ... )

I also note that in the 7k_handset.kl file, "HEADSETHOOK" is defined with a "WAKE" action. However, the button on the SF's wired headset does not wake the phone - either from proper sleep or from screen-only-sleep (on usb/charger).

Presumably the module behind the headset socket is powered down in sleep.

Similarly, pressing the equivalent button on my Bluetooth headset does not wake the phone either.

From the HEADSETHOOK definition, it would seem that there might be some diversity of opinion within ZTE as to what the phone should be doing. Perhaps this could be offered to them for clarification?

[Guest rjm2k]

Strangely enough, I can't find where on the phone I have any control of the behaviour of Bluetooth while sleeping! (I think it stays on while sleeping, ... )

I also note that in the 7k_handset.kl file, "HEADSETHOOK" is defined with a "WAKE" action. However, the button on the SF's wired headset does not wake the phone - either from proper sleep or from screen-only-sleep (on usb/charger).

Presumably the module behind the headset socket is powered down in sleep.

Similarly, pressing the equivalent button on my Bluetooth headset does not wake the phone either.

From the HEADSETHOOK definition, it would seem that there might be some diversity of opinion within ZTE as to what the phone should be doing. Perhaps this could be offered to them for clarification?

have I added you to the zte list, if not, pm me your email address and I will add you so you can pass this on yourself if you like

[Guest Frankish]

Should that action not be WAKE_DROPPED? I don't know too much but i know adding that to the desire keypad.kl makes the phone wake up with Desired button press.

[Guest oh!dougal]

Should that action not be WAKE_DROPPED? I don't know too much but i know adding that to the desire keypad.kl makes the phone wake up with Desired button press.

What it SHOULD be is another thing entirely!

That is what it says (so act on it, ie wake, then pass the event on to a running app for it to do something). If it was 'dropped' then the event would wake the phone and then be dropped, ie not passed on, so that the first press wakes the phone only and has no other action.

If you read back a few pages, you'll see that 1/ editing the 7k_keypad.kl file to add more wake_dropped keys is ineffective (those keys are de-activated during sleep, so can't signal wake up) and 2/ ZTE are under the misapprehension that that file does NOT have to do with waking the phone's computer from sleep, only relighting the screen when that is the only thing powered down (eg when on usb/charge, or when playing music) - but they are confused!

Read earlier in this thread.

Fact is - the headset button has no wake-up effect. But it ought to according to the file.

Edited November 17, 2010 by oh!dougal

[Guest rjm2k]

ZTE....

Thanks for your mail.

I used another model ZTE android smartphohe named P722G to reappear your issues, then i find that our P722G would flash his LED every 1 minutes in the sleeping mode. In the waking up mode, the LED would flash its LED every 3 seconds.

I have found Blade in my table but when i used it to reappear your issues i found that it was an Chinese version Blade, there was no LED in the front of the handset. So I found that i have no idea on your problem this night. I will try to find an England version Blade to reproduce your matter tomorrow.

.....

I found the frequence problem and i have passed this issue to the user experience promoting project manager.

I think he will glad to get a so big user exerience promoting point B)

Edited November 18, 2010 by rjm2k

[Guest oh!dougal]

ZTE....

...

I have found Blade in my table but when i used it to reappear your issues i found that it was an Chinese version Blade, there was no LED in the front of the handset. So I found that i have no idea on your problem this night. I will try to find an England version Blade to reproduce your matter tomorrow.

.....

I found the frequence problem and i have passed this issue to the user experience promoting project manager.

I think he will glad to get a so big user exerience promoting point B)

Very simple.

Only standard software running and no apps interfering with sleep.

Attach charger

Call the Blade, let the Blade ring, then cancel the call (at the other phone)

Blade shows missed call at the top of the screen. (LED does not flash). No problem.

Put the Blade to screen sleep (charger still attached). Notification led flashes. No problem. (Its not bright, it is hard to see in daylight, but it does flash! About once per second.)

Notification does work ... BUT ...

Unplug from the charger. Phone wakes to lock screen showing the missed call, led continues flashing. Still no problem.

Wait for the lock screen to time out.

When the screen goes off, the led gives one more flash and goes out.

It does not flash at all (not even once per minute) in real sleep.

The notification led works -- except when the phone is in sleep.

ADDED - Is it really true that the Chinese one has no such led? (The Hungarian version with lcd display and 256k like the Chinese spec does have the led.)

Edited November 18, 2010 by oh!dougal

[Guest popoyaya]

Here is a new app to choose led color and frequency for gmail, SMS, missed calls, battery and disk space notifications...

http://forum.xda-developers.com/showthread.php?t=837057

[Guest The-One]

Problem is that when the phone sleeps it starts ignoring the signals from these kind of apps..

[Guest rjm2k]

hmm, they aren't really getting it (already told them about the wifi sleep policy being ignored), though maybe now he will understand

I found a switch in the menu to solve your problem "wifi chip sleeping".

in the "setting" program, "wireless & networks" , WLAN setting. Then press menu button to call up the menu .then select "advanced".

Can you find the menu like the follow pic in your Blade?

[Guest rjm2k]

Anyone got time to try the source for the wifi driver mentioned in here?!

http://android.modaco.com/index.php?s=&amp...t&p=1483557

Might be worth a few ppl taking a clone of that tree just in case it's not supposed to be public!

Ah, hang on, not sure it actually is the source, just binary?

Someone blogged about using this source

http://armin762.wordpress.com/2010/05/24/n...s-6002-working/

and another atheros git here http://git.chromium.org/gitweb/?p=atheros.git;a=tree

Does appear to be source and it says it's GPL too so wonder why ZTE have been so funny about releasing their copy?

Edited November 22, 2010 by rjm2k

[Guest oh!dougal]

Anyone got time to try the source for the wifi driver mentioned in here?!

http://android.modaco.com/index.php?s=&amp...t&p=1483557

...

PLEASE NOTE - that link is for 2.2 FroYo (despite what it might say)

For 2.1 you should scroll down 6 posts or click here http://android.modaco.com/index.php?s=&amp...t&p=1483645

Edited November 22, 2010 by oh!dougal

[Guest rjm2k]

PLEASE NOTE - that link is for 2.2 FroYo (despite what it might say)

For 2.1 you should scroll down 6 posts or click here http://android.modaco.com/index.php?s=&amp...t&p=1483645

Actually, stackrish has compiled this source for both 2.2 and 2.1

[Guest oh!dougal]

Actually, stackrish has compiled this source for both 2.2 and 2.1

Yes but at least one person had a problem with the combined version -- hence stackrish posting the 2.1 only version, in the post I linked ... !

Just read the posts between the two version links!

I did ... and that was why I put "despite what it might say" to make clear about the first version NOT being best for 2.1 ....

And strangely from your own post (number 14 in that thread) it looks very much as though it was the 2.1 version that YOU chose to download for your own 2.1 phone ... B)

http://android.modaco.com/index.php?s=&amp...t&p=1483666

Edited November 22, 2010 by oh!dougal

[Guest rjm2k]

OK, ZTE have released new source, lets hope it's correct!

"

We have finished checking work and i have released the code in the same adress as http://support.zte.com.cn/support/news/New...?newsId=1000304

We corrected the multi-touch gesture issue and made a compatible in the different LCD.

"

[Guest goatee]

Great news B). Let's hope it compiles. .

OK, ZTE have released new source, lets hope it's correct!

"

We have finished checking work and i have released the code in the same adress as http://support.zte.com.cn/support/news/New...?newsId=1000304

We corrected the multi-touch gesture issue and made a compatible in the different LCD.

"

[Guest igors_s]

downloaded 1-6, just 2 files left.

will upload to mediafire as a single archive when done.

[Guest Jon_V]

I've updated the github repo at https://github.com/jvaughan/san-francisco-kernel with the new code (branch zte/2.6.29)

To explain the branches of this repository:

caf/2.6.29-closest-to-zte - the commit from the code aurora repository that was found to be closest to ZTE's 2010-11-01 release.

zte/2.6.29 - unaltered code from ZTE, starting with the 2010-11-01 release being committed on top of the above branch. Now updated to 2010-11-23 code.

shyde/2.6.29 - Stephen Hyde's kernel with fixes to the power button, battery reporting, and attempt at overclocking.

jvaughan/2.6.29-eclair-fixes - A branch for fixes required to get the kernel working in Eclair. So far includes fixes from shyde/2.6.29.

If people are working on the kernel, then I'd be very happy to incorporate their branches / fixes (with full credit to them). If using github then i'll happily merge in their changes that way, otherwise get in touch with me.

Cheers.

Jon

[Guest rjm2k]

I've updated the github repo at https://github.com/jvaughan/san-francisco-kernel with the new code (branch zte/2.6.29)

To explain the branches of this repository:

caf/2.6.29-closest-to-zte - the commit from the code aurora repository that was found to be closest to ZTE's 2010-11-01 release.

zte/2.6.29 - unaltered code from ZTE, starting with the 2010-11-01 release being committed on top of the above branch. Now updated to 2010-11-23 code.

shyde/2.6.29 - Stephen Hyde's kernel with fixes to the power button, battery reporting, and attempt at overclocking.

jvaughan/2.6.29-eclair-fixes - A branch for fixes required to get the kernel working in Eclair. So far includes fixes from shyde/2.6.29.

If people are working on the kernel, then I'd be very happy to incorporate their branches / fixes (with full credit to them). If using github then i'll happily merge in their changes that way, otherwise get in touch with me.

Cheers.

Jon

are you keeping a repository with a copy of the 2 sources for atheros drivers that have been found?

[Guest oh!dougal]

OK, ZTE have released new source, lets hope it's correct!

"

We have finished checking work and i have released the code in the same adress as http://support.zte.com.cn/support/news/New...?newsId=1000304

We corrected the multi-touch gesture issue and made a compatible in the different LCD.

"

Have ZTE been specifically asked to take (for later publication) a snapshot of the frozen-for-production version of 2.2?

Naturally, publication would only follow product release, but the thing they need to do is to take that snapshot at the point when they sign-off the code for production.

With the product said to be for release in mid-December, the time of firmware sign-off is likely to be about now. (Judging by the time from build date to sales of the Hungarian version.) So its about now that they should be archiving their copy ...

Edited November 23, 2010 by oh!dougal

[Guest Jon_V]

are you keeping a repository with a copy of the 2 sources for atheros drivers that have been found?

Not at present. Does anyone have a working build yet with those atheros sources?

[Guest rjm2k]

Have ZTE been specifically asked to take (for later publication) a snapshot of the frozen-for-production version of 2.2?

Naturally, publication would only follow product release, but the thing they need to do is to take that snapshot at the point when they sign-off the code for production.

With the product said to be for release in mid-December, the time of firmware sign-off is likely to be about now. (Judging by the time from build date to sales of the Hungarian version.) So its about now that they should be archiving their copy ...

Yes

"Since it appears the 2.1 kernel source was out of step with the kernel binary on the sanfrancisco, I've been asked to check that the 2.2 source you will eventually release will be a snapshot taken at the time the kernel that will go into production use on the phone was built, that way the source will match the kernel binary since there will have been no changes to the source since the phone was released?"

Edited November 23, 2010 by rjm2k

[Guest oh!dougal]

Yes

Excellent! B)

And have they responded to that request in a form that should engender hope or despair?