| *** xes has joined #maemo-ssu | 00:07 | |
| *** andre__ has quit IRC | 00:28 | |
| *** Skry has quit IRC | 00:29 | |
| *** Skry has joined #maemo-ssu | 00:31 | |
| *** dhbiker has quit IRC | 00:38 | |
| *** Vlad_on_the_road has quit IRC | 00:43 | |
| *** Woody14619 has quit IRC | 01:31 | |
| *** Woody14619 has joined #maemo-ssu | 01:31 | |
| *** Woody14619 has quit IRC | 01:31 | |
| *** Woody14619 has joined #maemo-ssu | 01:31 | |
| *** unclouded has joined #maemo-ssu | 01:58 | |
| *** arcean_ has joined #maemo-ssu | 02:00 | |
| *** arcean has quit IRC | 02:01 | |
| *** _LauRoman has joined #maemo-ssu | 02:10 | |
| *** LauRoman has quit IRC | 02:13 | |
| *** LaoLang_cool has joined #maemo-ssu | 02:16 | |
| *** LaoLang_cool has quit IRC | 02:29 | |
| *** M4rtinK has quit IRC | 02:31 | |
| *** arcean_ has quit IRC | 02:36 | |
| *** kolp has quit IRC | 02:37 | |
| *** xes has quit IRC | 03:32 | |
| *** _LauRoman has quit IRC | 04:05 | |
| *** discopig has quit IRC | 04:22 | |
| *** discopig has joined #maemo-ssu | 04:22 | |
| *** discopig has quit IRC | 04:22 | |
| *** discopig has joined #maemo-ssu | 04:22 | |
| *** Pali has quit IRC | 04:48 | |
| *** amiconn has quit IRC | 05:39 | |
| *** amiconn_ has joined #maemo-ssu | 05:39 | |
| *** amiconn_ is now known as amiconn | 05:39 | |
| *** DocScrutinizer05 has quit IRC | 06:03 | |
| *** DocScrutinizer06 has joined #maemo-ssu | 06:03 | |
| *** DocScrutinizer06 is now known as DocScrutinizer05 | 06:03 | |
| *** chainsawbike has quit IRC | 06:20 | |
| *** chainsawbike has joined #maemo-ssu | 06:21 | |
| *** M13 has joined #maemo-ssu | 06:47 | |
| *** amiconn has quit IRC | 09:09 | |
| *** amiconn has joined #maemo-ssu | 09:10 | |
| *** M13 has quit IRC | 09:47 | |
| *** andre__ has joined #maemo-ssu | 10:11 | |
| *** dhbiker has joined #maemo-ssu | 10:19 | |
| Estel_ | DocScrutinizer05, extremely usefull info here | 10:26 |
|---|---|---|
| Estel_ | pity that you won't put it on wiki, as it will gest lost, and in 3 weeks no one will remember it, too | 10:26 |
| Estel_ | (the things about bmi, shutdown graceful and not graceful levels, etc) | 10:26 |
| Estel_ | kerio, and what are your experiences with no compression? :P | 10:27 |
| Estel_ | kerio, what do you think would it be much code change to stop behavior of missing sysfs nodes when not calibrated? | 10:28 |
| Estel_ | in module? | 10:28 |
| Estel_ | maybe forking it and 99% of sensible users using fork would convince Pali to stop selling bulls about "send patch to mainstream" | 10:28 |
| Estel_ | if it's small change, maintaining it over next versions of bq27x00_battery would be easy | 10:29 |
| *** Martix has joined #maemo-ssu | 10:34 | |
| *** M4rtinK has joined #maemo-ssu | 10:54 | |
| *** LauRoman has joined #maemo-ssu | 11:16 | |
| *** kolp has joined #maemo-ssu | 11:22 | |
| *** M4rtinK has quit IRC | 11:31 | |
| *** M13 has joined #maemo-ssu | 11:52 | |
| *** lizardo has joined #maemo-ssu | 12:26 | |
| *** Pali has joined #maemo-ssu | 12:38 | |
| *** unclouded has quit IRC | 12:55 | |
| *** sunny_s has joined #maemo-ssu | 13:09 | |
| *** LauRoman has quit IRC | 13:24 | |
| *** futpib has joined #maemo-ssu | 13:43 | |
| *** futpib has quit IRC | 14:26 | |
| *** sunny_s has quit IRC | 14:59 | |
| Pali | ping Estel_ | 15:19 |
| Pali | ping kerio | 15:19 |
| Pali | I updated bme replacement wiki | 15:21 |
| Pali | there is one question (at wiki): what should battery applet show when battery is not calibrated and is configured to not use rx51_battery driver | 15:22 |
| kerio | "<charge>/<full charge> (CI)" | 15:22 |
| kerio | it's already written in my proposal afaik | 15:22 |
| *** xmlich02_ has joined #maemo-ssu | 15:37 | |
| *** xmlich02_ has quit IRC | 15:37 | |
| discopig | hi | 17:46 |
| Pali | kerio, small update which allow to do not use design capacity in status menu applet | 18:31 |
| Pali | package is in cssu-devel | 18:31 |
| kerio | yay | 18:32 |
| kerio | what does it do if bq27k isn't calibrated? | 18:32 |
| kerio | 0/0? | 18:32 |
| Pali | Estel_, I fixed hald-addon-bme, now it does not power off device when drivers are unloaded | 18:32 |
| Pali | kerio, it will show message that data are no available or battery is not calibrated | 18:33 |
| kerio | and does the usual guesstimate for bars and percentage? alright | 18:33 |
| Pali | yes | 18:33 |
| Pali | kerio, changes are on gitorious | 18:34 |
| kerio | gitorious where? | 18:34 |
| * kerio doesn't grok gitorious' interface | 18:35 | |
| Pali | merlin1991: I pushed new version of rtcom-messaging-ui-portrait to cssu-devel. I only changed version string to 1.0-1 and it fixed that infinity upgrade loop | 18:59 |
| Pali | merlin1991: add this version of package to cssu-testing list | 18:59 |
| *** NIN101 has joined #maemo-ssu | 19:21 | |
| merlin1991 | Pali: I'll do | 19:24 |
| *** BCMM has joined #maemo-ssu | 19:37 | |
| *** luf has joined #maemo-ssu | 19:42 | |
| Estel_ | Pali, thanks | 20:00 |
| Estel_ | Pali, is battery status applet also on your page, for non cssu-devel users? of course, I can install it from cssu-d, too, if not | 20:00 |
| Estel_ | Pali, so there remains one problem - about missing sysnode. You're not right, that it should be adressed by mainstream | 20:01 |
| Estel_ | look how busybox-power does it - it fixes things for maemo, *then* send patches to upstream | 20:01 |
| Estel_ | then, they're accepted in upstream | 20:01 |
| Estel_ | DocScrutinizer05, thought you may be interested in it (guy have problems with maemo repos) | 20:02 |
| Estel_ | http://talk.maemo.org/showpost.php?p=1331800&postcount=63 | 20:02 |
| Pali | Estel_, please read that email thread about bq27x al lkml | 20:03 |
| Estel_ | ok, any highlights to look for? | 20:03 |
| Pali | https://lkml.org/lkml/2013/1/19/162 | 20:03 |
| Pali | link is on wiki | 20:03 |
| Estel_ | btw, I'm mainly interested about our maemo case, not what mainstream does. It's good practice to fix for maemo, and send upstream - if they accept it it's fine, if not, fine too | 20:03 |
| Estel_ | ah | 20:03 |
| Estel_ | thanks | 20:03 |
| Pali | https://wiki.maemo.org/Bme_replacement | 20:04 |
| Estel_ | most of the times, they're much likely to accept it mainstream, if practically used "live" on some devices | 20:04 |
| Estel_ | Pali, seen mail on lkml, can't see hpw it is related | 20:05 |
| Pali | correct solution is to use debugfs | 20:06 |
| Estel_ | he talk about i2cget for userland, we fat about bq27x00_battery stopping censoring info for no reason | 20:06 |
| Estel_ | s/fat/talk/ | 20:06 |
| infobot | Estel_ meant: he talk about i2cget for userland, we talk about bq27x00_battery stopping censoring info for no reason | 20:06 |
| Pali | afk | 20:06 |
| Estel_ | correct solution is to comment out those damn 3 lines of code, that make it censor data for no practical or theoretical reason | 20:07 |
| Estel_ | so it always export to sysfs node what hardware tells it, period | 20:07 |
| Estel_ | someone who thought it's good idea to censor that data when not calibrated, was fucked in head | 20:07 |
| Estel_ | I must go off-line now, sorry | 20:07 |
| DocScrutinizer05 | yes | 20:08 |
| *** freemangordon has quit IRC | 20:25 | |
| Estel_ | Pali, as a suplement - you've talked with every user of your early stage bme replacement. Everyone think censoring that sysfs node is freakin bad idea | 20:40 |
| Estel_ | that must mean something. BTW, if me and DocScrutinizer05 speaks the same voice, it means even more :P | 20:40 |
| kerio | even a broken clock etc. etc. | 20:41 |
| kerio | Pali: hmm, is the default to not use design now? | 20:51 |
| Pali | kerio, when battery is not calibrated, see wiki | 20:51 |
| kerio | to *not* use design i said | 20:52 |
| kerio | oh i see | 20:52 |
| *** M13 has quit IRC | 20:53 | |
| *** arcean has joined #maemo-ssu | 21:29 | |
| *** BCMM has quit IRC | 21:50 | |
| *** futpib has joined #maemo-ssu | 22:04 | |
| *** XDS2010 has quit IRC | 22:05 | |
| *** luf has quit IRC | 22:15 | |
| Estel_ | Pali, new hald-addon-bme is in your page? | 22:34 |
| Pali | Estel_, yes, also dsme plugin | 22:35 |
| Estel_ | any more packages updated? | 22:35 |
| Estel_ | thanks | 22:35 |
| Estel_ | installing now | 22:35 |
| Estel_ | ~pali | 22:35 |
| infobot | from memory, pali is http://atrey.karlin.mff.cuni.cz/~pali/ | 22:35 |
| Pali | dsme plugin now fallback to bq27x temperature if rx51 is not available | 22:35 |
| Estel_ | new batt applet from cssu-dev only? | 22:35 |
| Estel_ | nice | 22:35 |
| Estel_ | ~bme-replacement | 22:36 |
| infobot | bme-replacement is probably http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement . Please, use wiki page to report bugs/problems and/or solutions to them! | 22:36 |
| Pali | yes, battery plugin is in cssu-devel | 22:36 |
| Estel_ | Pali, and what about shutdown, was it fixed? | 22:37 |
| Estel_ | edv1 and co? | 22:37 |
| Pali | not implemented yet | 22:37 |
| Estel_ | I want to update wiki if smth is solved | 22:37 |
| Estel_ | OK | 22:37 |
| Pali | it shutdown at edv1 | 22:37 |
| Estel_ | but one can unload modules | 22:37 |
| Pali | yes | 22:37 |
| Pali | https://gitorious.org/community-ssu/status-area-applet-battery/commit/3d3599743a598a833c1ecfa886ebf53fb6d11a12 | 22:37 |
| Estel_ | all right, I want to maintain wiki up to date, as no one else seems to be interested in it (and you're, rightly so, busy with coding) | 22:38 |
| Estel_ | please, Pali, include that gconf value to set up own shutdown limit, too :P | 22:40 |
| Pali | ok, later | 22:40 |
| Estel_ | best would be to make it inclusive or exclusive with edv1 | 22:40 |
| Estel_ | so, 2 gconf values | 22:40 |
| Estel_ | one for treeshold voltage | 22:41 |
| Estel_ | and one that triggers behavior of watching for shutdown voltage only after edv1 flag | 22:41 |
| Estel_ | so, for example, 3000 mV shutdown from first gconf value, but triggered only, id edv1 flag was set (if 2nd gconf value, for example, "wait_for_edv1" is 1) | 22:42 |
| Estel_ | or doesn't care about edv1 flag, if set otherwise | 22:42 |
| Estel_ | it allow to rise voltage for devices with gsm problem, or lower it for dual-cells, ignoring spikes (due to waiting for edv1) | 22:42 |
| Estel_ | Pali ^ | 22:42 |
| Pali | Estel_, next simple patch will be to replace #define VOLTAGE with value from gconf | 22:43 |
| Estel_ | OK | 22:43 |
| Estel_ | looks great | 22:43 |
| Estel_ | but you said voltage will be significant only, if edv1 flag isn't exported by kernel | 22:43 |
| Estel_ | it would be nice to have this gconf value working even, when kernel properly exports edv1 flag | 22:44 |
| Pali | I will add gconf value to disable edv1 | 22:44 |
| Estel_ | ok | 22:44 |
| Pali | (I wrote that on wiki) | 22:44 |
| Estel_ | so I'm talking about - it's good idea to make it inclusive, no exclusive | 22:44 |
| Estel_ | so one could have both $voltage from gconf AND edv1 gconf | 22:45 |
| Estel_ | = shutdown at $voltage, but only if edv1 flag is set | 22:45 |
| Pali | inclusive is simple, exclusive will be hard to write | 22:45 |
| Estel_ | or, when edv1 gconf is 0, shutdown at $voltage (ignoring edv1 totally) | 22:45 |
| Estel_ | I think most people that are willing to change shutdown voltage would like to have it inclusive with edv1 | 22:46 |
| Estel_ | to ensure that low voltage spike won't make device shutdown before edv1 flag | 22:46 |
| Estel_ | voltage can drop even to 3000 mV, without edv1 flag still in place, as it needs 15 seconds | 22:46 |
| Estel_ | Pali, I'm glad inclusive will be easy to write, but it will work for people that want RISING voltage, too? | 22:47 |
| Estel_ | for example, shutting down at 3300 mV? | 22:47 |
| Estel_ | (for people with gsm modem problems) | 22:47 |
| Estel_ | edv1 will be never set, then, so 3300 mV won't work without exclusive | 22:48 |
| Estel_ | flexibility is key here, to less rewrites later | 22:48 |
| Estel_ | when everyone will be able to set whatever fancy scenario, no one will pester you about features/bugs, later :P | 22:49 |
| Estel_ | Pali, I've seen your info about i2c_slave | 22:51 |
| Estel_ | problem is, no one know how to use it :P | 22:51 |
| Estel_ | properly | 22:51 |
| Pali | Estel_, what? | 22:51 |
| Estel_ | from wiki, you said that problems can be solved by using i2c_slave | 22:51 |
| Estel_ | I2C_SLAVE_FORCE | 22:51 |
| Pali | you can use i2cget without problem with force flag | 22:52 |
| Estel_ | no idea how to do it, properly, as no one want to access i2c wrong way and fuck something up | 22:52 |
| Estel_ | I see | 22:52 |
| Pali | use *only* for bq27200 | 22:52 |
| Estel_ | so it's just a matter of proper i2cget command syntax? | 22:52 |
| Estel_ | yes | 22:52 |
| Pali | i2cget -f | 22:52 |
| Pali | (check if -f is really force, but I think yes) | 22:53 |
| Estel_ | and it stop complaining about resource in use? | 22:53 |
| Estel_ | ok | 22:53 |
| Estel_ | well, lemme check it, if I dissappear, it mean something went wrong :P | 22:53 |
| Pali | and double check if you are sending command to bq27200 address | 22:53 |
| Estel_ | you're right, it works | 22:54 |
| Estel_ | how to determine that addres is bq27200? | 22:54 |
| Estel_ | address* | 22:55 |
| Estel_ | 0x55 | 22:55 |
| Estel_ | is bq27200? | 22:55 |
| Estel_ | it solves many problems, then | 22:56 |
| Estel_ | I still think sysfsnode shouldn't censor data, but I can at least workaround it by using 82cget directly | 22:57 |
| Estel_ | not ideal, but at least works | 22:57 |
| Estel_ | I appreciate you work on this, Pali, and I'm glad I could contribute by at least wiki | 22:58 |
| Pali | ok | 22:58 |
| Estel_ | just don't, *ever*, write "send patch to upstream", when we report something valid :P It makes people go berseker | 22:58 |
| *** lizardo has quit IRC | 23:02 | |
| *** xes has joined #maemo-ssu | 23:09 | |
| DocScrutinizer05 | >>dsme plugin now fallback to bq27x temperature if rx51 is not available<< WTF? bq27x temperature is as meaningless as my little toe's temperature | 23:14 |
| DocScrutinizer05 | actually tempreature from bq27200 is the most useless and void-of-any-meaning value you can read out from that chip | 23:15 |
| *** Vlad_on_the_road has joined #maemo-ssu | 23:16 | |
| Estel_ | DocScrutinizer05, except for the fact, that, in reality, it's always same as rx51 temperature :P | 23:17 |
| Estel_ | i.e. difference never exceeds 1C | 23:17 |
| Estel_ | and rarely ever exceeds 0.5C | 23:17 |
| Estel_ | also, nothing ever use that temperature for any real-life purpose, so we can safely ignore it? or I'm wrong? | 23:18 |
| * ShadowJK would expect bq27 temp to be close to that of the pcb it sits on | 23:19 | |
| DocScrutinizer05 | yeah, and temperature difference between my living room and outside rarely ever is >2°C (in spring and autumn, when my windows are opened wide) - MEH, the one is battery tempreature and the other one some bogus bullshit | 23:19 |
| Estel_ | I think that Pali followed our suggestion, that presenting not-accurate data is better than no data at all :P | 23:19 |
| Estel_ | why bogus? | 23:19 |
| DocScrutinizer05 | because that chip is not even near to battery cell | 23:20 |
| DocScrutinizer05 | and no, that value isn't useless or unused, bme uses it for batterty safety monitoring I'd say | 23:20 |
| Pali | dsme needs some value and what is better? some hardcoded? some reported by bq27200? | 23:20 |
| ShadowJK | I don't think either are very close to the batteri | 23:20 |
| DocScrutinizer05 | dang, my ignore filter failed | 23:20 |
| Estel_ | Pali, definitelly reported by bq27200 is better than hardcoded | 23:21 |
| ShadowJK | But the thermistor attached to madc is first source, right? | 23:21 |
| Estel_ | DocScrutinizer05, not very mature to use some bullshit ignore filter as argument in civilized discussion, really *shrug* feel free to leave conversation, though | 23:21 |
| DocScrutinizer05 | for cell temperature? there's only ONE "better", the theristor labeled "battery temp" in schematics | 23:21 |
| Estel_ | ShadowJK, yes | 23:21 |
| ShadowJK | Estel_; right | 23:22 |
| Estel_ | fallbacks to bq27200 only if rx51 one isn't available | 23:22 |
| ShadowJK | So I'd agree that bq27 is better than nothing | 23:22 |
| ShadowJK | For sure better than the one in omap :) | 23:22 |
| Estel_ | DocScrutinizer05 fails to understand, that dsme need *some* temperature to function | 23:22 |
| DocScrutinizer05 | this is a safety relevant design detail, you shouldn't mess with it | 23:22 |
| Estel_ | so if not bq27200, we would use dummy hardcoded palceholder | 23:22 |
| Estel_ | placeholder, even | 23:23 |
| ShadowJK | As long as madc continues to function, and battery temp thermistor stays attached, dsme will use exactly the same data as before, right? | 23:23 |
| Estel_ | ShadowJK, yes | 23:23 |
| ShadowJK | right.. | 23:24 |
| DocScrutinizer05 | ShadowJK: if those guys can't get the ADC-4(?) readout, then for sure they should SHUT DOWN that crap, and not try to handle LiIon cell based on some guestimate about cell temperature | 23:24 |
| Estel_ | can't agree, no temperature can be due to unloaded module or whatever | 23:24 |
| Estel_ | I want to be able to unload some module for debugging or whatsnit, without device shutting down in flames, because someone thought it's good idea to hardcode it. | 23:25 |
| *** XDS2010 has joined #maemo-ssu | 23:26 | |
| ShadowJK | The battery temp sensor is kinda useless anyway, with that big air gap (or was it air gap + shield?) between it and battery :/ | 23:26 |
| Estel_ | agreed. | 23:26 |
| Estel_ | air+ shield, in fact | 23:27 |
| DocScrutinizer05 | not at all, the battery temp sensor is in contact with shield which in turn is in *tight* contact with battery | 23:27 |
| Estel_ | sure, with insulating layer between. and definitelly not "tight" | 23:27 |
| Estel_ | only springs are tight, without them battery can fell of on it's own | 23:28 |
| Estel_ | s/can/will always/ | 23:28 |
| infobot | Estel_ meant: only springs are tight, without them battery will always fell of on it's own | 23:28 |
| Estel_ | springs, otoh, touch even thicker plastic insul. layer | 23:28 |
| ShadowJK | Oh I remembered it as the batt thermistor not touching anything at all except for the point it's soldered to the pcb | 23:28 |
| Estel_ | Because it's that fckin way | 23:29 |
| ShadowJK | ah lol | 23:29 |
| * DocScrutinizer05 feels like watching those experts who go like "that fuse is useless anyway, so let's use a nail to short it" | 23:29 | |
| Estel_ | IDK why DocScrutinizer05 thinks it's attached to shield | 23:29 |
| Estel_ | in contact = may accidentaly touch it, from time to time, or not at all | 23:30 |
| Estel_ | before it would detect any temp. change, it would be dissicipated in whole ground plane already | 23:30 |
| ShadowJK | hm, if I used my 1000mR battery, I'd get some mean heat dissipation, wonder if that would provoke bigger temperature gradients | 23:30 |
| Estel_ | and bq27200 temp sensor would know it already, too | 23:30 |
| *** Vlad_on_the_road has quit IRC | 23:31 | |
| Estel_ | belive me, when I got some overheating batteries, that rx51 sensor was last thing that knew about it | 23:31 |
| Estel_ | I first felt it through backcover, lol | 23:31 |
| Estel_ | 30 seconds later sensor started to notice slowly rising temp | 23:32 |
| ShadowJK | Never had a situation like that myself | 23:32 |
| Estel_ | when backcover was 60C already | 23:32 |
| ShadowJK | Except on N810 | 23:32 |
| Estel_ | I had some funny batteries around | 23:32 |
| Estel_ | Pali, you said unloading both bq27x00_battery and rx51_battery won't cause reboot now. So dsme will work despite no temp. readings? | 23:33 |
| Pali | Estel_, I tested it and no reboot, but I do not know what will dsme do if it will not receivce temperature for 1hour/1day... | 23:34 |
| Estel_ | btw, keeping fuse analogy... we're talking about "if that fuse fails, let's redirect it through another fuse", instead of using hardcoded value, with would be exactly using a nail. | 23:34 |
| DocScrutinizer05 | oh fine. some self-certified experts declare battery sensor useless and thus suggest to replace its readout by a hardoced value or even some unrelated bogus shit. FINE, will you next redefine cmt to be a LTS modem? | 23:35 |
| Estel_ | Pali, OK. | 23:35 |
| Estel_ | DocScrutinizer05, you're talkung bullshit, no one replaces anything. | 23:35 |
| Estel_ | we use 2nd value, when 1st value is unavailable. | 23:35 |
| ShadowJK | New behaviour identical to previous in all normal conditions | 23:36 |
| Estel_ | 1st - marginal chances of that ever happening 2nd - if that ever happens, it's better than use hardcoded thing not related to anything | 23:36 |
| Estel_ | ShadowJK, exactly. | 23:36 |
| Pali | DocScrutinizer05, write solution what to do when rx51_battery driver is not loaded | 23:36 |
| DocScrutinizer05 | except that sensor is exactly NOT about _normal_ situations | 23:36 |
| Pali | and reboot/shutdown device is not solution | 23:36 |
| Estel_ | DocScrutinizer05 preffer shutdown, then. | 23:36 |
| Estel_ | I don't agree | 23:36 |
| Estel_ | I would like that energy spent on improving bme replacement wiki, or convincing that cripplig sysfs nodes is bad idea :P | 23:38 |
| Estel_ | instead of arguing about bullshit temp. readout, which, in practical life, is completely irrelevant (meaning anything only in theoretical situations, and even there, discussably) | 23:39 |
| DocScrutinizer05 | btw wtf is adc-x via anything bme related? | 23:40 |
| Estel_ | Pali, version number of packages haven't changed on your page, but content changed? | 23:41 |
| Pali | yes | 23:42 |
| Pali | look at date | 23:42 |
| Estel_ | hald-addon-bme and dsme-thermaobject, yes? | 23:42 |
| Estel_ | ok | 23:42 |
| Estel_ | if you would, in future, bump versions, it would be less asking you about it | 23:42 |
| Estel_ | just a suggestion | 23:42 |
| DocScrutinizer05 | and wtf would it ever be "not available"?? | 23:43 |
| Estel_ | DocScrutinizer05, due to rx51_battery module being not loaded. | 23:43 |
| * DocScrutinizer05 pukes a little while heading out | 23:44 | |
| Estel_ | take your time and have all pleasure ;) | 23:45 |
| *** LauRoman has joined #maemo-ssu | 23:48 | |
| *** freemangordon has joined #maemo-ssu | 23:50 | |
| *** freemangordon_ has joined #maemo-ssu | 23:50 | |
| *** freemangordon_ has left #maemo-ssu | 23:50 | |
| DocScrutinizer05 | on a sidenote: if nokia had thought bq27200 temp was *any* useful for battery overtemp/undertemp(!) protection, don't you think they *happily* had saved that thermistor from the BOM? | 23:52 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!