23/Sep: Kernel Source

[Guest WigglerAway]

Prior to ZTE announcing they were working on releasing the correct source I was working on reverse engineering the kernel. I shelved the work when ZTE acknowledged they had linked to the wrong source so not to waste my time.

The issue with the power button is due to an incorrect rpc_server_handset.c file. If anyone is in contact with ZTE please see if they can 'find' the correct version of this file.

In the mean time, I may have found the cause of the issue. I don't have the time to set up a build environment, so can someone test a patch for me?

[Guest Jon_V]

Prior to ZTE announcing they were working on releasing the correct source I was working on reverse engineering the kernel. I shelved the work when ZTE acknowledged they had linked to the wrong source so not to waste my time.

The issue with the power button is due to an incorrect rpc_server_handset.c file. If anyone is in contact with ZTE please see if they can 'find' the correct version of this file.

In the mean time, I may have found the cause of the issue. I don't have the time to set up a build environment, so can someone test a patch for me?

Hi,

The issue can be solved with a different keymap file - see the thread at http://android.modaco.com/content/zte-blad...clocked-kernel/

[Guest Nick Rhodes]

Not sure if that's 'was' or 'was not' :)

Aaah, but the current draw will increase with higher clock speed (at the same voltage). IIRC with CMOS its pretty linear.

And heating is proportional to the square of the current.

So 1/3 more clocks/sec (6->800), about 1/3 more current, means about 75% more heat ... ! And, compared to 600, 864 would be generating over double the heat.

As long as the heat can be sufficiently removed to keep the CPU at operating temps should not be a problem.

Another thing to consider is the GPU is integrated so a proper stress test should exercise the CPU and GPU at 100%

Cheers Nick.

[Guest rjm2k]

Prior to ZTE announcing they were working on releasing the correct source I was working on reverse engineering the kernel. I shelved the work when ZTE acknowledged they had linked to the wrong source so not to waste my time.

The issue with the power button is due to an incorrect rpc_server_handset.c file. If anyone is in contact with ZTE please see if they can 'find' the correct version of this file.

In the mean time, I may have found the cause of the issue. I don't have the time to set up a build environment, so can someone test a patch for me?

Ok I've passed on your comment.

Edited November 3, 2010 by rjm2k

[Guest WigglerAway]

Hi,

The issue can be solved with a different keymap file - see the thread at http://android.modaco.com/content/zte-blad...clocked-kernel/

If a non-standard keymap is the root cause of the problem then the existing fix is perfect otherwise it'd better to fix it in the kernel.

There is also two other events that are mapped to wakeup events in the binary kernel that are unmapped in the source. Has anyone running the source kernel experienced the phone not waking up when it should? eg. incoming calls, messages, alarms etc.

[Guest rjm2k]

If a non-standard keymap is the root cause of the problem then the existing fix is perfect otherwise it'd better to fix it in the kernel.

There is also two other events that are mapped to wakeup events in the binary kernel that are unmapped in the source. Has anyone running the source kernel experienced the phone not waking up when it should? eg. incoming calls, messages, alarms etc.

Do you know what the events are?

[Guest WigglerAway]

Do you know what the events are?

0x78 and 0x79 :)

I don't know what causes them. They come over the rpc interface.

Edited November 3, 2010 by WigglerAway

[Guest Spooke]

Is anyone working on a ROM using the source now??

[Guest Stephen Hyde]

yep :)

[Guest WigglerAway]

0x78 and 0x79 :)

I don't know what causes them. They come over the rpc interface.

Ah, they're events which update the battery status. Perhaps low battery notifications?

[Guest kag8]

yep :)

yay! :)

[Guest rjm2k]

Things are looking even more positive at the moment, I've managed to get some of the ZTE staff including a software developer to join a mailing list for direct communication with us. This is a closed list for kernel/android developers only so if anyone who is working on the kernel and has used all other channels for help then pm me your email with a description of what you are working on and what you need from ZTE and I will look at adding you.

[Guest oh!dougal]

Things are looking even more positive at the moment, I've managed to get some of the ZTE staff including a software developer to join a mailing list for direct communication with us. This is a closed list for kernel/android developers only ...

Congratulations on a brilliant feat of diplomacy!

Now, about a filtered direct feedback route to let them know about well-established 'quirks' affecting ordinary users ... :)

[Guest rjm2k]

Congratulations on a brilliant feat of diplomacy!

Now, about a filtered direct feedback route to let them know about well-established 'quirks' affecting ordinary users ... :)

I have thought about that, not sure what the best approach is since many of the quirks could probably be dealt with by developers on here without needing to involve ZTE directly. Obviously our main goal is to get Froyo, which ZTE won't be too interested in hearing issues about from users other than those in China, the way I see it is that the forums and devs on here need to be the first port of call, with them working with ZTE where necessary.

Maybe a wiki or some other list which summarises issues, with the ones that can't be dealt with be volunteers being sent on to ZTE?

maybe a bucktracker of some kind, a tracker on sourceforge for example?

Any ideas?

Edited November 4, 2010 by rjm2k

[Guest goatee]

How about a Wiki? I'm happy to host one for free.

I have thought about that, not sure what the best approach is since many of the quirks could probably be dealt with by developers on here without needing to involve ZTE directly. Obviously our main goal is to get Froyo, which ZTE won't be too interested in hearing issues about from users other than those in China, the way I see it is that the forums and devs on here need to be the first port of call, with them working with ZTE where necessary.

Maybe a wiki or some other list which summarises issues, with the ones that can't be dealt with be volunteers being sent on to ZTE?

maybe a bucktracker of some kind, a tracker on sourceforge for example?

Any ideas?

[Guest Stuart_f]

How about a Wiki?

Like this one?

[Guest goatee]

Like this one?

exactly like that one! :)

[Guest rjm2k]

Like this one?

That's ok for us but most of the issues in there are actually down to the modding process, we wouldn't want to waste ZTE time with those, eg

Network Unlocking - this is a feature that we like, nothing for ZTE to do

Resolution Change - this was down to Stephen I think, he just likes this resolution so created the alpha release with it set, easy to fix

Virtual Network Names - Not sure what causes this but I would expect the devs here to be able to fix it through changes to a config file foe example the APN file has been copied from another rom

We really need something like a tracker on sourceforge so that we can log, prioritise and allocate/resolve issues, with the ones we can't deal with getting passed onto ZTE. We can't have an unmoderated list otherwise ZTE may well lose interest

[Guest oh!dougal]

That's ok for us but most of the issues in there are actually down to the modding process, we wouldn't want to waste ZTE time with those,...

... We can't have an unmoderated list otherwise ZTE may well lose interest

Damn right.

Sebastian404 has indicated that Orange are working on some sort of r2 (but importantly still on 2.1).

Dunno whether there's any changes in the ZTE-supplied stuff or just the Orange-bundled apps (and maybe taking out things like the FCC test app!)

However, the basic reality seems to be that Orange's Blade looks like shipping with 2.1 for some time to come.

Hence ZTE are going to be getting 2.1 support demands from Orange.

This makes me think that ZTE might see it as a benefit to get a cleaned-up idea of real customer feedback, BEFORE Orange come back with their ideas of what problems there might be.

[Guest rjm2k]

I see that Modaco has a bug tracker, wonder if Paul would setup trackers for the Blade Stock 2.1, Custom 2.1 and Froyo for us?

[Guest Jon_V]

I see that Modaco has a bug tracker, wonder if Paul would setup trackers for the Blade Stock 2.1, Custom 2.1 and Froyo for us?

Github has a pretty basic issues tracker at https://github.com/jvaughan/san-francisco-kernel/issues - obviously this would only apply to the kernel..

[Guest screwface]

Things are looking even more positive at the moment, I've managed to get some of the ZTE staff including a software developer to join a mailing list for direct communication with us. This is a closed list for kernel/android developers only so if anyone who is working on the kernel and has used all other channels for help then pm me your email with a description of what you are working on and what you need from ZTE and I will look at adding you.

.32 kernel + source.

Edited November 5, 2010 by screwface

[Guest jimmy2x2x]

Now that ZTE has released the source, and it looks like they are getting involved with the community (which is amazing, well done ZTE!)

Are there still issues compiling a vanilla 2.1 rom?

[Guest rjm2k]

.32 kernel

What about it?

[Guest Spooke]

What about it?

He wants you to get that??

what you need from ZTE