[ROM] 16. Feb. 2011 - BBlack-CM7 build

[Guest markastor]

I only see settings to Keep screen awake (Screen will stay awake longer...) but this don't fix the bug :D

Screen is keeping awake only for several seconds.

There is also a setting: Always use proximity but this one don't resolve this bug too :)

as for me the proximity sensor is working even if you turn it off in settings so maybe it's the origin of this bug.

PS.

Sorry for my poor english :D

I have the same problem too. There are no option to "disable switching off screen inside calls".

This makes unusable this very nice rom. :)

[Guest hecatae]

Fork the github repo, work on fixing bugs and adding features then send pull requests upstream. Tom or Jacob will look at the code and merge in if needed.

And the rom will be added to the build bot soon. There have been no bug fixes since the last release here so you aren't missing anything.

Overclocking is being added to the kernel by HCDRJacob along with the extra functions that the 2.2 OC kernels have.

which repo to fork?

[Guest metzench]

Sorry but no. If he wants to contribute to the community then he should offer to work with the developers rather in competition.

Sorry but this is no competition with someone. If there are fixes i could contribute ( e.g. via Github ) i will do, that´s the thing about Open Source, isn´t it? And trust me, working together with other is one of the things i do with my bigger project CCux Linux for years now.

But whats wrong about making a good rom for me, perhaps with alterations like added apps and other things based on CM7. In which way does this affect CM7 itself? Do you only used the default wallpaper because someone said this is the one?

And please, tell me why did you assemble your own rom? Why didn´t you try to assist someone else in his rom and make this better?

[Guest sensory]

I have the same problem too. There are no option to "disable switching off screen inside calls".

This makes unusable this very nice rom. :D

Have you had a look under Settings > Call Settings > Keep Screen Awake?

Edited February 16, 2011 by sensory

[Guest metzench]

Absolutely. And Christian is more than welcome to submit code to the project if he's managed to fix anything. Same for anybody really.

If a noob like me can fork a github repo and push changes upstream then anybody can :D

http://help.github.com/forking/

Well, i´m already runnig a fork for the relevant repo and if there es something that fixes things in upstream i´ll surely fill a push request on github and hope that it gets accepted. Where´s the problem?

[Guest markastor]

Have you had a look under Settings > Call Settings > Keep Screen Awake?

Read the description: it keeps the screen longer awake. I still have the screen off bug after 4-5 secs during a call.

Edited February 16, 2011 by markastor

[Guest hecatae]

Well, i´m already runnig a fork for the relevant repo and if there es something that fixes things in upstream i´ll surely fill a push request on github and hope that it gets accepted. Where´s the problem?

https://github.com/metzench/android_device_zte_blade

metzench's fork from 18 hours ago

and https://github.com/metzench shows all metzench's changes he's pushed commented on and pulled

Edited February 16, 2011 by hecatae

[Guest metzench]

https://github.com/metzench/android_device_zte_blade

metzench's fork from 18 hours ago

and https://github.com/metzench shows all metzench's changes he's pushed commented on and pulled

Repository doesn´t exist anymore, i deleted it for now. Seems to be better to stick with my personal copies as development/testing platform. Some people really seem to be pissed of someone not known by them tries to push things.

[Guest tonnikala]

Overclocked frequencies is not kernel related, isn´t it?

Somebody else answered before me, but see: http://android.modaco.com/content-page/322...ernel/page/140/ at least kallt_kaffes last post.

I don't understand why people are so obsessed about nightlies... there are none so far!

Exactly. That's why installed your latest build! Overclockable kernel would be nice (I know that HDCRJackob is working on it).

I removed RomManager.apk to get ROM + G-apps to fit in /system (now there is 1.1MB free).

Thanks for ROM!

[Guest metzench]

Somebody else answered before me, but see: http://android.modaco.com/content-page/322...ernel/page/140/ at least kallt_kaffes last post.

Exactly. That's why installed your latest build! Overclockable kernel would be nice (I know that HDCRJackob is working on it).

I removed RomManager.apk to get ROM + G-apps to fit in /system (now there is 1.1MB free).

Thanks for ROM!

I´ll investigate the kernel further and might be release another update.

Nice that someone likes sharing what i mainly did for me. I can´t really understand why this automatically must exclude letting the main development participate....

[Guest targetbsp]

Have you had a look under Settings > Call Settings > Keep Screen Awake?

Aren't you in danger of hanging up the phone with your ear if you do that though? I assume that's why the screen is designed to go off in the first place. Kind of need it to be able to come back on - not stay on?

[Guest Simon O]

And please, tell me why did you assemble your own rom? Why didn´t you try to assist someone else in his rom and make this better?

Why shouldn't I assemble my own rom? Should I have taken somebody elses and released it as my own like you have?

Bug fixes I made to my ROM have been given to other ROM developers. Paul uses a lot of my fixes in his MCR rom and I'm using several of his fixes too. This is how things should be.

Let me make this clear. I'm not trying to stop you from making your rom. But when you start talking about tweaks and extras for your rom which are not being passed on upstream then I consider than unfair and not in the spirit of things.

[Guest hecatae]

Repository doesn´t exist anymore, i deleted it for now. Seems to be better to stick with my personal copies as development/testing platform. Some people really seem to be pissed of someone not known by them tries to push things.

that's a shame, I was hoping to compare fixes

[Guest metzench]

Why shouldn't I assemble my own rom? Should I have taken somebody elses and released it as my own like you have?

Bug fixes I made to my ROM have been given to other ROM developers. Paul uses a lot of my fixes in his MCR rom and I'm using several of his fixes too. This is how things should be.

Well you really understood what i wnated to say. You just didn´t anything else i did with my release. You took someone elses rom and did some modifications to it, nothing else. I didn´t release CM7, i released a rom based on CM7 to further investigate what needs to be done and perhaps be helpful for the upstream developers when pushing fixes i may have found. Where´s the difference to your doing?

I never talked about not wanting to share my experiences with this, as i stated in my first post, i wanted to have a upstream source to search for bugs and not a reassembled one beeing based on compiled code already days old, nothing else.

Let me make this clear. I'm not trying to stop you from making your rom. But when you start talking about tweaks and extras for your rom which are not being passed on upstream then I consider than unfair and not in the spirit of things.

And again, you seem to be not reading anything i posted, this was one if my main intents why i compiled this rom. ( No i didn´t take a already assembled on and made some modifications to it ). Tell me where said i will not give anything to the upstream?!

Might be you don´t like other roms co existing with yours?

[Guest metzench]

that's a shame, I was hoping to compare fixes

No problem mate, there was nothing in yet that isn´t in the official repos. I´ll make a new repo and post this if there are any interesting fixes ( like modified kernel etc. ), i didn´t want ppl to try with my fork if there is nothing different.

[Guest markastor]

Any idea to switch the proximity sensor completely off? :D

[Guest jasonXXx]

@metzench

Carry on your good work with this rom i dont understand why people moan the more roms the better. If people did not base roms of other roms there would be hardly any roms available.

@flibblesan

This is not a negative comment but are you not using zte rom as your base? even if you use aosp you are basing the rom from google.

[Guest Flumpster]

but there will be times when I do not have a charger or different computer + cable with me, so sadly I will revisit once the bug is fixed.

The usb computer cable brings it back alive for me but not a charger. I had the same idea of plugging in my power monkey charger when it happened but would not bring it out.

[Guest fonix232]

Actually, I think metzench's build are needed until we get the first nightly. As such, we can push the fixes before the first build, so it gets more bug-free, and we will get an RC sooner.

BTW, what are the current bugs? Light sensors have been fixed, GPS too, what else remains?

[Guest Nick Rhodes]

Sorry but this is no competition with someone. If there are fixes i could contribute ( e.g. via Github ) i will do, that´s the thing about Open Source, isn´t it?

Metzench,

I appreciate and am currently using your build at the moment and so far you have provided a useful service, thanks.

Please remember your initial statement about the purpose of your ROM is to "collect bugs" and get "closer to a official CM7 build", this is what my previous criticism was based on.

Problem I see is to get "closer to an official CM7 build", means contributing back through the correct channels to gain acceptance and was the whole reason Tom stopped making his own ROM and decided to contribute with Jacob and through official channels.

By not doing so, it is actually of detriment to the Blade-Cyanogen community as a whole, it creates fragmentation, lower quality code (your fixes may not get accepted, any changes you make break compatibility) and support (duplicates and confusion - Cyanogen has already has issues with users reporting issues to them for unofficial ports they do not support). You risk fragmentation and forking without any unique features or benefits.

Negative stuff over, I have pondered over a pragmatic way forward, that I think is beneficial to all.

My suggestion would be, try and utilise Cyanogen's processes and tools where possible, their issue tracker, lists etc and joining as a dev.

I think this would actually benefit not only the main Cyanogen project, but also any of your own work, the blade community here and the Cyanogen community.

I think it will help prevent, duplicate effort of reporting bugs, duplicate effort of fixing bugs (as you could end up fixing a bug reported here that someone at cyanogen is tasked with fixing). You would follow their coding and testing standards better (last thing you want is your fixes being rejected because they are not attached to issues in the tracker or they do not meet their standards), be better aware of future plans for future changes (its already been mentioned about overclocking).

If you do choose to release your own builds with your own changes and additional features, the above will help you minimise risk of duplication (like with the overclock work), compatibility and better ability to merge back any of your changes/features into the main Cyanogen branch.

It would mean you can better support users for your changes rather than general bugs that apply to the main Blade build as well, try and direct them to the correct areas of Cyanogen for general cyanogen blade issues, try and leave this thread for your specific changes/features only.

Cheers, Nick

[Guest metzench]

Actually, I think metzench's build are needed until we get the first nightly. As such, we can push the fixes before the first build, so it gets more bug-free, and we will get an RC sooner.

BTW, what are the current bugs? Light sensors have been fixed, GPS too, what else remains?

That were my intentions, as stated in my first post. I´ll continue this for me, can´t see the bad side in doing my own builds based on CM7. And if there are things we can push, the better.

Proximity sensor after phone calls is one more bug. :-)

[Guest sensory]

Might be you don´t like other roms co existing with yours?

That's a very silly thing to say. :D

It's your decision to continue the development of your own unofficial CM7 ROM. No one's trying to stop you on that.

The thing I'm worried about is that taking CM7 and making your own additions and fixes tends to fracture the development, which is why it's good practice to keep CM7 development to the official channels. Keeping it all in one, easily-readable place helps everyone and doesn't cause the confusion that comes with multiple unofficial CM7 builds running different features or different base apps. e.g. People will start reporting bugs concerning your build of CM7 on the official bug tracker, because of features you may have added or something you may have broken. Things you want adding to the official CM7 can be achieved by working with the Blade CM7 devs, not on your own and pushing bug reports.

Finding information about a certain ROM on this forum (and any other) is hard enough as it is.

There's no need to start making it personal, though.

Any idea to switch the proximity sensor completely off? :D

The only solution I can find is using an app called Proximity Screen Off. Read the description, it has an option to disable during call. It might work, but it's not very elegant.

[Guest metzench]

Metzench,

I appreciate and am currently using your build at the moment and so far you have provided a useful service, thanks.

Please remember your initial statement about the purpose of your ROM is to "collect bugs" and get "closer to a official CM7 build", this is what my previous criticism was based on.

Problem I see is to get "closer to an official CM7 build", means contributing back through the correct channels to gain acceptance and was the whole reason Tom stopped making his own ROM and decided to contribute with Jacob and through official channels.

By not doing so, it is actually of detriment to the Blade-Cyanogen community as a whole, it creates fragmentation, lower quality code (your fixes may not get accepted, any changes you make break compatibility) and support (duplicates and confusion - Cyanogen has already has issues with users reporting issues to them for unofficial ports they do not support). You risk fragmentation and forking without any unique features or benefits.

Negative stuff over, I have pondered over a pragmatic way forward, that I think is beneficial to all.

My suggestion would be, try and utilise Cyanogen's processes and tools where possible, their issue tracker, lists etc and joining as a dev.

I think this would actually benefit not only the main Cyanogen project, but also any of your own work, the blade community here and the Cyanogen community.

I think it will help prevent, duplicate effort of reporting bugs, duplicate effort of fixing bugs (as you could end up fixing a bug reported here that someone at cyanogen is tasked with fixing). You would follow their coding and testing standards better (last thing you want is your fixes being rejected because they are not attached to issues in the tracker or they do not meet their standards), be better aware of future plans for future changes (its already been mentioned about overclocking).

If you do choose to release your own builds with your own changes and additional features, the above will help you minimise risk of duplication (like with the overclock work), compatibility and better ability to merge back any of your changes/features into the main Cyanogen branch.

It would mean you can better support users for your changes rather than general bugs that apply to the main Blade build as well, try and direct them to the correct areas of Cyanogen for general cyanogen blade issues, try and leave this thread for your specific changes/features only.

Cheers, Nick

That where my intentions, a already follow the development at cyanogen and will be pushing my changes/fixes whatever if there is something to push.

[Guest metzench]

That's a very silly thing to say. :D

As silly as the statement why i wrote that.

[Guest fonix232]

Look.

All of the fixes will be published and pull-requested to the official CM blade branch. So, this is something like a nightly build, but not by buildbot.