23/Sep: Kernel Source

[Guest cobhc]

It all seems rather shambolic to me.

Quite how a company which designs such high-tech devices (and does it pretty well in the case of the Blade) can be so lax with their website and/or keeping track of the source code for devices is really beyond me.

Maybe that's where the company is able to keep the cost of the phones down, by not employing much staff in the way of support/web maintenance.

[Guest rjm2k]

Update from ZTE.......

Hi, for your issues.

1.all our open source code point to the same source.

Our R&D engineer are so lazy that they integrated all the code into one copy :rolleyes:

If you have another model ZTE Android phone such as ZTE-link, you can find that our code can running on it cheerful.

2.Now i invited a developer to join the maillist.

3.The developers assure me that they are working for your issus such as "sleeping problem" and "wifi driver".

4.X and me find a problem that we cannot get the mail which another one send to the maillist.Is this right？

re "It would be helpful if you could provide any of the files under the /device/ZTE android source tree, things like BoardConfig.mk and so on, this would help us to setup the Android build environment correctly. I don't think there are any private files in there but if there are just don't send them but if would be helpful to know the names of any files you can't sent."

I'm so sorry to told you that we can not give these data after careful consideration.This action do not meet ZTE information security regulations because our competitors can get confidential information from this action.

Edited November 10, 2010 by rjm2k

[Guest rjm2k]

Just some further information on this; the version of the code we're looking for is:

Atheros AR6002 olca driver version 2.2.1.103 maintainer [email protected]

This is the path it was compiled under:

/home/tanbaihua/P729B/P729B_USR/android_b09/kernel/../vendor/zte/olca/host/os/linux/ar6000_drv.c

In light of the above post where ZTE say they can't release the stuff under the device/ or vendor/ tree it might be worth contacting the maintainer above to see if he will point out that the wifi code is open source and that they must release it?

I thought the wifi stuff was part of the kernel anyway, even if it's a loadable module, or is it completely seperate?

[Guest Stephen Hyde]

looks partially like thats being built under the android tree to me

[Guest mELIANTE]

Are they serious??

This is getting dark... :rolleyes:

[Guest Nick Rhodes]

An interesting and worrying implication of all of this is that ZTE have clearly little or no Source Code control and have in fact lost the code that was used to produce the Kernel for the SF as delivered to Orange. Any professional outfit should be able to quickly identify and re-build the source that was delivered into production no matter what has happened or been released since. Orange should also have been sent the Source for the kernel that they have sold to people.

Ouch.

As Orange are the ones distributing the San Francisco it is their legal responsibility to provide the sources (due to the GPL licence of the Linux kernel and any other GPL licensed software included)...

[Guest goatee]

Ouch.

As Orange are the ones distributing the San Francisco it is their legal responsibility to provide the sources (due to the GPL licence of the Linux kernel and any other GPL licensed software included)...

I need to dig out the SIM card that came with my phone, and register it, so I can contact Orange support, and ask for the source.

[Guest rjm2k]

oh, missed part of the response....

about wifi driver, our developer told me that this code is provided by a third party company, so we do not have any permission to public this code.

so I wonder who this 3rd party is, they should be releasing the code as it's GPL I guess?

[Guest Nick Rhodes]

In light of the above post where ZTE say they can't release the stuff under the device/ or vendor/ tree it might be worth contacting the maintainer above to see if he will point out that the wifi code is open source and that they must release it?

I thought the wifi stuff was part of the kernel anyway, even if it's a loadable module, or is it completely seperate?

It is possible to link closed source librarys and modules with open source code, the lGPL v3 has provisions for this I believe. Could well be the firmware (which is commonly soft-loaded on WiFi devices) that is the issue - could well be a binary blob, no source provided.

Cheers, Nick

[Guest rjm2k]

Looks like the wifi is by samsung (based on my MAC address), or Atheros (code) can we find code elsewhere for it? Is it the firmware or the kernel driver we need?

Edited November 10, 2010 by rjm2k

[Guest deltronuk]

Looks like the wifi is by samsung (based on my MAC address), or Atheros (code) can we find code elsewhere for it? Is it the firmware or the kernel driver we need?

Already tried the AR6K code from Nvidia Tegra sources and the code from a ZTE 1.6 release. The first didn't work at all and the second did partially but only in test mode.

What needs to be made clear here is that the Linux kernel is GPL *not* LGPL. Hence you may not legally load a proprietary module into the kernel because the act of doing so makes it a derivative work. Manufacturers such as NVIDIA get around this by coding a stub module that then interacts with a binary blob (for which they do not need to provide the source code). I believe this is what Atheros does in their driver (have a look at the .bin files in /system/wifi). The issue is not that there is binary blobs involved - we just do not have working source code for the ar6000 kernel module that is shipped with the Blade.

ZTE have previously released the source code for the AR6000 wifi driver, so there is no legitimate reason why they cannot release the code that works with the 6002 chip in the Blade.

Note: IANAL! :rolleyes:

[Guest rjm2k]

Already tried the AR6K code from Nvidia Tegra sources and the code from a ZTE 1.6 release. The first didn't work at all and the second did partially but only in test mode.

What needs to be made clear here is that the Linux kernel is GPL *not* LGPL. Hence you may not legally load a proprietary module into the kernel because the act of doing so makes it a derivative work. Manufacturers such as NVIDIA get around this by coding a stub module that then interacts with a binary blob (for which they do not need to provide the source code). I believe this is what Atheros does in their driver (have a look at the .bin files in /system/wifi). The issue is not that there is binary blobs involved - we just do not have working source code for the ar6000 kernel module that is shipped with the Blade.

ZTE have previously released the source code for the AR6000 wifi driver, so there is no legitimate reason why they cannot release the code that works with the 6002 chip in the Blade.

Note: IANAL! :rolleyes:

TBH it seems that the ZTE code is in such a mess that they probably wont manage to release a fully working version, fingers crossed they release the froyo kernel soon and so little time has passed between release of the binary and release of the source that they've not buggered the kernel source up in the meantime by attempting to add more phones into it!

[Guest oh!dougal]

Just to cross-link info from another thread.

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

The (French) Bouygues Telecom version of the Blade seems to have some parts of the OS at a more recent version than the SF.

Worth feeding that back to ZTE for comment as to what is fixed or different?

[Guest oh!dougal]

...

Thanks to those who tried installing the current French {Bouygues} roms and FroYo.

I think we can say that as of now, there is no phone software that solves the "only way to reconnect is to reboot the router" wifi-router-compatibility problem.

Over to you ZTE - and the Netgear DG834G v5 would seem to be a clear demonstration example to replicate the anomaly.

This is a solid reproducible problem (not an intermittent one) and as such it should be easier to isolate and fix.

Whether or not this an extreme example of the occasional "have to turn phone wifi off and then on again to reconnect" problem, I don't know.

There may be a single underlying cause, but certainly with particular router models (and versions) the ultimate consequence is different.

...

Quoted from another thread.

Could this please be fed back to ZTE as a specific reproducible wifi anomaly?

On disconnecting (whether because of sleep or manual disconnect) from the Netgear DG834G v5 the SF will not reconnect successfully unless (until) the router is rebooted.

Phone wifi off/on is not sufficient to reconnect to that router.

The problem seems to happen on every disconnect from that router.

Its not about DG834G v5 compatibility.

Its about the reconnection activity of the SF/Blade not working properly.

The DG834G v5 gives a solid demonstration of where the problems lie. (The v5 is important. I know the v3 behaves differently.)

If the cause of this were to be determined, it might incidentally be very helpful to the many many others suffering occasional failures to reconnect.

This is a solid problem in the same area and might well shed some light on other reconnection difficulties.

[Guest vl4d1m1r]

In light of the above post where ZTE say they can't release the stuff under the device/ or vendor/ tree it might be worth contacting the maintainer above to see if he will point out that the wifi code is open source and that they must release it?

I thought the wifi stuff was part of the kernel anyway, even if it's a loadable module, or is it completely seperate?

The code is based on GPL code by Atheros. They are under legal obligation to release it, even if they don't want to. End of story. ZTE are pissing me off big time.

[Guest hungary]

T-Mobile Hungary release a source code (i dont know which "version") in next week.

[Guest Ally Weir]

i tweeted to orange's support team @OrangeHelpers. They said they would investigate and get back to me. they only work monday til friday so we might get a nice surprise in the morning :rolleyes:

[Guest rjm2k]

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. For example, the light sensor. What's the point of having light sensor working when the phone sleeps? For these modules, users don't have any chance to control their sleep behaviour. So technically you can do anything you like, surely at the risk of a shorter battery life.

When USB cable is connected, the phone doesn't really sleep. Only the LCD and some other modules are turned off. Generally the LCD(including the backlight module) consumes most current on the phone. It's not necessary to go to deeper sleep other than turning off LCD because after turning off LCD, the USB cable supplies far more current than the amount that the phone consumes. There is no need to perform a full sleep. It might take a little bit more time to have the phone fully charged than in a full sleep. But it's not noticable.

WIFI module is special. The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up.

Concerning the key issue you may have some misunderstanding. ZTE handsets highly conform with Android conventions. What keys can wake up the phone and what keys can turn on the screen? They are different things. You must first wake up the phone and then turn on the screen. 7k_handset.kl is only responsible for defining keys that can turn on the screen. You edit that file but it takes no effect because these keys you add are not even eligible to wake up the phone. Keys that can wake up the phone are defined by the manufacturer. Users are not encouraged to change it.

[Guest rjm2k]

Quoted from another thread.

Could this please be fed back to ZTE as a specific reproducible wifi anomaly?

On disconnecting (whether because of sleep or manual disconnect) from the Netgear DG834G v5 the SF will not reconnect successfully unless (until) the router is rebooted.

Phone wifi off/on is not sufficient to reconnect to that router.

The problem seems to happen on every disconnect from that router.

Its not about DG834G v5 compatibility.

Its about the reconnection activity of the SF/Blade not working properly.

The DG834G v5 gives a solid demonstration of where the problems lie. (The v5 is important. I know the v3 behaves differently.)

If the cause of this were to be determined, it might incidentally be very helpful to the many many others suffering occasional failures to reconnect.

This is a solid problem in the same area and might well shed some light on other reconnection difficulties.

Have passed this on, does anything appear in the logs when this happens (logcat or dmesg) ?

[Guest oh!dougal]

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

Thanks, there are some nuggets there, but as you suggest, some things need to be fed back for clarification!

I trust you will be so good as to feed back to your contacts at ZTE at least the substance of my responses.

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.

Yes, and also No !

There is a UI option (WiFi Settings/Advanced) to prevent WiFi sleeping - "Wi-Fi Sleep Policy: Never".

On the Blade/SF this User Setting is NOT obeyed.

When the Blade is in proper sleep (no usb), wifi always goes Off when sleep begins.

It is not clear whether ignoring this UI setting is a software error or a hardware limitation.

Why is the UI setting not being obeyed?

The 'wifi never sleep' setting is useful for "wifi tethering", as one example.

For many other haredware modules, We don't see any reason to have them on when the phone is suspended. For example, the light sensor. What's the point of having light sensor working when the phone sleeps? For these modules, users don't have any chance to control their sleep behaviour. So technically you can do anything you like, surely at the risk of a shorter battery life.

The notification LED (in the 'Back' key) does not function when in Sleep.

The overwhelming user preference is that missed calls, SMS, and email should be notified -- PARTICULARLY when the phone is in Sleep.

This is so significant that it would certainly deter some potential customers. Fewer people would buy this phone if they knew that it could ONLY show a missed call or SMS when it was attached to usb/charger.

People are very surprised to discover that the Blade ONLY shows the Notification LED when the phone is On, or connected to usb.

Its a missed call notification, telling you that something happened that you did not notice. It doesn't do that unless its on usb.

If this is a "design decision", users consider it a very strange, and bad, decision - it needs to be reconsidered..

The battery-power cost of the LED flashing (only when there is something to notify) is not very big.

This would be an important fix both for new production, and existing SF/Blades.

Can this behaviour be changed in software?

It needs to be fixed quickly!

It is a very basic expectation of modern mobile phone users to have notification of missed calls (without needing to be attached to usb!)

When USB cable is connected, the phone doesn't really sleep. Only the LCD and some other modules are turned off. ...

Thank you for confirming my deduction!

WIFI module is special. The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up.

Understood that the module has no sleep mode, it must be either On or Off.

However there are two points here.

1/ As mentioned above, the UI "wifi never sleep (or go Off)" UI policy setting is not obeyed.

2/ There have been problems with the SF wifi when coming out of sleep (wifi being powered on again). Many users experience occasional difficulties REconnecting, but the same users generally don't report difficulty in making a first connection. The workaround has been to turn wifi off and then on again - some developers have made Apps to automate that process. That is not a good sign! But some users can never reconnect and need to reboot their router to connect again -- it seems that the SF has great difficulty with some routers, one example being the Netgear DG834G v5 (the need to reboot is specific to the v5 of the DG834G). Unfortunately for ZTE, the v5 is very common in the UK, being supplied by many ISPs to their customers.

Concerning the key issue you may have some misunderstanding. ZTE handsets highly conform with Android conventions. What keys can wake up the phone and what keys can turn on the screen? They are different things. You must first wake up the phone and then turn on the screen. 7k_handset.kl is only responsible for defining keys that can turn on the screen.

Is that really correct?

I believe the key(s) defined in that file are the keys that cause the Blade to wake from sleep, NOT from screen off.

When usb power is available (and therefore, as confirmed above, ONLY the screen is off, the phone is NOT 'sleeping'), the Home, Menu and Back keys DO wake the screen to the lock screen (and the Volume Up/Down keys don't) -- they are working screen-wake keys but NONE of them have definitions in that file. So how can it be that this file specifies screen-wake keys?

Yes, there may be some misunderstanding somewhere about that file!

You edit that file but it takes no effect because these keys you add are not even eligible to wake up the phone. Keys that can wake up the phone are defined by the manufacturer. Users are not encouraged to change it.

Agreed that users are not encouraged to edit that file!

But when a crazy user does edit the file, the results are not as expected.

If (as I understand) that file is how the manufacturer defines 'eligible' system-wake keys (and not screen-backlight-on keys), the question remains as to why editing the file has no effect.

My theory is that there is no power (in sleep) to the switch module.

I hope that can be changed without difficulty.

Giving the switch module a connection to power while the phone is sleeping is going to be needed to fix the Notification LED problem (the led is inside a switch).

I would hope (I almost expect) that fixing the led power would, as a side-effect, also 'fix' the capability to wake the phone from other keys, by providing power (and/or ground) to the front keys during sleep.

This fix should come "free" when making the Notification LED work. The LED is the important fix, the wake-switches are not important to the majority of ordinary (non-enthusiast) users. But the notification LED is very important to very ordinary users.

[Guest oh!dougal]

Quoted from another thread.

Could this please be fed back to ZTE as a specific reproducible wifi anomaly?

On disconnecting (whether because of sleep or manual disconnect) from the Netgear DG834G v5 the SF will not reconnect successfully unless (until) the router is rebooted.

Phone wifi off/on is not sufficient to reconnect to that router.

The problem seems to happen on every disconnect from that router.

....

Have passed this on, does anything appear in the logs when this happens (logcat or dmesg) ?

For detail you'll have to contact the v5 owners posting in that other thread (my v3 doesn't have the reboot-needed problem)

http://android.modaco.com/content/zte-blad...m/#entry1474228

[Guest targetbsp]

The notification LED (in the 'Back' key) does not function when in Sleep.

The overwhelming user preference is that missed calls, SMS, and email should be notified -- PARTICULARLY when the phone is in Sleep.

This is so significant that it would certainly deter some potential customers. Fewer people would buy this phone if they knew that it could ONLY show a missed call or SMS when it was attached to usb/charger.

People are very surprised to discover that the Blade ONLY shows the Notification LED when the phone is On, or connected to usb.

Its a missed call notification, telling you that something happened that you did not notice. It doesn't do that unless its on usb.

All of the above confuses me. Mine flashes in sleep mode if i set it to do so. Wasn't frequent enough for my tastes though so I installed Missed Reminder to have it flash more frequently. And leading onto your keypress waking the phone stuff, while a missed contact notification is flashing, the button can be used to wake the phone (which it can't do if it's not notifying me)

Edited November 15, 2010 by targetbsp

[Guest oh!dougal]

All of the above confuses me. Mine flashes in sleep mode if i set it to do so. Wasn't frequent enough for my tastes though so I installed Missed Reminder to have it flash more frequently. And while it's flashing, the button can be used to wake the phone (which it can't do if it's not notifying me)

I'll bet your phone isn't actually asleep.

Are you running MyLock by any chance? (It prevents sleep. Don't know about Missed Reminder ....)

Does your battery last more than 24 hours?

With mobile data on, wifi set on, but nothing else happening, mine can still be at 90% after 24 hours. Its using sleep mode.

Edited November 15, 2010 by oh!dougal

[Guest targetbsp]

I'll bet your phone isn't actually asleep.

Are you running MyLock by any chance? (It prevents sleep. Don't know about Missed Reminder ....)

Does your battery last more than 24 hours?

With mobile data on, wifi set on, but nothing else happening, mine can still be at 90% after 24 hours. Its using sleep mode.

I don't have Mylock. My phone drops about 3% battery overnight. So yeah - 10% over 24 hours sounds about right. It lasts days if I'm not playing with it. :rolleyes:

I don't know how to tell if it's asleep or not. But my wifi doesn't work when I unlock the screen (I use a wifi fixing app) so I suspect it is?

Edited November 15, 2010 by targetbsp

[Guest oh!dougal]

I don;t have Mylock. My phone drops about 3% battery overnight. So yeah - 10% over 24 hours sounds about right. It lasts days if I'm not playing with it. :rolleyes:

Try disconnecting from the charger (or usb) killing ALL your tasks (you can reboot it later), put it to sleep, leave it for more than 30 seconds and see whether your front buttons wake it.

If they do, then a bunch of folk will either be after your magic rom ('cos its different to everyone else's) or they will be calling BS.

Even that 30 seconds is important, We've had people claiming the front buttons 'woke' their phone because they were pressing them immediately after the screen went off, and thus before the rest of the phone had gone to sleep.

The behaviour you quote, screen off, notifications work and a front button wakes it is EXACTLY what happens when the phone is prevented from sleeping, for example by a music player, mylock or by connection to usb/charger.

Note that ZTE are saying that its intentional that the front buttons DO NOT wake the Blade from "sleep" --- only from screen-off. They know that they don't work from sleep.