yashsingh1/xdaforums huggingface dataset:
[HD Mini General] tzacapaca:
dude,i'm not complaining and i believe you don't know the definition of "complaining"

here it is:

com·plain (km-pln)

intr.v. com·plained, com·plain·ing, com·plains

1. To express feelings of pain, dissatisfaction, or resentment.

2. To make a formal accusation or bring a formal charge.

see also:

Synonyms and related words:

Jeremianic, beef, beefing, bellyache, bellyaching, *****, *****ing, complaint, complaintful, crabbing, crabby, cranky, croaking, destructive criticism, disappointed, discontented, disgruntled, displeased, disputatious, disputing, dissatisfied, dissent, dissentient, dissenting, envious, faultfinding, fractious, fretful, grievance, gripe, griping, groan, groaning, grouchy, grouse, grousing, growling, grumbling, holler, howl, howling, kick, kicking, lamentive, malcontent, malcontented, moanful, mournful, murmuring, muttering, noncooperative, objecting, obstructive, on the barricades, out of humor, peeve, peevish, peevishness, pet peeve, petulance, petulant, plaintive, plangent, proof against, protest, protesting, puling, querulant, querulous, querulousness, rebellious, recalcitrant, refractory, reluctant, renitent, repellent, resentful, resistant, resisting, resistive, restive, restless, retardant, retardative, scolding, sniping, sorrowful, squawk, squawking, sulky, ululant, unaccepting, unaccommodating, uncooperative, uneasy, unfulfilled, ungratified, unhappy, unsatisfied, unsubmissive, unyielding, up in arms, wailful, whimpering, whining, whiny, withstanding, yapping,

the one who complained and started the mess from this thread which you said is munjeni aka cardsharing,so...try to read better..or change your online translator :)

as about defending r0bin and schlund i'm not doing it only for their port help,i'm doing also because they are nice guys,so if you can't read my mind don't assume what i'm thinking about!
[HD Mini General] munjeni:
This is not chaos, this is a fact what we needs if we want success! Good primer is "teamwork on battery driver", right? Don't forget, five brains are smarter than a one! This is what I try to say in this thread. And, don't forget, we are not profesionals like Cotulla! And, we are at the stage of learning, and should therefore we need to share the opinion. The point of all this is clear who the day! Some guys understand me, some guys no want to understand me, I think it is the mentality thing! Thanks to everyone who understands the point of my story
[HD Mini General] -r0bin-:
munjeni, please stop fighting on my thread.

everybody in this forum recognize you are helpful for photon porting

but if you're not happy with the time we take to answer you, or the time we take to upload new source code, just do it yourself and stop whining:

you've got the same level of information we have.

i know you want to be fast and port android as soon as possible, but we have different ways to work: accept it or leave it.

if you continue to fight like this, all you will get will be a dismissed dev team, a dead forum, and you will probably be banned again.

and android will never be ported on this phone.

i hope you will understand this time before it becomes too late.
[HD Mini General] munjeni:
I'm not here to fight! As I say, you are not obliged to publish their code (I think we definitely deserved to see), but then at least please try to help. Do be patient and make tutorial how to get gpio number, in any way, I will try to make byself a new driver. Knowledge for a (how to "number") gpio number has really needed! Bassed on this page http://xdaforums.com/showthread.php?t=1101809&page=6
[HD Mini General] -r0bin-:
google haret gpio =

http://htc-linux.org/wiki/index.php?title=HaRET_Documentation#Polling_GPIOs
[HD Mini General] utsavkoju:
off the topic and off the thread.:D

this thread is not for those english classes. So, keep all your excellence with yourself. Just think you started COMPLAINING me with this reply.:cool:

stop annoying other and HELP dev in testing android.:rolleyes:

see the second definition that's what i am implying at.

if you didn't get me then thats it

stop yelling and stop spamming in this r0bin battery thread.
[HD Mini General] -r0bin-:
stop fighting, thanks :cool:

code is commited in photon webpage, feel free to use or comment, it still need to be enhanced.
[HD Mini General] munjeni:
very, very, very thanks!

Thanks!
[HD Mini General] ToughGuy:
Please！

Guys!

I believe that everyone did not want to see this, please unity.

Thank all the developers to make contributions.
[HD Mini General] munjeni:
Some updates for AC-USB-BATTERY status detection-logic. First see this two pictures:

http://img18.imageshack.us/img18/5807/88335751.jpg

http://img687.imageshack.us/img687/7215/17033506.jpg

Example how we will know if charging is from usb or charging is from original charger (AC), or running on battery.

example code:

detect_ac = readl(0x0fffc00c);
//#define DETECT_AC readl(MSM_SHARED_RAM_BASE + 0xFC00C)

if (detect_ac == "01" && usb_is_detected == "00") source = AC;
elseif (detect_ac == "01" && usb_is_detected == "01") source = USB;
else source = BATTERY;

r0bin what you think?
[HD Mini General] -r0bin-:
i think:

- usb or AC detection is already working

- having this value in SMEM is good, but better is having a dynamic signal (such as IRQ) that a cable was inserted. and SMEM value is not IRQ, you need to do static polling
[HD Mini General] munjeni:
yes you are right. It's alredy defined in your code:

vbus_status = readl(MSM_SHARED_RAM_BASE+0xfc00c);
[HD Mini General] munjeni:
I could not understand how to fix bug in battery code posted on svn. I've tried from all way to get "on screen status charging" but could not locate where is bug:confused: Sorry, but I must to say code is very dirty with many bugs. I spent 1 hour without success:mad:

r0bin, would you be so kind to fix the bug and upload to svn, thanks
[HD Mini General] -r0bin-:
hum what bug are you talking about?

be more precise i cant understand
[HD Mini General] _Madmatt:
I'm not surprised the code is "dirty" because Robin hasn't had the time yet to clean it up. Because some persons were quite impatient to take a look at it... So please wait and give Robin the time to clean up (if he wants to, at least!).
[HD Mini General] munjeni:
You are his lawyer? r0bin, please, do not get me wrong, I asked why becouse maybe r0bin not know about what I say, but battery code posted on svn realy not working. I've tried to fix it but without success, but I need it for cm6 and cm7. I geting "bug" loop in batterty info "on screen" (charging-not charging, led lamp blinking-not blinking), all is with interval of 0,1 s, but I see charging is in progress! I think it makes no sense to repair something that has already been repaired, so I say if r0bin can chack that and upload to svn "fixed", it would be nice
[HD Mini General] 15MA1L:
I do not think it bothered Robin, the fact that "someone" is impatient because he was such from the beginning ... I know about that bug wich munjeni talk I saw today although the phone was disconnected from PC and after 10 minutes still showed me bat.indicator that the battery is charging and LED light was orange and on
[HD Mini General] -r0bin-:
guys chill out :D

there is no bug in svn, this is the real code i used to create r127.

so:

- if you have a bug with battery in release r127, then it is a bug and you should create an issue in photon code page.

- if you have a bug in cm6 or cm7, then the issue is in cm6/cm7 source code and you need to work on this ;-)
[HD Mini General] munjeni:
No, please try kernel posted by schlund with keypad fix, you will see a

bout what I talking
[HD Mini General] 15MA1L:
I apologize for the misunderstanding I'm talking about the bug that is in zImage (http://xdaforums.com/showpost.php?p=15490568&postcount=25) and not on release r127
[HD Mini General] -r0bin-:
@munjeni: schlund kernel was only a test kernel, to try keypad. if bug is not present in official froyo release, then please ignore it.

@15MA1L: i'm not into in cm6/cm7 development: if there is a bug that is not present in official froyo release, i cant help you :-)
[HD Mini General] munjeni:
R0bin, yes, bug is displayed also in froyo, and I think logic is if I say about kernel by Schlund (kernel from your svn, right?) that kernel must have working batt becouse is from your svn. Try deleting your local source and download source from svn and compile you will see I'm right
[HD Mini General] az35:
it's been a while :-) For those who were worrying about my strange battery curves: my phone had the same issues under winmo, and was just replaced (still under warranty!). Charging & gauge is ok with R127!

Az
[HD Mini General] audio84:
Great work so far guys, but I'm just wondering why the battery doesn't charge in R134 Beta? If it worked in R127, what's changed? :/
[HD Mini General] -r0bin-:
thanks for the update. thanks to android, you now have a new battery :-P

yes, it has been taken into account and will be fixed. thanks for reporting ;)
[HD Mini General] audio84:
Fantastic! Great to hear, can't wait for the next release. Hope it's soon :)

Keep up the good work buddy!
[HD Mini General] audio84:
Just a quick thought..

With 127's battery fix and 134's screen calibration & G-Sensor fix, the phone would be fantastic for everyday use. Could we see a quick version of 134 with only 127's battery fix implemented for the time being? Just something to tie us over while other elements of the phone are being fixed.

Cheers!
[HD Mini General] -r0bin-:
battery driver is really too messy, i will rewrite it using HTC Liberty skeleton itll give better results.

i cant release an in-between version, sorry.

next release will be a good one ;)
[HD Mini General] audio84:
Ahh I see. That's completely understandable :)

I won't ask when the next release would be due because that would be annoying.. but umm.. XD

Sorry, just getting exited with having this on our phones! Great work once again!
[HD Mini General] munjeni:
Temporary, I've fixed driver for the battery (and improved ac-usb detection), but you need to pay atention (until the new one is out)! And improved the brightness of keypad (reduced light), all known fixes (not know if time will work) is applied, try...

If you want to back to old kernel, don't forget to replace bcm4329.ko with bcm4329.ko from previous

update:

attachment removed becouse my bug! Sorry! Moved to page 31 !
[HD Mini General] goldenorb:
kepad light still at full brightness..
[HD Mini General] munjeni:
are you use r134 with kernel I posted? Put the phone to the light and put the phone in the dark, you will see it working now!

Guys I waiting your feedback
[HD Mini General] audio84:
Give me a sec buddy, I'll do some quick tests on it :)

Quick noobish question, the update folder that comes with this new version.. do I do anything in particular with that? Or do I just replace the older files..
[HD Mini General] munjeni:
if you allready have "instaled" latest release "r134", use attachment I posted, put "update" folder to sdcard, put bcm4329.ko to folder "update", put update_modules.sh to folder "update", replace zImage with mine zImage, run haret. It will fix battery problems, reduce button light, but in any way you need to pay attention to the battery!

Way if you not have instaled r134 release:

Download r134 release, pay attention to tutorial "how to install r134 release", replace bcm4329.ko with bcm4329.ko from my attachment, replace zImage with zImage from my attachment
[HD Mini General] pwel:
installed the fix, but now wifi does not work anymore??
[HD Mini General] munjeni:
are you placed update_modules.sh to folder "update"?
[HD Mini General] audio84:
I had R134++ installed. Replaced zImage, placed the Update folder onto the SD card with 'bcm4329.ko' and 'update_modules.sh' inside it. HARET wouldn't boot, it just froze.

I'll try a clean install of R134 with your new files overwriting R134's original files.
[HD Mini General] munjeni:
ok, thanks! Just only replace bcm4329.ko and zImage!
[HD Mini General] audio84:
Right, placing the update_modules file into the Update folder will cause HARET to freeze. If I don't use that, I can start it properly.. so I'll check to see if the battery's working without that file :/
[HD Mini General] munjeni:
My bug, sorry sorry sorry... wait a moment I will update all!
[HD Mini General] audio84:
Well I just realised that 127 had those files in the Update folder, but 134 didn't.. I'm trying different things to make it work :/
[HD Mini General] munjeni:
Sorry guys again, wait a moment I will post full update pack,sorry
[HD Mini General] munjeni:
Here is upgrade, and no need to install r134 from begining, just extract attachment to sd card and run haret!
[HD Mini General] audio84:
Too late, I already formatted the card :(

Not to worry though. I've installed R134 back onto the card, then placed the new upgrade files ontop of R134's. This SHOULD boot!

EDIT:

Well it booted fine :) I'll let you know on the results!
[HD Mini General] audio84:
Out of curiosity.. does this fix the lifetime of the battery as well? Or does it just fix the charge?
[HD Mini General] Wowser:
Very pleased with the patch by munjeni at post above and a highly recommended one in addition to the current beta r134. The keypads are definitely less bright and the battery does have improved ac-usb detection. But the time bug is still present - my time immediately galloped ahead by one hour! Excellent work.

EDIT- Windows Mobile showed 20% before I exited into Android. Using Dial this: *#*#4636#*#* with wifi turned on upon boot up showed 40/100. After 7 min had slowly reduced to the 21/100 battery level and stayed there. Battery health described as good (36.9 deg). From 00:00 to 09:00 the time since boot shows battery voltage consistently at 3678mV. At 14:30 showed 3670mV and 19/100. Under battery history/other usage both with since last unplugged and total since last boot options: "Running 155.3% (blue); Screen on 98% (red); Wifi on 98.5% (red); wifi running 98.2% (red)". At about 30 min with still showing 19 /100 , I put in the USB charging plug (with wifi still going) and the battery voltage is around 3794mV - 3812mV temperature steadily increased from about 36.9 deg to 41.2 deg over 22 minutes. At 33 min and 40 min, shows 20/100. At 44 min, 21/100. Time is steadily increasing too (at 50 min mark, time is now 22 min ahead since plugged in the USB at the 30 min mark when the clock time was the same as local time).
[HD Mini General] audio84:
I suppose one way of fixing this is to set the screen to never sleep while on USB mode. The time only jumps forward if it's sleeping while plugged in! This worked for me.

However the time is still a little fast - as someone said, it's about 10 minutes fast over a period of about 6 hours.

Great work though, tried it and love it so far!!!
[HD Mini General] audio84:
Another update: It appears that although the phone now charges with the new update, and that USB works, it says it's at 100% and stops charging after about 15 minutes, even though it's not. :(

EDIT:

Actually this only happens for about 10 minutes, then it carrys on charging?
[HD Mini General] munjeni:
Thanks guys! I want to say it is temporary fix, as a r0bin say next release will be better!

Thanks but I not understand what you want to say (I use google translate!), please explain better.

yes I know that, and I found where is problem! See DMESG "sleep function" ! I think fixing it will fix time bug! Enjoy with this update until new release come out...
[HD Mini General] zio_rudy:
thank you munjeni, i will test you "patch" this afternoon a report feedback. what do you mean with "pay attention" with your patch?

waiting for the time fix patch...it will be awensome!

thank you again!
[HD Mini General] munjeni:
I say it becouse new battery driver is not fully tested! How to pay attention? Simple! Dial this: *#*#4636#*#* , open battery info and pay special atention to battery voltage becouse green lamp is displayed at 4050mV and green lamp reporting that battery is full, but charging is in progres! I not know if battery charging is stoped at 4200mV !!! I think best way is to turn off charging when you see green lamp!

It will be tested in next time, I will report if battery "full" charging is safe!

EDIT:

Yes, I've tested full charge, and its safe (battery is full charged when have 4200mV, and battery charging "stop" is controled by chip inside or maybe by processor!). You do not have to worry about charging!
[HD Mini General] audio84:
What I meant was, if the batter is flat and I put it on charge, it would say it's at 100% ten minutes later, even though that's impossible. Then it would jump back to the level of charge it was originally at. Just for you to know :)
[HD Mini General] munjeni:
Ok, thanks, and do not worry, we were described the charging process in previous posts, "how engineers made ​​way related to battery.dll and marketing", but I agree that it is not a perfect driver... will be in future
[HD Mini General] -r0bin-:
dunno if it helps, but i found something with rID value from SMEM:

when rID < 270, we are on battery

when rID ~=300, we have high current charge (AC) then it goes down to ~270 at end of charge

still those values are not similar for each samples I have, but might be useful somewhere?
[HD Mini General] munjeni:
Maybe constant for something? Other things we have all good but only level is not good sometimes. Also I found something when Elixir-app-widget working in background (battery values goes crazy)
[HD Mini General] zio_rudy:
i format my sd card and install 10.07.2011_r134++ android and your update.

now charge from usb (some delay again...but its about 5/6 second, absolutly acceptable :)).

i'm now charging from usb (43°, 3802 mV). in WM it was like 20%.

android now (20min in charge) says that its full! not possible i think. (i dont know but my clock really run fast, faster then 10min in 6hrs that someone report).

keypad-backlight still on when is in stand by.

(n00b question: i pasted the 134++ in the root with update folder, booted android, deleted the HARET_PHOTON7227.exe and paste the heret.exe of munjeni, the update folder and the other files there is in the last munjeni's patch. right? or i miss something?)

EDIT:

unplugged the usb charge and rebooted its say a range of data about the battery load. 51% to 54% to 50% back to 52%. 38°C 3736 mV with only android assistant working. the keypad-backlight now turns off when in stand by. its on when is on charge and in stand by.

good work!

EDIT2: now the keypad-backlight works well even plugged with the usb in charge! keypad-backlight archived :D
[HD Mini General] Ray2210:
This fix is only for r127 or not??????????:confused:

Or both version also can use??????????:confused:
[HD Mini General] munjeni:
read posts mate, no, this is only for r134 !
[HD Mini General] Wowser:
Why not take the plunge and go for r134 beta with the patch from munjeni and report your findings. r134 beta has G-sensor, L-sensor, more stable internet data connection, good touchscreen response and better keypad backlight amongst other fixes. Alternatively there is bound to be a new build with even more improvements thanks to the porting team...
[HD Mini General] munjeni:
you are totaly wrong, button leds is bassed on room lights!!! Try your phone in darkness room and try your phone in lightest room you will see how its work
[HD Mini General] pwel:
I did 3 different charging tests with different sources (2x AC, 1x USB) and for all three, the current ends at 100mA at rID=280. This value seems to be different for each Mini, about +10 or -10. However, from most people there is only 1 curve available
[HD Mini General] pwel:
works great! thanks! only time running too fast but I don't care for now
[HD Mini General] LEO K:
hey munjeni:

work fine , thanks.
[HD Mini General] munjeni:
Some new fixes (market full fixed so you not need to umount sd card anymore!)...etc ... I will report link to developers to implement fix in his release after some tests
[HD Mini General] audio84:
Any other fixes we can expect in the next release?
[HD Mini General] derefas:
after munjeni patch , backlight don't work correctly , i turn off phone, backlight working, in darkness don't see any change
[HD Mini General] munjeni:
Pwel, what you think?

wPercent = ((wVolt - min_volt + (rId / 10)) * 100) / (max_volt - min_volt - (rId / 10))
[HD Mini General] GeForZero:
Dear munjeni, first of all i'm very happy with your patch. It's look great for me. Bt light is had dim to normally as winmo and battery charger worked find.

Thank you.
[HD Mini General] GeForZero:
Dear munjeni, my battery charging is shown 58% but the voltage is shown 4135 mV. As your advised the full scale of battery is at 4200mV. Why my droid (r134+patch) is shown only 58%? Please advise.
[HD Mini General] munjeni:
Hi, battery is full fixed by r0bin, other things also, so please wait new release!
[HD Mini General] motefarreghe:
thank you,It is excellent!!!
[HD Mini General] kiretocin:
and when it will be? :D
[HD Mini General] iPlasm:
Be Patient.... Just wait!

It is a test version, not daily use.
[HD Mini General] fluffy.khv:
With latest update from -r0bin-, battery drain comes to be good enough (full workday for one charge), but functional buttons now always active :(
[HD Mini General] munjeni:
R169 willful bug or only bug or wrong code uploaded to svn?

static int htc_battery_thread(void *data)
{
#define BATT_SAMPLES_NUMBER	30
struct battery_info_reply htc_batt_data_smooth;
int percent_tab[BATT_SAMPLES_NUMBER];
int tab_index = 0;
int i;

//struct battery_info_reply buffer;
daemonize("battery");
allow_signal(SIGKILL);

while ((!signal_pending((struct task_struct *)current))) {
//when battery is suspended, work slower to save power
if(bat_suspended)
msleep(10000);
else
msleep(1000);

[COLOR="Red"]#ifdef NO_BATTERY_COMPUTATION_IN_SUSPEND_MODE
//dont work in sleep mode!
if (bat_suspended)
{
//update the batt level with the samples we have
if(tab_index >= 1)
{
int smooth_lvl = 0;
//compute average level
for(i=0;i<tab_index;i++)
smooth_lvl += percent_tab[i];
smooth_lvl = smooth_lvl / tab_index;
printk("%s, %d samples only, average percentage=%d\n",__func__,tab_index,smooth_lvl);
//smooth batt level
htc_batt_info.rep.level = smooth_lvl;
htc_batt_info.update_time = jiffies;
//update power supply class
power_supply_changed(&htc_power_supplies[CHARGER_BATTERY]);
}
tab_index = 0;
//put on sleep, waiting for signal to wake up
printk("%s, put batt thread on sleep!\n",__func__);
wait_for_completion(&batt_thread_can_start);
printk("%s, batt_thread_can_start!\n",__func__);
}else
#endif
{[/COLOR]
//read raw SMEM values
[HD Mini General] -r0bin-:
dude i dont know why you see bugs everywhere :rolleyes:

and i dont know why you always say we dont upload right code to svn, you are not victim of a conspiracy dont worry :D

but if you ask for it, this is a piece of code that is

not enabled

in r169

i keep the option to enable it in case it consumes too much battery in suspend mode, but after testing it seems all right.
[HD Mini General] munjeni:
r0bin, it is bug, please, it is a fact that code on svn and code in yor letest kernel is not the same... I say it becouse (I know it is disabled) if it is disabled you will have "{" , so if you use to compile that code you will have error, so it means you use "good code" like in your latest kernel, but for public you uploading (totaly other) code and I am confused about why is not like in your latest kernel! Thats all. And, again, I say, I do not want to go back again to the old story, I think we should stay united till the end! And sorry if I am not right! So please confirm you use code posted in svn in your latest kernel, I'm realy confused when some guys reporting "some strange" problems in my release (~ same as your), understand me? So PLEASE put "tested" code always to svn, ok?
[HD Mini General] -r0bin-:
i think you need to test things before you say it is giving error...

have you ever thought the "strange" problems might come from your changes before blaming the other devs?

please read my previous post for the answer
[HD Mini General] tzacapaca:
it's a bug..it's a bug..i can see it

:p
[HD Mini General] munjeni:
o k

That looks like one step forward and two backwards, and so we go in circles!