**** BEGIN LOGGING AT Thu Oct 06 02:59:56 2011 Oct 06 05:20:05 SHR: 03Martin.Jansa 07shr-chroot * r67db96fbabaf 10/ (1194 files in 40 dirs): system upgrade Oct 06 07:23:44 ybotspawn: morphis should be able to anwser your question, he usally shows up around 15 o'clock UTC Oct 06 07:24:25 if i remeber correctly there was someone trying to get the CDMA version running, but i don't know if he was successfull Oct 06 09:02:03 thansk Oct 06 09:20:47 GNUtoo|laptop: why use input-mtdev at all? can't you just use standard input-evdev for now?... Oct 06 09:21:55 didn't work Oct 06 09:22:11 evdev doesn't expect the MT_TOUCH etc... Oct 06 09:22:26 so there are 2 solutions to use evdev: Oct 06 09:22:33 1)modify the kenrel driver => I failed Oct 06 09:22:47 2)modify the userspace => useless since there is xf86-input-mtev Oct 06 10:04:18 SHR: 03GNUtoo 07meta-smartphone * reb39c82e4fce 10/meta-samsung/recipes-kernel/linux/ (linux-samsung-crespo/defconfig linux-samsung-crespo_git.bb): meta-samsung: linux-samsung-crespo: update defconfig for beeing able to run Xorg Oct 06 11:22:34 alsamixer now segfault on my nexus S Oct 06 11:22:36 it didn't before Oct 06 11:22:48 I reinstalled and I've the same problem Oct 06 11:25:54 Are the major problems with the Alarms application known? and if they are, is there a known workaround for making the alarm reliable? Oct 06 11:25:59 Hello everyone btw Oct 06 11:27:21 GNUtoo|laptop: do you have latest eglibc from oe-core-contrib/shr? Oct 06 11:27:40 maybe not Oct 06 11:27:49 if so should I rebuild everything? Oct 06 11:28:57 no, just upgrading eglibc should be enough Oct 06 11:50:36 ok nice Oct 06 11:50:37 thanks a lot Oct 06 12:56:04 whats the difference between shr-core and shr-unstable? Oct 06 12:56:29 Martix, shr-core is based on openembedded-core Oct 06 12:56:35 it's the new SHR Oct 06 12:56:53 but it has less software right now Oct 06 12:57:18 so shr-unstable will deprecate soon? Oct 06 12:58:03 can I use shr-core for writing recipes and testing apps? Oct 06 12:58:16 yes you should Oct 06 12:58:23 yes it will Oct 06 12:58:25 ok, thanks Oct 06 14:22:00 Does anyone here know if SHR supports phone and data connections over CDMA? Oct 06 14:40:04 ybotspawn, hi Oct 06 14:40:26 what phone do you have? Oct 06 14:40:32 CDMA is curreently untested Oct 06 14:40:44 so I guess that it doesn't work out of the box Oct 06 14:42:48 i was thinking about a pre Oct 06 14:43:00 as it seems like the only phone that could POSSIBLY support cdma Oct 06 14:43:13 but i was curious first Oct 06 14:43:40 is there even any built in libraries to communicate over cdma Oct 06 14:43:44 i guess thats the best question Oct 06 14:44:12 no idea, how's cdma? Oct 06 14:44:18 how different it is from GSM? Oct 06 14:44:40 you must ask morphis about pre state Oct 06 14:45:01 and look in the wiki before Oct 06 14:45:14 i checked the wiki Oct 06 14:45:14 http://wiki.freesmartphone.org/index.php/HardwareComparison Oct 06 14:45:16 ok Oct 06 14:45:18 not much is mentioned Oct 06 14:45:20 i saw that Oct 06 14:45:31 the notes are VERY sparse on cdma support Oct 06 14:45:48 ok Oct 06 14:46:08 none of the current core devs have cdma where they are.... Oct 06 14:46:50 lol because they live in countries where there is only ONE mobile standard, god forbid we settle on one standard here in the US Oct 06 14:49:12 Blame Canada Oct 06 14:49:58 LOL Oct 06 20:52:02 DocScrutinizer: I tried another battery. my phone still doesn't charge it over 60% -- any idea what could be wrong? Oct 06 20:53:23 well, maybe you don't finish the charging cycle properly, or the chip has "learnt" the battery has way more capacity than it seems to take now. Oct 06 20:53:50 DocScrutinizer: but I tried two different batteries? Oct 06 20:54:33 you'd need to read the bq27x00 datasheet and find out what are the preconditions for switching from xy% to 100% Oct 06 20:55:12 I'd guess it's Vbat>4.0V and Ichrg<50mA, or similar values Oct 06 20:55:58 if your charger is configured to abort charging before Ichrg< for bq27000, then it probably won't ever switch to 100% Oct 06 20:56:24 all this mere handwaving though, as I really forgot how that particulr detail of bq27x00 works Oct 06 20:56:34 so RTFM ;-D Oct 06 20:57:57 btw what phone, what chip, what battery and what method to read out those "60%" are we talking about? Oct 06 21:00:07 DocScrutinizer: gta02V7 and "om battery energy" Oct 06 21:00:10 your pastebin'ed hdq/dump yielded a value of iirc 70% here, with my updated bq27k-detail script Oct 06 21:00:37 nfc about om battery energy Oct 06 21:01:26 values of 33%, 50%, 66% are a known issue, when multiple batteries get "detected" by the "app" that reads out capacity Oct 06 21:02:02 1full, 2 empty batteries. or 1/1, or 2/1 Oct 06 21:02:32 DocScrutinizer: om battery energy just reads sysfs Oct 06 21:02:43 :shrug: Oct 06 21:03:29 aiui your sysfs changed a lot, no? Oct 06 21:03:42 DocScrutinizer: changed when? Oct 06 21:03:50 dunno Oct 06 21:03:51 DocScrutinizer: om was started because of changing sysfs paths yes Oct 06 21:04:03 honestly, I'm not familiar with that shit anymore Oct 06 21:04:07 shit? Oct 06 21:04:32 toldya I got no idea what om battery energy is Oct 06 21:04:54 and I not even got a sysfs here to check Oct 06 21:05:33 if you don't bother to use my script to read out the raw values of bq27200 chip, I can't help any further Oct 06 21:06:03 DocScrutinizer: yep I send it yesterday? we discussed it here Oct 06 21:06:26 [13:34:26] DocScrutinizer: http://lindi.iki.fi/lindi/openmoko/openmoko-2.6.34-hdq-dump1.txt Oct 06 21:06:26 [13:34:59] DocScrutinizer: the mystery for me is that it stops at 69% Oct 06 21:06:31 [13:34:26] DocScrutinizer: http://lindi.iki.fi/lindi/openmoko/openmoko-2.6.34-hdq-dump1.txt Oct 06 21:06:31 [13:34:59] DocScrutinizer: the mystery for me is that it stops at 69% Oct 06 21:06:41 whoops :) Oct 06 21:06:57 for me that dump yields 70% Oct 06 21:07:46 so where does it stop now? 60%, 66%, 69% 70%, does it stop at all? Oct 06 21:08:45 DocScrutinizer: yes seems it is 70% in that dump Oct 06 21:08:56 :shrug: Oct 06 21:09:54 but with this another battery it seems to be stuck at 60% Oct 06 21:10:03 * DocScrutinizer notices he's in a foul mood, and apologizes for not helping any further today Oct 06 21:10:31 with "om battery consumption" at only -38062 so it is clearly not charging it fast anymore Oct 06 21:10:40 (those are uAmps) Oct 06 21:11:21 I guess I'll try the wall charger and booting from NOR u-boot and choosing shutdown from that menu :) Oct 06 21:11:37 not sure what other voodoo could work :P Oct 06 21:12:42 check voltage, current, and percentage. do so every 60s while charging, to a logfile. Will tell a story Oct 06 21:13:18 and RTFM of bq27x00 Oct 06 21:13:39 as I can't recall... Oct 06 21:13:52 will do if this voodoo trick fails :P Oct 06 21:16:49 I recall however shutting down system on bq27k signalling 8% (or any $random value) led to vastly off calibration of the chip, and system shutdown at >50% remaining true capacity Oct 06 21:17:22 in the early days of FSO Oct 06 21:18:05 o/ Oct 06 21:18:40 DocScrutinizer: the chip == the chip inside the battery? Oct 06 21:18:53 yup Oct 06 21:19:07 DocScrutinizer: ok but that does not explain why I see the problem now with two batteries Oct 06 21:19:45 check voltage, current, and percentage. do so every 60s while charging, to a logfile. Will tell a story Oct 06 21:22:18 pretty please compare voltage to percentage and see if it looks reasonable at all Oct 06 21:23:18 possibly your charger is configured to a CV of 4050mV or whatever, so there wouldn't be any way to get beyonfd ~70% of charge Oct 06 21:23:41 and bq27000 was completely correct then Oct 06 21:23:51 no use at all in guessing Oct 06 21:24:04 and will try&error Oct 06 21:24:08 wild* Oct 06 21:24:44 DocScrutinizer: in the paste http://paste.debian.net/134024/ the voltage is less than 4 Oct 06 21:28:43 DocScrutinizer: can I reset the charger state by removing battery for a day or so? Oct 06 21:28:51 which makes my proposal of pcf50633 being configured to stop charhing at that voltage even more likely Oct 06 21:29:18 no, charger state gets programmed by kernel (and uBoot iirc) Oct 06 21:30:18 DocScrutinizer: ok but I have not changed boot loader or kernel so I'm bit puzzled here Oct 06 21:30:41 hmm, dunno. Oct 06 21:30:53 it's still the same qi and linux 2.6.34 Oct 06 21:30:55 check voltage, current, and percentage. do so every 60s while charging, to a logfile. Will tell a story Oct 06 21:32:20 maybe not even kernel but some userland daemon does the programming, dunno Oct 06 21:32:35 and Qi probably doesn't Oct 06 21:33:23 and values could persist for years after that process ceased to program the charger, as there's bupbat making them persistent Oct 06 21:34:30 DocScrutinizer: I don't have such userland daemons Oct 06 21:34:49 so your CV setting of charger could have been at 4200mV since the times of OM2008, until some bad luck messed them up lately Oct 06 21:35:20 DocScrutinizer: the backup battery is dead on this unit so I think it has reset itself often Oct 06 21:35:25 sorry, I really can't recall all this anymore Oct 06 21:36:09 and I'm getting kinda annoyed of speculations while we are missing proper analytic data to base those speculations on Oct 06 21:36:35 check voltage, current, and percentage. do so every 60s while charging, to a logfile. Will tell a story Oct 06 22:19:51 seems removing battery for 10 minutes and holding power was enough to reset the state of something Oct 06 22:19:57 it's not charging at 600 mA :) Oct 06 22:20:30 s/not/now/ Oct 06 22:20:30 lindi- meant: it's now charging at 600 mA :) Oct 07 01:39:58 lindi-: obviously pcf50633 had some odd settings that survived all your booting and whatnot. Seems your system doesn't take care about properly configuring pcf50633 to the right CV voltage and probably also some other settings are odd Oct 07 02:54:49 I hate to keep reasking, but does anyone online know if SHR has been tested or at least has unstable support built in for CDMA phones? I hear Morphis is the guy to ask, so I'm hoping that he will see this and respond back :) If the question of which phone, the Palm Pre or Pre 2 **** ENDING LOGGING AT Fri Oct 07 02:59:58 2011