Guest johnsmithx Posted August 5, 2011 Report Share Posted August 5, 2011 Hi, yes, I've noticed a commit with updated lcd driver, I backported it into the previous CM kernel which I am still using. But let's put kernel aside, there is no problem with the kernel. Kernel is fine. CM itself is fine too (although it contains various funny bugs, like this nonsense information as for the name of the accelerator sensor, but that's just a cosmetic thing, just for confusing applications and the users, nothing "serious"). What is really the problem is that CM contains, and is being distributed with, old proprietary files. That's not a cosmetic thing, that's pure functional issue because these old files don't work with the hardware the Blade is already being sold with. CM is being downloaded by thousands and thousands of people, thus the amount of people whose Blade is incompatible with old CM's proprietary files will grow and grow and more and more people asking for help on various forums will appear. Take a person who just bought a Blade. Probably with some 2.2 ROM. At the very moment he "upgrades" to CM (naively thinking he will get something better), the proprietary files in his phone will actually downgrade because they will be older and less functional than the original files in his phone when he bought it and our poor dude will find himself staring at a phone which can't even rotate landscape. So CM will actually make his phone less usable, practically unusable, what is pretty opposite to what CM is supposed to do, right? It's cool that cm devs look at the new proprietary libs but where is the result of this "looking"? CM is still being distributed with old proprietary files which don't work with newer hardware. But I don't blame them and neither I think we should just sit and wait (I guess that's the reason why we all are here in the first place, because we want help others, not just wait for some savior). That's why I proposed this idea to create and maintain the recent set of these proprietary files, totally independently to what CM team will or will not do, because at the end CM is not the only ROM here and these files will be needed in any ROM. I would do it myself and keep maintaining it had I had time for that. Link to comment Share on other sites More sharing options...
Guest wbaw Posted August 5, 2011 Report Share Posted August 5, 2011 (edited) A lot of the proprietary file sets had issues with MVNOs, they'd say the phone was roaming when it wasn't. Not sure if that's still an issue with the more recent releases, but I think that is why CM chose to use Saunalahti RIL files. I think the Swedish generic 2.2 files had that problem, I got complaints when I used them in GSF, so I switched it to the same Saunalahti files that CM7 uses. RIL doesn't work on the gingerbread leak, it needed replacing, possibly a sign of new radio firmware to go with official Gingerbread. It's a good idea to keep testing new ones, see if there are any improvements or problems. I don't see any huge problems with what they're using though. I haven't had any complaints about sensors not working in gsf, except the proximity sensor (calibration, bright light, new hardware revision?). Beware of the mvno issue too, might be best to use files from an mvno rom. It could even be a good idea to keep them separate from the main CM7 distro, like gapps, to work around any possible copyright problems, although I don't think any manufacturers have tried to take any action against cm7 yet. Edited August 5, 2011 by wbaw Link to comment Share on other sites More sharing options...
Guest johnsmithx Posted August 5, 2011 Report Share Posted August 5, 2011 GSF is fine, it's dated 20110525. We got first batch of GEN2 Blades in June, those contained an older ("CM ready") LIS302DL accelerometer. Batch from 2 weeks ago got newer ("CM bye bye") ADXL345. What's interesting is that in both is the identical ROM dated 20110422. So they started flashing newer libraries in advance even into phones with older hardware. Keeping proprietary files separate from CM is a good point. Better not to distribute them at all than to distribute obsolete files, anyway. But who would maintain and distribute them then? There might be a possible partial solution within the CM installation process. If you check the install script, first thing it does is to launch /system/bin/backuptool.sh. This script attempts to backup some .apk and other files before the /system is reformatted, and after the installation those backup files are restored back. The very same way may as well be backed and restored these proprietary files and CM wouldn't need to distribute them at all. Link to comment Share on other sites More sharing options...
Guest wbaw Posted August 5, 2011 Report Share Posted August 5, 2011 GSF uses the same proprietary RIL files as CM7. The ones in the original leak didn't work. Link to comment Share on other sites More sharing options...
Guest johnsmithx Posted August 5, 2011 Report Share Posted August 5, 2011 I wasn't referring to any RIL at all. I simply pointed out the fact that since GSF is quite recent it's no wonder that it logically contains akmd2 file compatible with newer accelerometer (the reason why I started this whole discussion) as opposite to the obsolete incompatible very old akmd2 file found in CM. I see why you take this very major issue calmly - it doesn't concern you and on this forum there are not many complains from people with newer accelerometer. If you had to read several complains a day ("Why I can't rotate my Blade? Did I break it?" - "Did you install CM?" - "Yes." - "Here is your answer, CM is broken.") maybe you would have realized there is some serious problem (needing to be faced). I don't need to care either, it doesn't concern me and I already fixed this issue for all people on our Czech forum. I just (maybe stupidly) care about all the other people who bought (and sooner or later will be buying everywhere around all the world) Blade and its clones with newer accelerator and they can't use CM in it. I simply thought this may be a good "trigger" to start maintaining the recent set of proprietary files as the more generic "countermeasure" in case of any next "surprise" from ZTE . That's all, no biggie. Maybe I did a mistake. Maybe I should have sent all those whining people here. Maybe after hundreds of posts the big sleeping bear would have finally awaken and realized there is a problem. But I did notice several complains related to given issue on this forum and there was virtually no response here, no reaction, so I simply thought I will have to fix it myself. And I did and now I simply thought that since as the cause was identified the very old set of proprietary files then maybe, just maybe, it might be a good idea to prepare for the all future similar problems. Maybe not. If I have sent people to CM forums and bugreports maybe, maybe after some time, they would finally replaced the files, but this would solved only the current problem, not the cause - do we really want to rely on someone third who may or may not update proprietary files for us with x months delay, or do we rather update and keep them updated ourselves? If I create a new thread titled "For everyone with non-working accelerometer in CM - the solution" and tell the people to use newer set of proprietary files they will tell "ok and where we get those from?". If I tell them to get them from their original ROM they will start crying "I didn't backup my original ROM" or "and how actually to do it? I don't understand" and they start looking and searching for "better" proprietary files on their own (people can be very helpative to each other if they have common problem) and first "good one" they find (maybe fixing accelerometer issue but at the same time dragging X other new issues in) they will start using and there will be a total chaos with proprietary files. Do we really want this to happen? I though that preventing this may be in our (who help others) own interest because otherwise any problem anyone will have we will have to ask an additional question "have you done anything with the proprietary files?". Here is the center of various stock ROMs, here is the center of various firmware files, it seemed just right to me that here could also be the center of proprietary files. Maybe not. I believe I've put all possible arguments on the table and repeating the same again doesn't make any sense, so I won't bother with this issue anymore. If anyone would be interested, I am of course willing to help as much as I can with regards to my unfortunately limited spare time. Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted August 5, 2011 Report Share Posted August 5, 2011 (edited) I wasn't referring to any RIL at all. I simply pointed out the fact that since GSF is quite recent it's no wonder that it logically contains akmd2 file compatible with newer accelerometer (the reason why I started this whole discussion) as opposite to the obsolete incompatible very old akmd2 file found in CM. I see why you take this very major issue calmly - it doesn't concern you and on this forum there are not many complains from people with newer accelerometer. If you had to read several complains a day ("Why I can't rotate my Blade? Did I break it?" - "Did you install CM?" - "Yes." - "Here is your answer, CM is broken.") maybe you would have realized there is some serious problem (needing to be faced). I don't need to care either, it doesn't concern me and I already fixed this issue for all people on our Czech forum. I just (maybe stupidly) care about all the other people who bought (and sooner or later will be buying everywhere around all the world) Blade and its clones with newer accelerator and they can't use CM in it. I simply thought this may be a good "trigger" to start maintaining the recent set of proprietary files as the more generic "countermeasure" in case of any next "surprise" from ZTE . That's all, no biggie. Maybe I did a mistake. Maybe I should have sent all those whining people here. Maybe after hundreds of posts the big sleeping bear would have finally awaken and realized there is a problem. But I did notice several complains related to given issue on this forum and there was virtually no response here, no reaction, so I simply thought I will have to fix it myself. And I did and now I simply thought that since as the cause was identified the very old set of proprietary files then maybe, just maybe, it might be a good idea to prepare for the all future similar problems. Maybe not. If I have sent people to CM forums and bugreports maybe, maybe after some time, they would finally replaced the files, but this would solved only the current problem, not the cause - do we really want to rely on someone third who may or may not update proprietary files for us with x months delay, or do we rather update and keep them updated ourselves? If I create a new thread titled "For everyone with non-working accelerometer in CM - the solution" and tell the people to use newer set of proprietary files they will tell "ok and where we get those from?". If I tell them to get them from their original ROM they will start crying "I didn't backup my original ROM" or "and how actually to do it? I don't understand" and they start looking and searching for "better" proprietary files on their own (people can be very helpative to each other if they have common problem) and first "good one" they find (maybe fixing accelerometer issue but at the same time dragging X other new issues in) they will start using and there will be a total chaos with proprietary files. Do we really want this to happen? I though that preventing this may be in our (who help others) own interest because otherwise any problem anyone will have we will have to ask an additional question "have you done anything with the proprietary files?". Here is the center of various stock ROMs, here is the center of various firmware files, it seemed just right to me that here could also be the center of proprietary files. Maybe not. I believe I've put all possible arguments on the table and repeating the same again doesn't make any sense, so I won't bother with this issue anymore. If anyone would be interested, I am of course willing to help as much as I can with regards to my unfortunately limited spare time. The central core problem is - diffing the binaries and assuming that the datestamp is newer, then it must be "new"... and that's assuming it has been fixed when in fact it could/may well be quite the opposite... Its a mammoth task to find out which is the more recent/stable/fixed and not a fuxxored-up version... the libs as well... and not alone that, there's far too many roms lying around on multiuploader that you have no way of telling which is which... and the endless flashing/rebooting to find out which is the better binary.... Put it another way, how about a centralized repository of ALL roms that were released and make note of the date that it was posted first, and work through them all... when you think about it - its big.. My 2cents B) Edited August 5, 2011 by t0mm13b Link to comment Share on other sites More sharing options...
Guest johnsmithx Posted August 5, 2011 Report Share Posted August 5, 2011 (edited) The central core problem is - diffing the binaries and assuming that the datestamp is newer, then it must be "new"... and that's assuming it has been fixed when in fact it could/may well be quite the opposite... Nono, sure not that way. But you think in very right direction. Except classical reverse engineering (decompiling, disassembling) there is a lot of what could be done totally automatically via a statical analysis. You can check for specified strings like "/dev/' (that would be the simplest way to find out which akmd2 supports newer accelerators), versions, etc., you can check what shared libraries was file in question linked with, what compiler version was file in question compiled with, in some cases you can even check what sourcefile names (with full pathnames) were used, and many many more. Now once we peep a bit under the roof and identify the files which are actually different in different ROMs (we don't need to care about the identical ones at all) we may come up with some correlation and more on-the-spot functions how to compare files with the same filenames but from unknown sources and times. It may be a nice project for some student for example and in addition you can make it more general if you want. Hell, I've seen the whole graduation theses based on something as "little" as this :rolleyes: Besides, there already exist many automated file recognition & inspection frameworks which can be used. Put it another way, how about a centralized repository of ALL roms that were released and make note of the date that it was posted first, and work through them all... when you think about it - its big.. That's exactly what I was hoping for. Storing, tagging, sorting and indexing everything together, making some simple web interface with some simple engine underneath doing the necessary gathering and data mining. It's not a rocket science (to not scare off with "big words"). And I don't really think there will be big legal issues because if these files are already freely available to download (that would unfortunately disqualify the leak ones), then no one can blame us for mirroring them. And doing some analysis? Where is the harm? I can help with all this with advice as well as with some programming, but I can't really be a "project leader" for this. Edited August 5, 2011 by johnsmithx Link to comment Share on other sites More sharing options...
Guest wbaw Posted August 5, 2011 Report Share Posted August 5, 2011 If anybody wants to do their thesis on it, it'd be welcome. Unfortunately I have better things to do too. Here is where to send people with bugs in CM7: http://code.google.com/p/cyanogenmod/issues/list?&q=blade Why is there no bug for this problem there? How do you expect it to get fixed if no bug has been reported? Why did "all these whining people" come to you, but we've not heard a thing on the forums or the issue tracker? Not trying to criticise, I'm just confused. Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted August 5, 2011 Report Share Posted August 5, 2011 Well, if its of any help, there's a cm7 script used for extracting proprietary libs, to start off with, that includes any aforementioned bootup scripts also, assuming the current directory is CyanogenMod, then in devices/blade/zte/extract-files.sh contains the list of files that is proprietary... B) Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted August 5, 2011 Report Share Posted August 5, 2011 If anybody wants to do their thesis on it, it'd be welcome. Unfortunately I have better things to do too. Here is where to send people with bugs in CM7: http://code.google.com/p/cyanogenmod/issues/list?&q=blade Why is there no bug for this problem there? How do you expect it to get fixed if no bug has been reported? Why did "all these whining people" come to you, but we've not heard a thing on the forums or the issue tracker? Not trying to criticise, I'm just confused. Sorry if you sound confused but the linky that you supplied - that's for RC only versions of CM7, not nightlies - don't ask me why there is none for the nightlies or that the CM7 team just cannot be bothered.... which sticks out like a sore thumb - no place to report bugs for the nightlies which is what I suspect is going on here.... B) Link to comment Share on other sites More sharing options...
Guest johnsmithx Posted August 5, 2011 Report Share Posted August 5, 2011 Why is there no bug for this problem there? How do you expect it to get fixed if no bug has been reported? Why did "all these whining people" come to you, but we've not heard a thing on the forums or the issue tracker? Well, why people come to me you ought ask them, not me :rolleyes: It's maybe because I actually help them instead of sending them elsewhere. And surely another reason will probably be the language issue (maybe unbelievable but that's unfortunately the reality). I did try to contact Tom, since he is written as the "author" in sensors.c, via e-mail some week or two ago and received none ( 0 ) response. I thought it would take a few hours, if not minutes, for him to fix this. First I thought he was on vacation, then I noticed on gerrit he is alive, so you make a conclusion yourself. Now, being a programmer for 25 years, you can't really expect me to "beg" such younger people and with such attitude, so I simply decided (partly was forced) to give it a try myself. Link to comment Share on other sites More sharing options...
Guest wbaw Posted August 5, 2011 Report Share Posted August 5, 2011 (edited) If you want to get a cyanogenmod issue fixed & it's a bug that is present in their 'stable' version, then you should report it on the cyanogenmod issue tracker, otherwise they wont know about it. If you supply a patch then it's likely to be fixed faster. If you've been a programmer for 25 years then it should be easy for you to work out how to do that. This was intended to be a thread purely to collect links to different stock updates ... if you want to talk about CM7 proprietary files then it'd be better in another thread. Edited August 5, 2011 by wbaw Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted August 5, 2011 Report Share Posted August 5, 2011 (This question may or may not be better for a separate thread, not sure, you tell me.) Would anyone be interested in comparing "proprietary files" from all these ROMs and finding out what files are actually changing, what are still the same, and in the end making "the best" set of proprietary files for ZTE Blade? I'll explain why I am asking this. If someone wants to build CM himself, he would find out that he needs first to extract proprietary files from his phone and put them in the CM tree. CM team says that they cannot publish these files in CM repository because of license issues or whatever. That's the current reality. Now, I don't really understand this attitude because: these same people already made these same proprietary files publicly accessible in their git repositories (for example here and here)these same people already do publish these same proprietary files in the official CM downloadsWhat to make of this schizophrenic standpoint is beyond my comprehending but.. whatever. The real problem here is that these files distributed within CM downloads are old. This proved as a major issue just recently when ZTE Blade started to be sold with a newer type of accelerometer sensor. The old proprietary files from within CM doesn't work with it. I was researching this problem for a while and after several tens of testing builds, digging into kernel sources, digging into various CM sources, today people are finally starting to report me fully working sensors in CM. I didn't have time yet to find out what was actually the cause but on 99% it was those proprietary files, namely /system/bin/akmd2 (the one in the official CM distribution doesn't talk to /dev/adxl34x and consequently the other sensors don't work as well). Based on the findings above, the general advice to people in similar "strange" problems (beside the usual advices like "make sure you have the latest versions", "make sure you do a full wipe" etc.) could go like this: "extract the proprietary files from your original ZTE ROM and inject them into CM". While that would be for their particular phones the best, in reality for many it would be a problem. Not everyone makes a backup of the original ROM, not everyone is capable of such manipulations with files, and they would have to do it every single time when they upgrade CM. So I was thinking, why not to take it a one step forward and not research and compare these proprietary files ultimately making a single best set of them? Then we can offer this set to the CM team to include it in their CM builds and also we can make a simple installable .zip file. If I say it in general way, maybe in the same way as wbaw is collecting and maintaining "the best" set of .mbn firmware files, we may as well maintain a similar "the best" set of these proprietary files. What do you think about that? A very easy way to deal with this is use the dxida kitchen to convert the system.img to an update.zip copy the update.zip to CM7/blade_update.zip (where CM7 = your root directory) Then just run device/zte/blade/unzip-files.sh I think both the softbank / hungarian 2.2.2 builds are pretty much identical. Link to comment Share on other sites More sharing options...
Guest unrandomsam Posted August 5, 2011 Report Share Posted August 5, 2011 hi, good idea, both blade cm devs own a zte blade and a zte v880. When a new stock rom comes out they have looked at the new proprietary libs to see what will work. when they looked at gen1 to gen2 libs they found the majority had not changed. when they received their v880s from ZTE, one of the devs found that they were based on a newer kernel source and rom than the latest kernel source zte provided, so they had to hack the kernel to support the new lcd. the newer blades coming out are having to be supported with adjustments to the kernel, as the zte provided kernel source is incomplete and the cm blade devs are having to hack around issues. proprietary libs are closed source, cyanogenmod repository is opensource, you will never see anything that is proprietary or closed source in there. Appart from in the binary builds. (Thats the inconsistancy) Link to comment Share on other sites More sharing options...
Guest bogino Posted August 14, 2011 Report Share Posted August 14, 2011 Why is there no bug for this problem there? How do you expect it to get fixed if no bug has been reported? Why did "all these whining people" come to you, but we've not heard a thing on the forums or the issue tracker? Not trying to criticise, I'm just confused. Hello, I am quite new here, quite new 1st time owner of an Android device and quite new on http://androidforum.cz, where I found I have a new accelerometer and I found other users on androidforums.cz, who reported the CM7 accelerometer issue with the same accelerometer I have. Actually there are 2 new accelerometer devices and I have one of them: dmesg | grep gsensor.*id <3>[01-01 00:00:02.000006] [1: swapper][lis302dl@gsensor]:use ADI gsenosr chip ,chipid = e5! <4>[01-01 00:00:02.000006] [1: swapper][adxl34x@gsensor]i2c read success,revid =229 But I would like to answer to the quoted text. People like I do not know do not know where is the official place to report some issue for example in CM7. I found androidforums.cz through Google. Naturally, Google prefers sites from my country and region. On that forum I found information about the issue as well as the link to this modaco forum. Although it is no problem for me to communicate in English, many people from Czech Rep. or Slovakia do not know English sufficiently, or it is simply easier ot communicate in Czech or Slovak (we understand each other). Such users remain on androidforums.cz. Few of skilled Blade users from our region are registered here, but they may represent much bigger community. Please do not underrate the information from johnsmithx, as well as the number of owners of new Blades. Maybe new Blades were not yet sent to countries you are from, I don't know. I am from Slovakia. I would like to thank all who are supporting Blade users in any way. Link to comment Share on other sites More sharing options...
Guest KonstaT Posted August 14, 2011 Report Share Posted August 14, 2011 (edited) Hello, I am quite new here, quite new 1st time owner of an Android device and quite new on http://androidforum.cz, where I found I have a new accelerometer and I found other users on androidforums.cz, who reported the CM7 accelerometer issue with the same accelerometer I have. Actually there are 2 new accelerometer devices and I have one of them: dmesg | grep gsensor.*id <3>[01-01 00:00:02.000006] [1: swapper][lis302dl@gsensor]:use ADI gsenosr chip ,chipid = e5! <4>[01-01 00:00:02.000006] [1: swapper][adxl34x@gsensor]i2c read success,revid =229 But I would like to answer to the quoted text. People like I do not know do not know where is the official place to report some issue for example in CM7. I found androidforums.cz through Google. Naturally, Google prefers sites from my country and region. On that forum I found information about the issue as well as the link to this modaco forum. Although it is no problem for me to communicate in English, many people from Czech Rep. or Slovakia do not know English sufficiently, or it is simply easier ot communicate in Czech or Slovak (we understand each other). Such users remain on androidforums.cz. Few of skilled Blade users from our region are registered here, but they may represent much bigger community. Please do not underrate the information from johnsmithx, as well as the number of owners of new Blades. Maybe new Blades were not yet sent to countries you are from, I don't know. I am from Slovakia. I would like to thank all who are supporting Blade users in any way. How to use CM7 issue tracker: http://wiki.cyanogenmod.com/index.php?title=Howto:_Use_the_Issue_Tracker Sensor issue already reported (and fixed?): http://code.google.com/p/cyanogenmod/issues/detail?id=4177 This is absolutely wrong thread for this discussion... Edited August 14, 2011 by KonstaT Link to comment Share on other sites More sharing options...
Guest ksatriapetir Posted August 19, 2011 Report Share Posted August 19, 2011 need an indonesian ZTE blade stock rom... anyone? Link to comment Share on other sites More sharing options...
Guest ksatriapetir Posted August 19, 2011 Report Share Posted August 19, 2011 need an indonesian ZTE blade stock rom... anyone? Link to comment Share on other sites More sharing options...
Guest Unbalanced Posted August 20, 2011 Report Share Posted August 20, 2011 @wbaw found the greek (Wind) update (working link) for the ZTE Blade from the official site. Here's the site (google translated - just click the Software Support tab) and here's the direct link of the ROM... 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