**** BEGIN LOGGING AT Sun Jun 07 02:59:57 2009 Jun 07 03:02:56 hey toaster, night! :-) Jun 07 03:05:23 who is working on shr-settings? Jun 07 07:45:34 wpwrak: btw, i'm using an AP atm with wpa which refused to give me dhcp until i used maxperf. Jun 07 07:51:41 re Jun 07 07:52:26 mrmoku|a`, dos1: thank you for your new dbus thing, and the links too. Im testing right now Jun 07 08:23:25 PaulFertser: argh :) seems thjat there's no weirdness that doesn't exist somewhere in that module :-( Jun 07 08:34:31 wpwrak: do you know atheros's code enough to fix the oopses recently reported? Because it seems it's a mess :-/ Jun 07 08:45:52 PaulFertser: probably ... the issue is more of finding a large enough block of idle time ... Jun 07 08:53:17 wpwrak: i understand... even without wlan our kernel is not really stable, it seems Jun 07 09:00:01 I'd like to test Koolu android beta7, but Qi does not work on my Freerunner (an issue with bad blocks as it seems). Jun 07 09:00:32 flohack: ah, i looked at your bad block map. there's indeed one of these darling early on Jun 07 09:00:48 I flashed uImage.bin to NAND kernel, system.img to NAND rootfs and extracted userdata.img to the ext2 SD partition. Jun 07 09:01:20 flohack: i wish you had a debug board ... then you could trace the skipping of the bad block. seems that this algorithm in Qi is broken Jun 07 09:01:23 Then I flashed and modified the newest u-boot according to the wiki. But android still does not boot. Jun 07 09:01:54 wpwrak: Hmmm...I'll ask if someone from Graz has a debug board Jun 07 09:02:18 flohack: weird that it doesn't work with u-boot, though. might be a different problem then Jun 07 09:03:13 wpwrak: It boots the kernel...the problem is something else. Jun 07 09:04:18 "I was not able to find installation files, sorry" that's what it says as soon as the kernel is loaded Jun 07 09:04:49 dos1|neo, so... it works? shall I push it to shr/import? Jun 07 09:05:24 flohack: hmm, kick the android guys, wherever they hang out ? Jun 07 09:05:41 =jffs2"r illegal character '=' in variable rootfstype Jun 07 09:05:51 That's what u-boot says before loading the kernel Jun 07 09:06:20 seems that the u-boot env is somehow broken Jun 07 09:06:32 what if you boot from NOR ? Jun 07 09:06:50 wpwrak: doesn't load the >2M android kernel, does it? Jun 07 09:07:09 Is someone proficient with u-boot here? Jun 07 09:07:12 ah, it's > 2 MB. crap. Jun 07 09:07:21 dos1 what does your qi patch mesn? Jun 07 09:07:25 * wpwrak ducks Jun 07 09:08:17 flohack: maybe you can send me your u-boot env ? Jun 07 09:08:42 Here is my u-boot env: http://pastebin.ca/1450505 Jun 07 09:09:31 I followed http://wiki.openmoko.org/wiki/Android_on_Freerunner#Modify_Uboot_as_Bootloader_for_more_than_2MB after flashing u-boot-gta02v5-1.3.1+gitr650149a53dbdd48bf6dfef90930c8ab182adb512-r1.bin Jun 07 09:11:18 hi everyone. gtk question. I try to make a part of my gui "clickable". Let's say a vbox container with all its label in it. I have tried many events from gtk, but none are triggered when I tap with my finger on the area. what events a tap with your finger is supposed to trigger? Jun 07 09:11:28 flohack: hmm, i think (from memory) that should be bootcmd=setenv bootargs ${bootargs_base} ... Jun 07 09:12:14 yup Jun 07 09:12:17 wpwrak: ? But that's what it is or is my vision a bit low today? :-) Jun 07 09:12:40 the "bootargs" is missing Jun 07 09:13:01 wpwrak: ahhhh....thanks... Jun 07 09:14:03 np. let's hope this helps a bit Jun 07 09:14:48 wpwrak: Ok, the u-boot complaint is gone Jun 07 09:15:04 but android still does not find the 'installation files' Jun 07 09:15:39 Has someone here ever installed android beta7 manually on NAND + SD? Jun 07 09:34:50 ok I found a way, simply listen to all event of a widget, to identify what happens when finger tap the screen (stupid me, wa simple) Jun 07 09:44:17 onen|openBmap: you here? Jun 07 09:44:44 onen|openBmap; do i recall correctly that when i close openBmap; my logs will be overwritten when i restart it? Jun 07 09:44:59 Zorkman: I am here Jun 07 09:45:29 Zorkman: the application log file, yes. The gsm/gps log fileS no Jun 07 09:45:50 ah, k, i can live with that :) Jun 07 09:46:12 Zorkman: did you understand that the gsp/gps logs were overwritten on startup? Jun 07 09:48:44 i just faintly remembered i scrolled over a message with regards to openBmap that had something to do with files being overwritten, and i said to rename; but didn't remember what files exactly :) Jun 07 09:48:48 just double checking Jun 07 09:49:12 although 486 is a nice number, i'm not hoping to stay on it forever :) Jun 07 10:06:21 Zorkman: I am not *that* bad that I would have overwritten gsm logs on startup ;-) (well I hope so :-P ) Jun 07 10:06:41 Zorkman: I have very much faith in your ability to increase this number ;-) Jun 07 10:07:11 Zorkman: I spent some time yesterday and this morning, on the GUI. pfff, painful. Jun 07 10:07:34 Zorkman: now gps, and gsm, are grouped by an expander, so that people could hide what does not interest them Jun 07 10:08:40 wpwrak: Could the patch mentioned here have an effect on my badblocks problem? http://lists.openmoko.org/pipermail/openmoko-kernel/2009-May/010104.html Jun 07 10:29:35 btw onen|openBmap; i cannot upload them with gprs... prolly due to bad connection.... Jun 07 10:35:15 Zorkman: files aims at a size of 20 kB. and does work through http upload Jun 07 10:35:28 Zorkman: I can imagine GPRS in general, should be fine... ? Jun 07 10:38:27 * mrmoku is off to obey to an european citizens duty and goes voting Jun 07 10:46:20 vote for the good ones mrmoku|away ;) Jun 07 11:19:02 is there some problem with gps and the latest shr-unstable? Jun 07 11:19:14 i can't get a fix Jun 07 11:26:12 Azog: i can... Jun 07 11:26:25 but first i only saw 9 sattelites for about an hour Jun 07 11:26:29 after two hours it was 11 Jun 07 11:26:31 normally Jun 07 11:28:06 normall i see 12 Jun 07 11:30:14 strange, well, i just started openmoko-agpsui and let it run Jun 07 11:35:24 mickey|squash, around? Jun 07 12:04:12 ah, i found the problem, there is no /sys/bus/platform/devices/neo1973-pm-gps.0; is there a workaround for this problem? Jun 07 12:05:15 anyone, know which branch of git.fso contains the linux26.vapi and posixextra Jun 07 12:10:46 got it :D Jun 07 12:18:55 is there any debugging information for gps besides that one in frameworkd.log? Jun 07 12:21:46 don't think so. frameworkd accesses the gps directly Jun 07 12:21:59 Zorkman, sure thing :) Jun 07 12:24:37 ok, so frameworkd thinks, that gps is powered on at /sys/bus/platform/devices/neo1973-pm-gps.0/pwron, but there is only /sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.7/neo1973-pm-gps.0/power_on Jun 07 12:25:23 how can i fix this? Jun 07 12:25:42 Azog: use the right kernel? Jun 07 12:26:45 i use the latest image and kernel from http://build.shr-project.org/shr-unstable/images/om-gta02/ at the moment Jun 07 12:27:07 Azog: SHR-oemerge works with gps Jun 07 12:27:19 Sup3rkiddo: pong Jun 07 12:27:33 Sup3rkiddo: misc-vapi contains the stuff now Jun 07 12:27:47 i have moved it out of fsoframework to fix the dependencies Jun 07 12:27:51 I really doubt there's such a severe regression in shr-unstable Jun 07 12:29:23 Azog: careful, framework tries to turn it on in 2 locations and 1 path will never exist Jun 07 12:29:32 mickeyl: what do you think of last night's dbus patch? Jun 07 12:29:44 spaetz: ah, i check this Jun 07 12:29:49 mickeyl, yeah, got it.. thanks... was thinking of starting on otimed.. am lost where to start :( Jun 07 12:30:00 prolly the alarm Jun 07 12:30:03 mrmoku: just been in hamburg this week. the Piratenpartei has funny posters Jun 07 12:30:38 DocScrutinizer: nothing yet, i have not been able to follow any FOSS development for one week. need to catch up first Jun 07 12:30:39 * spaetz doesn't obey his German EU citizen duties this year... Jun 07 12:30:48 Sup3rkiddo: yep, alarm sounds good Jun 07 12:31:12 spaetz: you are right, power_on is 1 after starting tangogps; but i still don't see any satellite Jun 07 12:32:34 no clue about that, sorry Jun 07 12:32:59 hi there Jun 07 12:33:09 hi KaZeR Jun 07 12:33:41 Hey, I am no7 in openBmap stats. I should do more travelling :) Jun 07 12:33:51 Azog: close tango, open settings-gps, set to manual-on, delete pickle Jun 07 12:34:11 then wait for fix Jun 07 12:34:21 set back to auto Jun 07 12:34:29 wasn't that corrupt pickle thinng fixed ages ago? Jun 07 12:34:37 dunno Jun 07 12:35:04 DocScrutinizer: for me that doesn't work Jun 07 12:35:19 everything is "unknown", except "Fix: no fix" Jun 07 12:35:32 and after turning off "Fix: invalid" Jun 07 12:35:38 I'm not claiming that's the minimum needed. It just worked for me Jun 07 12:35:42 and in dmesg... sec... Jun 07 12:36:08 rxerr: port=1 ch=0x00, rxs=0x0000000c Jun 07 12:36:34 i have the same in dmesg Jun 07 12:40:14 just saying there's low likelihood to fix a major issue wrt sysfs nodes etc, when gps worked with a rootfs 10 days ago. Odds are you'll spoil more rather than fix anything by random mods Jun 07 12:44:28 standard procedure would be to go back to a "known good" rootfs and verify own test procedure, then do regression tests and git diffs. random patch-mess is causing troubles, nothing else Jun 07 12:50:56 mrmoku: tested your patch today? :-) Jun 07 12:54:07 dos1|away: is this your gps not working after a suspend? Jun 07 12:54:12 could be http://lists.openmoko.org/pipermail/openmoko-kernel/2009-June/010185.html then Jun 07 12:54:55 dos1|away: what's your qi patch? Jun 07 12:55:44 DocScrutinizer, and? Jun 07 12:55:51 ahh, me? Jun 07 12:55:57 well yeah... installed it Jun 07 12:56:10 don't know yet... there are some strange things happening Jun 07 12:56:18 like intone segfaulting Jun 07 12:56:24 and once ophonekitd vanished Jun 07 12:56:30 hmmm Jun 07 12:56:39 on the other hand... looks like connman works more reliable Jun 07 12:57:32 well I'd expect a few bugs to sow up now that never did before, due to the dbus response never happened Jun 07 13:11:51 mrmoku: btw seems I seen most of those without the patch as well :-/ Jun 07 13:12:17 hehe, did you update dbus? Jun 07 13:12:43 ophonekitd vanished for me several times last week Jun 07 13:12:59 (update) not yet Jun 07 13:13:54 managed to completely bork my kernel on SD, by doing a droptest o.O Jun 07 13:14:04 ouch Jun 07 13:14:22 strange thing Jun 07 13:15:14 I would like comments about my new GUI for openBmap. It can be seen here: http://myposition.wiki.sourceforge.net/GUI_thoughts Jun 07 13:15:36 I showed a friend how rugged FR is, and bat fell out. After that uSD kernel failed to boot Jun 07 13:16:06 ZorkAway: mrmoku: rhkfin: spaetz: ping (please give impression about gui (see wiki link a little above) ) Jun 07 13:18:13 onen|openBmap: don't you have double information? Jun 07 13:18:42 two times "GSM", MCC, MNC, LAC, ID, strenght? Jun 07 13:18:51 ZorkAway: yes, indeed, for ease of comparison Jun 07 13:19:09 Zorkman: but "there can be only one" Jun 07 13:19:15 what do you mean? Jun 07 13:19:27 that you're going to chose on of both? Jun 07 13:19:41 Zorkman: you can easily compare the old presentation and the new one, to see if you find it clearer, etc... Jun 07 13:19:47 ah k Jun 07 13:19:48 Zorkman: yep Jun 07 13:20:20 first of all, i think writing the complete names is of no use... Jun 07 13:20:35 it will certainly result in too much clutter Jun 07 13:21:14 and on a first impression: i like the new look (in a tabel) Jun 07 13:21:39 I also agree with what somebody said yesterday: not so many decimal numbers for speed Jun 07 13:23:22 Zorkman: sure thing, first validate the new table approach before breaking everything Jun 07 13:25:49 onen|openBmap, well... I don't care ;) I just turn it on... let it log... and never watch it :) Jun 07 13:26:02 dos1, what are your dbus findings? Jun 07 13:26:43 * onen|openBmap knows mrmoku is pragmatic Jun 07 13:27:34 :) Jun 07 13:27:43 Zorkman: rhkfin: asked yesterday for explaination for mcc, mnc, etc. So I tried to put the complete name, but it makes the interface much less readable, I think Jun 07 13:28:03 nah, if you want explanation: add a "info" button somewhere, where you explain it all Jun 07 13:28:13 but not on the "main" screen Jun 07 13:28:19 Zorkman: I tend to think the same Jun 07 13:30:52 Just have some explanations on the web page and people can look it up there Jun 07 13:31:07 i agree Jun 07 13:31:15 we all have internet and know how to use it Jun 07 13:33:47 I wonder if this applies to me ;-) Jun 07 13:33:56 heh Jun 07 13:34:52 I like to think the more I learn about internet, the less I know how to use it Jun 07 13:39:58 Upgrading navit on root from svn-2287 to svn-2307... Jun 07 13:39:59 Downloading http://download.navit-project.org/navit/openmoko/svn/navit-svn-2307_armv4t.opk Jun 07 13:39:59 Killed -> what can be wrong? Jun 07 13:40:02 (opkg upgrading) Jun 07 13:56:50 opkg sucks Jun 07 13:59:25 i agree with spaetzAway Jun 07 14:05:23 flohack: let's see ... Jun 07 14:08:32 flohack: is your qi recent enough to include the patch ? i.e., built after may 7 Jun 07 14:16:02 * onen|openBmap does not bother mrmoku with artistic consideration this time Jun 07 14:17:31 Zorkman: rhkfin: spaetzAway: and the other interested: I added a complete interface screenshot with table for all sections. Please have a look and give feedback Jun 07 14:25:03 onen|openBmap: fine by me Jun 07 14:25:15 i care a lot more about functionality of openBmap than looks :) Jun 07 14:25:36 when improving something i would first improve the fact of those popups Jun 07 14:25:45 Zorkman: he he :-) nevertheless I always get more suggestions about gui :-P Jun 07 14:26:08 Zorkman: what now with my popups? Jun 07 14:26:43 i just don't like them :) Jun 07 14:27:02 during the popups i also don't think you can "scroll" through your apps Jun 07 14:27:09 (with illume top bar) Jun 07 14:27:33 Zorkman: spaetz raised this point Jun 07 14:27:34 and the windows to upload them: the button is only half visible, due to the keyboard popping up Jun 07 14:28:16 Zorkman: odly, the first popup with id/passwd is a gtk dialog, and works with illume arrows. the others are messagedialog and don't :-S Jun 07 14:28:33 out with the gtk :p ;) Jun 07 14:29:24 Zorkman: keyboard + hiding button. I remember having written this somewhere, as someone already did tell me. have to look at it Jun 07 14:29:59 Zorkman: my work on gui is to bring more infos (satellites, neighbours, number of cells seen so far). So reorganise and make some space for it Jun 07 14:30:10 people: intone uses much less cpu when playing audio, is there anyway i can use their (patched mplayer?) to listen to it with a2dp bluetooth? Jun 07 14:30:11 Zorkman: it is not "pure" look improvement Jun 07 14:30:45 onen|openBmap: it could be interesting to see "how many" cellID's i've captured during a session... Jun 07 14:31:07 maybe even a possibility to download a list with known cellids and show me how many new ones i've found Jun 07 14:31:14 to stimulate us more :) Jun 07 14:32:02 Zorkman: A2DP BT should be just another alsa PCM device, from app's POV Jun 07 14:32:55 DocScrutinizer: the only way to play a2dp i know atm is mplayer -ao alsa:device=bluetooth /mp3/ Jun 07 14:32:58 Zorkman: yep this could be done with the dbus service I developed. ask if cell is known Jun 07 14:33:13 DocScrutinizer: is there a way i can set something, so that intone will route audio through bt? Jun 07 14:33:46 use alsa device 'bluetooth' for intone output? Jun 07 14:34:24 Zorkman: or set it to be he default device Jun 07 14:34:40 wpwrak: are you still there? Jun 07 14:34:42 if there is no way to set up intone to use this device, then intone is broken by design and needs augment Jun 07 14:35:44 mabe it's possible, but i don't know how... will take a look at it... Jun 07 14:36:43 Zorkman: general rule: no audio app shall have a hardcoded audio device. A setup option is mandatory Jun 07 14:37:43 flohack: yup Jun 07 14:38:16 dos1: I like the new splash themes swicher in shr-settings Jun 07 14:39:09 the only valid botch would be to have a unique dedicated device like e.g. 'alsa-intone', then set up .asound to associate a physical device to this symbolic name Jun 07 14:40:36 wpwrak: I just flashed qtextended, basically I used the qi which is included in android beta7, because someone told me android requires a patched qi. That version however, does not have a git hash in it's name, so basically I can't tell. Jun 07 14:40:49 Zorkman: nevertheless a lot of audio apps are borked and use a hardcoded 'default' device. This is absolutely deprecated Jun 07 14:41:15 I'll try to boot QtE with a stock qi a bit later and report back whether that Qi boots the device successfully. Jun 07 14:42:15 flohack: ah, someone recently offered a theory what it was that android had to hack into their qi. hmm, what was it again ... ? Jun 07 14:42:34 flohack: might be something non-essential. let's hope that :) Jun 07 14:43:01 wpwrak: nand psrtition table Jun 07 14:43:18 ... can't remember sorry. But if the stock qi can boot qtE, we can safely assume that the issue is already solved. Jun 07 14:44:05 wpwrak: PaulFertser is right, android beta7 can run on NAND only, but requires three partitions (kernel, rootfs, data) Jun 07 14:44:25 wpwrak: the definition of the third partition is what the qi patch does Jun 07 14:46:11 * mwester is convinced that any distro that requires a custom bootloader is to be avoided at all costs. Jun 07 14:47:15 * lindi- is convinced that any boot loader that can not be configured with configuration file/block is to be avoided :P Jun 07 14:50:59 lindi-: kexec Jun 07 14:57:29 PaulFertser: is there some sort of menu program already? Jun 07 14:57:57 let me read Qi source code to figure out how to make it load an initramfs Jun 07 15:00:41 lindi-: best method is to link your initramfs to the kernel Jun 07 15:01:11 lindi-: there's some menu program in angstrom. Jun 07 15:03:16 PaulFertser: then i couldn't edit the initramfs on the device itself easily? Jun 07 15:04:04 it's this "boot/initramfs.gz"? Jun 07 15:04:36 I see it in source only in ./src/cpu/s3c6410/om_3d7k-steppingstone.c: * .initramfs_filepath = "boot/initramfs.gz", Jun 07 15:05:45 PaulFertser: is there a similar option for gta02? Jun 07 15:06:34 lindi-: it should work for gta02 too, but i never tried it Jun 07 15:07:32 lindi-: are you sure you really need to efit initramfs on device easily Jun 07 15:07:39 yep Jun 07 15:13:55 mwester: yeah, that approach has a very foul smell to it ... Jun 07 15:14:46 PaulFertser, flohack: (data partition) that explains it then. oh dear, this gets messy. is there perhaps an sd-only install mode too ? Jun 07 15:17:12 lindi-: (config) yeah, andy was quite dogmatic making it non-configurable. of course, this then breeds the kind of problems we now have with android. my approach would be to try to eliminate the need to configure. e.g., if you're doing a completely new system anyway, why not kill NAND while the killing is cheap ? ;-) Jun 07 15:18:40 wpwrak: but all i have is this lousy gta02 :) Jun 07 15:19:28 wpwrak: in kernel testing I need to be able to boot different kernel versions easily Jun 07 15:20:21 PaulFertser: at least placing empty initramfs.gz did not have any effect. Qi only blinked AUX twice as normally Jun 07 15:21:12 PaulFertser: and sudo grep initr /dev/mtdblock1 finds nothing. Jun 07 15:21:44 wpwrak: maybe i'll hack Qi to use uboot-env :) Jun 07 15:21:48 lindi-: but then sd should be perfect for you :) Jun 07 15:22:00 lindi-:arrrrrgh |-((( Jun 07 15:22:20 lindi-, in that case, why not just use uboot?????? Jun 07 15:22:40 mwester: it talks to glamo Jun 07 15:25:07 removing the glamo stuff would be a more desirable solution than further corruption of Qi, I think. (and is probably just a config option to uboot) Jun 07 15:25:37 mrmoku: i Jun 07 15:25:40 uh Jun 07 15:25:46 mrmoku: i'm happy with new dbus :D Jun 07 15:27:33 mwester: i'd be happy if Qi cycled between uImage-GTA02.bin.{1,2,3} instead of requiring me to have three partitions to support three different kernels Jun 07 15:27:57 that should be fairly easy to code Jun 07 15:28:33 lindi-, I think based on the feedback from users in general, and the failure of the community to create a "micro-kexec-env", that Qi has failed for the gta02. Modifying uboot is probably a better solution. Jun 07 15:29:10 By all means, add code to Qi for yourself, but I can't see that you would be adding value when compared to fixing whatever might be wrong with uboot. JMO. Jun 07 15:29:26 mwester: well uboot is much more complex and difficult to modify surely Jun 07 15:29:42 I guess that depends on the nature of the mods. Jun 07 15:29:46 yep Jun 07 15:30:03 my longterm wish for uboot would be forcing fast charge mode Jun 07 15:30:12 and showing current_now Jun 07 15:30:25 should be easy ;) Jun 07 15:30:26 but now that we have the glamo issues i'm not sure if its good for the bootloader to talk to glamo Jun 07 15:30:27 dos1, good to hear Jun 07 15:30:32 mwester: yep Jun 07 15:31:15 AFAIK, the issue is that uboot avoids the WSOD we have right now _because_ it talks to the glamo Jun 07 15:31:22 mrmoku: i will say everything later, now girlfriend is here ;) Jun 07 15:31:33 mwester: which WSOD? ;) Jun 07 15:31:34 Since nobody can solve the kernel problem with the WSOD, I guess uboot is the fix we have. Jun 07 15:31:47 mwester: i'm confused now Jun 07 15:31:53 The outstanding WSOD -- the one on the "must-fix" list for the current kerrnel. Jun 07 15:32:17 mwester: when using X? Jun 07 15:32:44 mwester: the "Xorg causes WSOD if you try to stop it with gdb" issue? Jun 07 15:33:08 The bug report describes the issue -- some users report a WSOD of sorts when resuming, but ONLY when using Qi. Confirmed by switching bootloaders. (has nothign to do with xorg) Jun 07 15:34:13 mwester: "#2274 Kernel regression: white screen of death reappeared with 2.6.29"? Jun 07 15:34:21 yep Jun 07 15:34:42 Reverting the commit did not fix it; we still have no solution. Jun 07 15:35:06 mwester: bt it says "* it is not reproducible using Qi" Jun 07 15:35:34 That's wrong. Jun 07 15:35:50 Unfortunately the discussion did not get captured in the ticket; it's in the mailing list archives. Jun 07 15:36:09 the original submitter also only used u-boot Jun 07 15:38:00 mwester: kernel list? Jun 07 15:38:03 Perhaps there are multiple issues then - the threads get quite entangled as I search for the pertinent messages. Jun 07 15:38:34 anyone in here using evopedia with succes? i get "Mounting Wikipedia data image: mount: Cannot allocate memory (failed)", but i have 2.5gig free Jun 07 15:38:42 The messages I saved claim to be on the kernel list, but I'm not finding them online right now. Jun 07 15:39:22 mwester: got something to grep for? Jun 07 15:39:40 The last message I can find is from Nelson to Nicolas Dufresne on 4/27 -- I'm sure there was follow-on discussion but I cannot locate it. Jun 07 15:39:50 fwiw, i doubt u-boot touches the glamo when resuming Jun 07 15:39:50 mwester: subject? Jun 07 15:40:06 "WSOD will need redisign (and spec)" Jun 07 15:40:10 [sic] Jun 07 15:40:30 Perhaps the subject line changed; I'm not finding the rest of the thread. Jun 07 15:42:07 found Jun 07 15:42:26 Ok, well, in any case there is _some sort_ of outstanding WSOD bug, even though nobody seems to be complaining of late. And perhaps I'm wrong about it being only with Qi, as I cannot find any of the messages that I seem to remember. I'm going senile... :( Jun 07 15:43:50 ("doubt" = it's not supposed to and the last time i looked at the code there was nothing that made it try.) Jun 07 15:44:06 mwester: at least the xserver-xorg-video-glamo driver will need a redesign Jun 07 15:44:20 mwester: one problem with such bugs can also be that someone with an old configuration reports what then looks like a new bug Jun 07 15:44:33 mwester: since just sending SIGSTOP to it will kill the whole device :) Jun 07 15:45:28 Maybe we should consider just closing these "stale" bug reports, and letting folks open new ones (which might have better and more current information)? Jun 07 15:46:21 Since there have been no complaints, and no followup that I can find on that bug for 6 weeks, I wonder if it is _really_ the show-stopper that it was first identified to be? Jun 07 15:47:29 mwester: well I hit it Jun 07 15:47:38 mwester: then i switched to Qi and didn't hit :) Jun 07 15:47:49 Ok. So is that the fix then? Jun 07 15:48:11 mwester: difficult to say for sure Jun 07 15:49:02 Since I've rather lost my initial enthusiasm for Qi, I would hope we can resolve the issue properly. But since I cannot reproduce it on either of the two GTA02's I have, I'm unable to help. :( Jun 07 15:49:28 mwester: can you reproduce the issue with xserver-xorg-video-glamo? Jun 07 15:49:44 I haven't tried. Is there a bug report on that one? Jun 07 15:51:53 mwester: i'll file it Jun 07 15:54:42 freesmartphone.org: 03sudharsh 07cornucopia * rc3e94e528619 10/libfsoframework/fsoframework/ (fsoframework-2.0.vapi interfaces.vala): fsoframework: Add DBus interface prefixes for fsotime Jun 07 15:54:42 freesmartphone.org: 03sudharsh 07cornucopia * r492d249c5115 10/fsotimed/ (9 files in 5 dirs): fsotime: Initial skeleton checkin for Alarm Jun 07 15:58:50 hey, can can someone here help me with python-ekementary hover object? Jun 07 16:07:44 mwester: https://docs.openmoko.org/trac/ticket/2294 Jun 07 16:15:24 mwester: would be nice if you could test this Jun 07 16:16:11 mwester: it's a fully reproducible WSOD that does not involve suspend/resume at all :) Jun 07 16:34:39 Ainulindale, dos1 : http://trac.shr-project.org/trac/ticket/506 can be closed Jun 07 16:43:27 lindi-: you were supposed to tweak Qi sources first to use initramfs. Jun 07 16:46:18 lindi-: i wonder where Nicolas gone... Do you have a way to reproduce wsod without X? Jun 07 17:02:03 F4t: You still looking for hover help? There are some example within shr-settings. Jun 07 17:03:08 PaulFertser: why? Jun 07 17:03:30 PaulFertser: can't uImage have initramfs in itself? Jun 07 17:04:47 Toaster`, ye, i fiund the examples, though it is still acting weird, when i set content it doesnt seem to set it... Jun 07 17:04:51 found* Jun 07 17:05:31 F4t, so i end up with unlinked content and have to .delete() it separately Jun 07 17:05:41 i mean Toaster`* :) Jun 07 17:07:37 F4t: how are you using it? Jun 07 17:08:01 F4t: Can you paste-bin the relevant section of you code? Jun 07 17:09:21 lindi- et al.: http://lists.openmoko.org/pipermail/openmoko-kernel/2009-April/010012.html - i think the proposed rework, if it hasn't already happened, could fit nicely into the KMS framework Jun 07 17:10:46 since, with KMS< everything gets abstracted away into a generalised "Give me a GEM buffer object to put on the screen" interface (glamo-fb.c would go away entirely) Jun 07 17:11:17 (but KMS is going to involve many weeks of suffering with a debug board for someone..) Jun 07 17:12:47 (sadly, it would also involve a rather large rework of xf86-video-glamo, but into something very generic and small) Jun 07 17:13:16 Weiss: but if that is needed for stability we should go for it Jun 07 17:16:55 i agree, but cautiously due to not understanding the origins of the problems reported Jun 07 17:17:23 actually i've run into a rather annoying dependency on KMS to get "EXA-via-DRI" to work, for a really boring reason Jun 07 17:17:49 (there's no sensible way to get a front buffer handle otherwise) Jun 07 17:19:27 dos1: it can Jun 07 17:19:28 Weiss: are all docs really under nda? is there anything i could do without singing it? Jun 07 17:20:07 dos1: any idea when we're going to get our next e or elm version bump? Jun 07 17:20:13 i wonder if anyone's confirmed our NDA status since SMedia got taken over by ITE.. someone did suggest to ask. ITE might not care and could just release the docs.. Jun 07 17:20:38 lindi-: potentially quite a lot.. initially it's a case of taking apart glamo-fb and fitting the bits into the KMS framework Jun 07 17:21:05 then adding hooks basically copied from any KMS DDX into ours Jun 07 17:23:21 i've done the skeleton hooks already: http://git.bitwiz.org.uk/?p=kernel.git;a=blob;f=drivers/mfd/glamo/glamo-display.c;h=e0c654f23867f945d1739e6fb7de31a5732d03ad;hb=refs/heads/drm-kms Jun 07 17:27:32 so is this the api that userland can use? Jun 07 17:27:53 instead of writing to ioports as root Jun 07 17:27:56 SHR: 03frazier.cameron 07shr-settings * rdb49cdf7727e 10/shr-settings: [Launcher] shr_homedir.HomeDir added Jun 07 17:29:41 yep, you allocate memory for a framebuffer in Xorg using GEM ioctls (via libdrm), then you do an ioctl to pass that to the kernel Jun 07 17:29:50 (i'm still studying the details) Jun 07 17:31:44 Weiss: so not just malloc? it needs to be physically contiguous right? Jun 07 17:32:53 Weiss: does kernel framebuffer console use the same api too? could we simplify the situation by disabling console? Jun 07 17:33:39 yes, fbcon is compatible with KMS in the latest kernels, so that happens "for free" Jun 07 17:33:59 it can't be a malloc because we have to allocate (and manage, between various applications) Glamo's own VRAM Jun 07 17:36:12 Weiss: ah, glamo has its own memory? how can that be mapped to userland process`s address space? Jun 07 17:37:10 currently it's exposed via /dev/fb0 -> glamo-fb -> glamo-core Jun 07 17:37:47 with KMS, it'd be /dev/dri/card0 (using GEM) -> glamo-drm -> glamo-core Jun 07 17:38:30 you can do a GEM ioctl to map it into process address space (the kernel does the necessary magic) Jun 07 17:39:29 Toaster`: could you use hoversel (or radios) to select backup or restoring in homedir? Jun 07 17:39:35 Toaster`: now it's wasting space :x Jun 07 17:41:15 tracfeed: messages.log attached to Ticket #504  || ophonekitd.3.log attached to Ticket #504  || frameworkd.3.log attached to Ticket #504 Jun 07 17:41:39 Toaster`: why do you want e version bump> somethink new/hot? :) Jun 07 17:41:56 Weiss: so when Xorg is running the pagetable has mappings from some virtual address to inside 0x08000000 ? Jun 07 17:42:05 Weiss: (looking at http://wiki.openmoko.org/wiki/Neo_FreeRunner_Memory_Mapping ) Jun 07 17:42:32 dos1: adding a HoverSel won't save much space.. and the e question relates to hopefully getting InnerWindows to work :) Jun 07 17:42:33 tracfeed: Ticket #504 (contacts and messages segfault (but calls are still possible)) updated Jun 07 17:43:05 lindi-: yep (cat /proc/iomem) Jun 07 17:43:19 Weiss: ah that is done even without KMS? Jun 07 17:43:34 Toaster`: so radios :) Jun 07 17:43:37 dos1: though I can't tell if it would do anything, as I have terrible luck getting anything to complile on my system. I would need a fair bit of handholding to set my system up. Hence why I like doing things in python :) Jun 07 17:43:48 yep. in fact, the memory management i mentioend is already in drm-tracking - it's exercised in those demos i reported a few weeks ago Jun 07 17:43:59 dos1: I'll see what it looks like... just fo ryou ;) Jun 07 17:45:30 dos1: will you ever answer me about your Qi patch? Jun 07 17:46:38 PaulFertser: uh? what did you ask? Jun 07 17:47:55 dos1: what is it for? Jun 07 17:49:23 PaulFertser: mwester said that setting loglevel twice isn't correct Jun 07 17:49:38 Weiss: are we sure that glamo can not be crashed by writing to memory that is mapped to the userland process that way? Jun 07 17:49:40 PaulFertser: and in default boot is should be handled by kernel default loglevel Jun 07 17:50:20 PaulFertser: so Qi shouldn't touch loglevel, until it's requested to do it; and distro kernels should have default loglevel specified Jun 07 17:50:52 dos1: i'd like it to not pass options for my usb gadgets either :) Jun 07 17:51:18 or assume that my flash has some sort of factory partition Jun 07 17:51:48 lindi-: it can't be crashed by accessing VRAM afaik, as long as it's kept off the actual registers. that's why i don't understand your gdb crash: there actually aren't many register accesses from userspace.. Jun 07 17:52:08 (you have to be able to draw on the framebuffer, at the end of the day) Jun 07 17:53:04 lindi-: well, i don't have factory partition (it's borked) and it boots ok :D Jun 07 17:53:27 lindi-: off for dinner, but will be back later.. Jun 07 17:53:53 lindi-: well, this idea needs wider discussion than several lines on IRC. Jun 07 17:56:07 dos1: why don't you fix your factory partition finally? Jun 07 17:56:41 PaulFertser: i'm lazy :D Jun 07 17:57:19 dos1: this idea to eliminate "extra" not strictly necessary parameters from Qi cmdline needs further discussion imho. Jun 07 17:58:11 http://people.openmoko.org/joerg/battery/batlog.txt.odf Jun 07 18:02:44 DocScrutinizer: btw, i was reading bq27000 datasheet lately (and noticed that i exported the wrong register in the latest patch) and i so no indication it should report capacity wrong after not full discharge. But we should export the flag indicating if bq27000 thinks its estimation is correct to the userspace for sure (will do this soon). Jun 07 19:11:18 PaulFertser: you seen in above document it jumps from 5% to 0% AND ADJUSTED DOWN charge_full. next discharge cycle the % calculation will be based on this lower charge_full value PLUS it will adjust charge_full down *again* Jun 07 19:13:08 DocScrutinizer: looks consistent with the datasheet, no? Jun 07 19:13:59 PaulFertser: so it will reach a point eventually where the whole span 100%..0% is eaten up with a few minutes of operation, and FSO will trigger shutdown on an actual chemical charhe of 95% and a voltage of 4V10 Jun 07 19:14:48 DocScrutinizer: it shouldn't loose that 5%, it is supposed to take that into account on LMD calculation. Jun 07 19:15:57 DocScrutinizer: is this log with the latest Qi alteration (or other means of setting MBC6?) Jun 07 19:17:16 aha. And what about the auto-adjust of charge-full to be seen in line 3040 of above document? it's from 1156501 down to 1151860. And I don't see another point to adjust that back up again, other han complete discharge Jun 07 19:17:42 nope. Dunno about that MBC6 thing Jun 07 19:17:46 dos1|away: are you here? Jun 07 19:17:56 DocScrutinizer: very decent log btw, thanks Jun 07 19:18:38 well the diagrams are quite ugly. I just left them in for other ppl to improve based on this Jun 07 19:18:54 dos1|away: I have updated the dbus bindings, but the #435 bug is still there. I wanted to let you know Jun 07 19:19:05 I'm no office wizard after all Jun 07 19:19:15 Log is what important. Jun 07 19:19:41 need to process my other logs eventually Jun 07 19:20:46 got some with FSO shutdown rule removed, where bat voltage is actually going down beyond 3.5V where GSM stops, even to 2.8V (iirc) where PMU SYS_low cuts out Jun 07 19:22:17 dos1|away: do you experience any benefits from the new dbus bindings? Jun 07 19:24:30 stefan_schmidt: so tomorrow evening we have FSO running with full modem support on omnia? ;-) Jun 07 19:25:04 PaulFertser: maybe I should upload the silly litle script to accuire these logs as well, for other ppl covenience? Jun 07 19:25:28 DocScrutinizer: i don't have a fast method of obtaining factory eeprom values for bq27000, do you know if battery aging is enabled? Jun 07 19:25:44 no idea, sorry Jun 07 19:25:45 DocScrutinizer: yes, probably lindi- will be interested. Jun 07 19:27:27 PaulFertser: but obviously, as the charge_full value is adjusted dynamically, I'd say this copes with battery aging (if bat is handled correctly) Jun 07 19:27:40 dos1|away: for you is there any benefit/bugfix from this dbus update? Jun 07 19:27:48 mrmoku|away: the same question for you too Jun 07 19:28:40 btw the both values mentioned above are a -0.4% adjustment for one cycle. I wouldn't agree this is real aging of chemical cell Jun 07 19:28:58 DocScrutinizer: looks like it doesn't matter as on the learning cycle LMD gets set strictly according to the measurements. Jun 07 19:29:04 PaulFertser: so eventually this value has to go up again Jun 07 19:29:31 DocScrutinizer: your LMD drop looks exactly like a result of a successful learning cycle. Jun 07 19:30:50 bah, I give a shit on LMD and learning cycles. It's obvious the CC is signalling 0% way to early, and we must NOT rely on it any way Jun 07 19:31:11 khiraly1, had not much time to play with it today Jun 07 19:31:52 mrmoku: Im just curious if it solves anything for you too. Because here the same problem (#435) remains. Jun 07 19:31:58 it's for mere user info *only* Jun 07 19:32:05 DocScrutinizer: hm, that depends on factory set values, that's why i'm asking again who and what sets that. Jun 07 19:32:14 khiraly1, #435 in which trac? Jun 07 19:32:31 khiraly1, and where did you install it from? the package I built? the second one? Jun 07 19:32:35 http://trac.freesmartphone.org/ticket/435#comment:17 Jun 07 19:32:42 mrmoku: the package you build Jun 07 19:32:44 built Jun 07 19:32:50 DocScrutinizer: btw, do you agree that the driver should signal POWER_SUPPLY_HEALTH_UNKNOWN if CC think that its capacity estimate can be incorrect? Jun 07 19:32:51 it does NOT depend. It's evident it is fact, from my log Jun 07 19:32:53 http://build.shr-project.org/tests/mrmoku/dbus_1.2.14-r0_armv4t.ipk Jun 07 19:32:59 http://build.shr-project.org/tests/mrmoku/libdbus-1-3_1.2.14-r0_armv4t.ipk Jun 07 19:33:01 khiraly1, ahh, ok Jun 07 19:33:06 that's the wrong one Jun 07 19:33:16 ahh, ok. So what is the good one? Jun 07 19:33:20 I updated it to r1 because I built it without that patch :( Jun 07 19:33:31 PaulFertser: I don't care, as it doesn't make any diff for system Jun 07 19:33:31 khiraly1, same url... just -r1 instead of -r0 Jun 07 19:33:35 ahh, ok. Thanks for the info! Jun 07 19:33:48 DocScrutinizer: to me it looks like 3625000 is the voltage preset at the factory as 6% capacity. Jun 07 19:34:02 khiraly1, dos1|away said he's quite happy with it... wanted to report more later today Jun 07 19:34:03 mrmoku: I update the bugreport too. Because there is someone else who tried out the new .ipk Jun 07 19:34:14 uhh... sorry for that Jun 07 19:34:28 DocScrutinizer: i mean a user might want to know when a new learning cycle should be done (for CC to estimate capacity correctly) so i need somehow export this information to the userspace. Jun 07 19:34:38 mrmoku: no problem. Im just gathering all available info on the bugreport. So thank you! Jun 07 19:35:17 khiraly1, would be nice to get it solved, yeah. It's very much what we would call a showstopper ;) Jun 07 19:35:22 feel free to show it to user. As long as system behaviour isn't determined any way by it, I don't care Jun 07 19:35:33 dos1, so... long report expected now :P Jun 07 19:35:55 mrmoku: i said No when opkg asked me to overwrite first file (system.conf) Jun 07 19:36:04 mrmoku: and Yes for second file (session.conf) Jun 07 19:36:05 DocScrutinizer: do you agree that bq27000 is smart enough and we want to rely on its estimations and that factory settings must be reasonable for that to work? Jun 07 19:36:08 mrmoku: and rebooted Jun 07 19:36:14 mrmoku: and it works good Jun 07 19:36:15 do the .29 kernel wifi issues still exist? specifically it not working? Jun 07 19:36:23 PaulFertser: see values and comments in lines 3045 and 3047 Jun 07 19:36:45 mrmoku: in every dbus using app i see warnings added by that patch Jun 07 19:36:55 mrmoku: in frameworkd there are lots of that messages Jun 07 19:37:04 but it doesn't change anything in working Jun 07 19:37:08 PaulFertser: system MUST NOT rely on any of bq27k readings Jun 07 19:37:10 !!! Jun 07 19:37:19 mrmoku: and after upgrading i didn't have any fail of phone functionality Jun 07 19:37:24 mrmoku: and i was suspending a lot Jun 07 19:37:30 DocScrutinizer: why? Because it doesn't work properly because of wrong factory settings? Jun 07 19:37:44 arrrrgh Jun 07 19:37:56 dos1: nice to hear. Im trying it out *now* (because yesterday I installed the wrong .ipk file) Jun 07 19:37:57 mrmoku: i have only one issue (not being able to turn off wifi), but acording to logs that was kernel problem Jun 07 19:38:01 mrmoku: and that's all :) Jun 07 19:38:02 because BL-5C *has NO CC*!! Jun 07 19:38:19 dos1, good thing :) Jun 07 19:38:19 and CC is guesswork only Jun 07 19:38:28 unrelyable Jun 07 19:38:35 DocScrutinizer: but if we have CC why can't we rely on it? From DS it looks like it's so cool and accurate and stuff. Jun 07 19:39:04 sorry, have to leave now. Zhink I made my point Jun 07 19:39:05 DocScrutinizer: if we don't -- well, we won't use it. But if we have it we expect reasonable values. Jun 07 19:39:16 DocScrutinizer: yes, see you later. Jun 07 19:39:23 DocScrutinizer: good convincing logs Jun 07 19:39:41 Some stuff for everybody to consider... Jun 07 19:40:09 khiraly1, could you report back if it fixes #435 for you? Jun 07 19:40:24 If I get some more positive responses I will put it in shr-unstable Jun 07 19:40:37 mrmoku: of course! I will also update on #435 too Jun 07 19:40:42 :) Jun 07 19:41:00 there are MadHAtter, who tried out the r0 Jun 07 19:41:10 I think he will tries this one too Jun 07 19:41:31 just I need to inform him in the bugreport;) Jun 07 19:44:48 khiraly1: i've just sent comment for that ticket Jun 07 19:45:45 dos1: I wanted to sent that;) Jun 07 19:52:09 dos1: I have updated too the #435;) Jun 07 19:54:58 dos1, any eta to multi message send? Jun 07 19:55:04 that's my most important bug atm ;) Jun 07 19:55:08 I'm going nuts. Jun 07 19:55:15 uh Jun 07 19:55:33 TAsn: mrmoku had code for that Jun 07 19:55:37 dos1: I just made my first test call. So far so good Jun 07 19:55:39 TAsn: but it segfaults Jun 07 19:55:48 I hope I can report the same tomorrow evening;) Jun 07 19:55:57 khiraly1: uh, i've just hit some problem Jun 07 19:56:06 * dos1 is checking log Jun 07 19:56:07 dos1, is it in git? Jun 07 19:56:17 if so i'll happily review it Jun 07 19:56:18 :) Jun 07 19:56:24 TAsn: yep Jun 07 19:56:24 (when i'll have the time, probably tomorrow) Jun 07 19:56:27 TAsn: in some branch Jun 07 19:56:31 bah. ;\ Jun 07 19:56:34 mrmoku, ? Jun 07 19:58:04 khiraly1: mrmoku I tried also the new dbus/shr -packages (on OM2009 from last night), so far everything's been good (ok, not a single call to me since last night....) Jun 07 19:58:25 rhkfin: no call no crash Jun 07 19:58:32 so i've just hit some problem Jun 07 19:58:44 rhkfin: the rule of thumb is if you can suspend the phone, everything is fine, and you surely get the incoming call Jun 07 19:59:29 khiraly1: oh, okay, I've tested the wrong packages ... Jun 07 20:00:09 TAsn: moment Jun 07 20:00:26 hm.. weird Jun 07 20:00:33 I have messages that don't appear in shr Jun 07 20:00:39 but do appear on my nokia Jun 07 20:00:53 mrmoku: 2009.06.07 21:48:47.962 oeventsd.action ERROR method RequestResource emited error: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Jun 07 20:01:15 damn Jun 07 20:01:20 many important ones :( Jun 07 20:01:29 mrmoku: but that look like some other problem Jun 07 20:02:41 TAsn: i thought that was fixed :x Jun 07 20:03:03 will keep an eye on that Jun 07 20:03:07 (already erased the messages) Jun 07 20:03:18 if it'll happen again I'll check it more throughly Jun 07 20:03:28 I missed a game of soccer with friends :) Jun 07 20:03:30 damn. Jun 07 20:04:27 btw, how do I turn on message receipts? Jun 07 20:04:49 TAsn: it's also in that branch from mrmoku Jun 07 20:04:55 TAsn: which is segfaulting Jun 07 20:04:56 :P Jun 07 20:04:57 :) Jun 07 20:05:08 dos1, oh, there are many changes and no way to know what caused it? Jun 07 20:05:10 damn ;\ Jun 07 20:05:24 TAsn: only that two changes Jun 07 20:05:28 oh, okie. Jun 07 20:05:38 will look on those (asap) Jun 07 20:05:39 TAsn: and it segfaults somewhere in dbus bindings Jun 07 20:05:46 oh, sucks. Jun 07 20:05:48 according to mrmoku Jun 07 20:05:55 I don't want to debug that crap :) Jun 07 20:06:24 I like C, not the glib-dbus bindings :) Jun 07 20:06:40 whatever, will give that a loop Jun 07 20:06:43 look* Jun 07 20:07:18 hey Jun 07 20:07:37 new libdbus I see? Jun 07 20:09:45 TAsn: better still it segfaults in the dbus-glib marshaller code :( Jun 07 20:09:59 Ainulindale: hey, I have an shr running FR :-) Jun 07 20:10:00 ; Jun 07 20:10:03 Ainulindale: we might have found a fix for that dbus annoyance Jun 07 20:10:12 onen|openBmap: good! Jun 07 20:10:13 mrmoku, ;\ Jun 07 20:10:14 mrmoku: might? Jun 07 20:10:20 Ainulindale: nothing you did work. You are lucky what do the others does work Jun 07 20:10:21 when will you try that? Jun 07 20:10:24 Ainulindale: well still testing it Jun 07 20:10:32 mrmoku, does it work atm? Jun 07 20:10:47 Ainulindale, get dos1 (and me?) access to the SHR oe repo! Jun 07 20:10:47 TAsn: what? Jun 07 20:10:48 :) Jun 07 20:11:04 mrmoku, you said you are still testing it, do the features work? Jun 07 20:11:08 Ainulindale: I installed the testing one. Some bugs there. But probably enough for now for obm. Jun 07 20:11:14 TAsn: there is no such thing as an SHR oe repo Jun 07 20:11:26 oe SHR repo then? Jun 07 20:11:27 ;) Jun 07 20:11:28 TAsn: well there is a limited access on purpose Jun 07 20:11:30 TAsn: I'm testing the new dbus server... not the features Jun 07 20:11:37 TAsn: OE repo Jun 07 20:11:44 (with a branch for SHR) Jun 07 20:11:59 mrmoku: small notes Jun 07 20:12:06 matchbox-keyboard in default image: can't see why Jun 07 20:12:08 mrmoku, have you tested the features with the new dbus server? Jun 07 20:12:11 as well as simple, saw no vote Jun 07 20:12:18 TAsn: no Jun 07 20:12:19 (splash) Jun 07 20:12:23 okie. Jun 07 20:12:59 we're not issuing ioctl( FBIOBLANK, FB_BLANK_POWERDOWN ) on turning off backlight Jun 07 20:13:11 is Valerio Valerio here? Jun 07 20:13:16 cause we're using xscreensaver... Jun 07 20:13:36 Ainulindale: you do cast vote for choosing default apps in shr images? Jun 07 20:13:53 onen|openBmap: for replacement, yes Jun 07 20:13:58 There already was a splash Jun 07 20:14:05 VDVsx:ping Jun 07 20:14:29 Ainulindale: I have been thinking what should obm need, to be granted a place on default desktop ? Jun 07 20:14:32 Ainulindale: yep, it was simple at start Jun 07 20:14:42 dos1: nah, it was the other one Jun 07 20:14:47 Ainulindale: and then you changed it Jun 07 20:14:47 As I put it there Jun 07 20:15:04 and i only sent patch for maillist Jun 07 20:15:09 dos1: wasn't at first image build Jun 07 20:15:23 onen|openBmap: that is? Jun 07 20:15:43 Ainulindale: it was Jun 07 20:15:44 Ainulindale: I meant, s/thinking/wondering/ Jun 07 20:15:57 onen|openBmap, I'm not sure that would be a correct choice Jun 07 20:15:59 Ainulindale: i still have fresh image with -simple as default Jun 07 20:16:06 Ainulindale: what does an app require, to get a space on default desktop in images Jun 07 20:16:07 but I'm not the one to ask Jun 07 20:16:11 since I use the lite image :) Jun 07 20:16:16 dos1: temporary thing only, due to a mistake Jun 07 20:16:28 dos1: it was intended to put don't panic as the default, see the logs Jun 07 20:16:36 and "SHR" as the default splash for stable Jun 07 20:16:37 TAsn: what do you mean? Jun 07 20:16:59 I don't see GSM triangulation as a core app Jun 07 20:17:01 onen|openBmap: well I'll tell you that when I won't be so sleepy Jun 07 20:17:11 but as I said, I don't see a lot of other stuff as core apps as well Jun 07 20:17:15 There was a wedding yesterday, I'm still trying to wake up Jun 07 20:17:16 (that ppl do think of as core apps) Jun 07 20:17:22 that's why I use the lite image Jun 07 20:17:22 ;) Jun 07 20:17:30 Ainulindale: ok, no hurry. Just the talk here made me think about it. Jun 07 20:18:24 well anyway I'm off to buy some cigarettes I definitely need something to help me to wake up Jun 07 20:18:34 TAsn: I see. Then you partially answer my question, which was: what is the requirement for an app to be in default image Jun 07 20:19:00 TAsn: so first thing, be a core app, if I understand you correctly Jun 07 20:19:01 onen|openBmap, that wasn't quite an answer as it was my opinion regarding obm Jun 07 20:19:13 onen|openBmap, the way *I* see it Jun 07 20:19:20 is that an app should be a core app, yeah. Jun 07 20:19:33 a default app should be something everyone probably need. Jun 07 20:19:41 Ainulindale: http://git.shr-project.org/git/?p=shr-overlay.git;a=blobdiff;f=openembedded/conf/distro/include/shr-autorev.inc;h=e3d6288a751be8f576bf14daf08c4b9244411bde;hp=0e565e6c8dc69e045f893c73a7b4ee1c32ed1ef8;hb=58524a19335e3f82f757f84c799e2bf320d7d42a;hpb=eb3b1b4f3737da7c904e2dc46ad8ed17b990940e Jun 07 20:21:17 dos1: Your commit, which was an error as it impacted on the two different images Jun 07 20:21:37 Ainulindale: hmm? Jun 07 20:21:45 TAsn: I understand. But to get a space there, is a big push for an app. Because people will probably give it a try, just to see what it is. Jun 07 20:22:03 onen|openBmap, as Ainulindale always says Jun 07 20:22:07 someone should cast a vote ;) Jun 07 20:22:24 dos1: too tired to explain, but this should go through ML anyways Jun 07 20:22:28 (replacement that is) Jun 07 20:22:30 I use the lite image anyway, I don't think it should be there, as for the full blown image, that might be a good idea. ;) Jun 07 20:22:35 not sure though. Jun 07 20:22:51 TAsn: well I think he is right (hope he won't read this), voting is a nice way of doing choices Jun 07 20:23:05 For the time being I'm off for cigarettes Jun 07 20:23:17 uh, i don't agree Jun 07 20:23:21 Ainulindale, sucks. smoking is bad. ;) Jun 07 20:23:23 that was new functionality Jun 07 20:23:35 and shr-splash-theme-simple was from start supposed to be default Jun 07 20:23:47 and shr-splash-theme-dontpanic was from start supposed to be addintional Jun 07 20:24:07 and i think voting would be needed when changing to dontpanic Jun 07 20:24:09 dos1: Check the IRC logs, you'll see it wasn't Jun 07 20:24:23 maybe it wasn't due to bug Jun 07 20:24:24 You'll also see it wasn't mailed in the "splash inclusion" topic Jun 07 20:24:37 TAsn: how I see the thing (and that's why I chose the full image), I want to install my phone, and everything is there. People ahve already chosen (a good) app for each use Jun 07 20:24:51 TAsn: sth like: work out of th ebox Jun 07 20:24:57 And in the end you'll also see that this discussion is pointless as in the end, I don't care, I was merely stating the procedure Jun 07 20:25:20 onen|openBmap, I like my apps ;) Jun 07 20:25:29 so I install lite. Jun 07 20:25:33 The fact that dontpanic was or wasn't the intended default by you is of no interest to me as at some point it was the default, and was changed without a vote Jun 07 20:25:35 anyhow, gtg Jun 07 20:25:36 night all. Jun 07 20:25:49 Meanwhile I'm really off Jun 07 20:25:54 be back in ten minutes Jun 07 20:25:55 dos1, especially since it rocks (don't panic) Jun 07 20:25:57 cya. Jun 07 20:25:58 TAsn: night, thanks for the explanation Jun 07 20:26:04 well, it was only patch sended to maillist, and it was supposed to put either simple and dontpanic to image Jun 07 20:26:16 onen|openBmap, that wasn't a real explanation, just my pov :) Jun 07 20:26:41 but it was spaetz who commited that :P Jun 07 20:27:15 SHR people, do you plan to put a specific gtkrc file on the system, to specify the size of buttons, etc... for all gtk apps? (so that it is usable with th efingers) Jun 07 20:27:41 onen|openBmap: it already is Jun 07 20:27:58 dos1|neo: do you know if it is in testing too? Jun 07 20:28:09 in shr-unstable we have complete gtk+ theme from TAsn Jun 07 20:28:16 onen|openBmap: no Jun 07 20:28:37 dos1|neo: my messagedialog window has yes/no buttons with differetn icons under shr testing, but still they are tiny Jun 07 20:29:11 dos1|neo: TAsn: that's great! I have been missing this for a long time! Jun 07 20:30:37 dos1|neo: is there still much sense behind testing/unstable? I mean, testing gets update often? As for now, it has ugly bugs. Jun 07 20:33:13 hi Jun 07 20:33:18 hai Jun 07 20:34:01 i've a problem with bluez4 and simple-agent Jun 07 20:34:21 DocScrutinizer: ping Jun 07 20:35:38 fredrin: hi. may I ask you some comments on new UI for my app? Jun 07 20:35:56 havent tried it yet Jun 07 20:36:05 but i can Jun 07 20:36:31 fredrin: you did use it already? isn't it? The new gui is on screenshots on our wiki for now only Jun 07 20:36:36 onen|openBmap: If you ask me (which you didn't :) I think OM2009 could be ~SHR stable/testing and SHR could be testing/unstable.. -> OM2009 might eventually die (no OM support any more though some OM-people still work on it) so maybe putting together one stable distro would make sense.. -> debian is stable, ubuntu is testing/unstable trying all the cool new stuff.. Jun 07 20:36:56 onen|openBmap: how new is the new UI? Jun 07 20:36:58 onen|openBmap: btw how ofter are the stats on hte OBM site regenerated? Can't wait to see me there :) Jun 07 20:37:45 fredrin: rhkfin: http://myposition.wiki.sourceforge.net/GUI_thoughts Jun 07 20:37:51 Ainulindale: well, for me it was clear when introducing shr-splash: -single as default. then i saw your commit and then i saw -simple in fresh image. i also saw it was choosing different theme in opkg install, and different by bitbake, so i thought it was some inconsistence in configs. as from start it was -simple as default in configs, i just proposed change by patch (which i would send to maillist also if i would have access to oe). And that's Jun 07 20:38:33 Weiss: gdb does not crash it, gdb just slows down Xorg a bit. can you reproduce the crash? Jun 07 20:38:43 rhkfin: om2009 survival? I agree, SHR has much more chances because much bigger community Jun 07 20:39:03 rhkfin: and Ainulindale is the best ever leader Jun 07 20:39:17 * onen|openBmap checks if Ainulindale reacts Jun 07 20:39:36 hehe Jun 07 20:39:48 dos1|neo: whoever commited it, I don't care, I'm not reproaching anything but the procedure Jun 07 20:39:50 onen|openBmap: I like OM2009 because of the stability/simplicity. 'just make it work' instead of 'include all new stuff' (ok, I don't know much about SHR, I admit :) Jun 07 20:40:01 dos1|neo: I have my personal preferrence which has no take on that Jun 07 20:40:12 onen|openBmap: yep, saw the wiki page about GUI. I'll try to write some comments.. Jun 07 20:40:14 fredrin: rhkfin: people were asking for more info on the screen, so I plan to move buttons to a specific screen. Now I try to organise data so that it is more readable (using table) Jun 07 20:40:17 dos1|neo: It's just my duty to make sure we keep a sane & procedurial way to do things ;-) Jun 07 20:40:31 onen|openBmap: I got some ideas.. Jun 07 20:40:44 Ainulindale: ACK :) Jun 07 20:40:45 dos1|neo: You don't have to justify yourself for that, it's partly spaetzAway's fault for not checking that and applying it too fast Jun 07 20:40:58 As I think we should have talked about that and delayed it one day or two Jun 07 20:41:07 lindi-: haven't tried yet. are you sure the breakpoint isn't having an effect? there's some pretty ugly kernel->userspace loops which go on during a VT switch, probably (i think?) ending up back in the Xorg DDX. but even that should result in "only" a kernel deadlock, not an nWait-style hard lock Jun 07 20:41:07 But I'll mail about that tomorrow Jun 07 20:41:09 rhkfin: you upload, every 20 minutes the site check if new upload. What it detects at that moment (so possibly in the middle of your upload) is automatically processed right away. Jun 07 20:41:13 Why not just print the data on one big lable or text field or something... and i would like to have the Satelites info like in TangoGPS,,,, Satelites 12/0 or Satelites 9/7 Jun 07 20:41:19 onen|openBmap: You're an ass! Jun 07 20:41:28 Ainulindale: ok Jun 07 20:41:39 rhkfin: so basically, see the tweet that you posted data (the loop detected it), and check for last update on front page of the website Jun 07 20:42:17 dos1|neo: But don't worry, I see your point anyway, I just have to disagree on the basis of, be it a bad commit for the change or not, the changed happened before (the dontpanic one) Jun 07 20:42:28 So we have to do the follow up :-) Jun 07 20:42:41 Weiss: i think i added sleep(10); there and caused the same crash Jun 07 20:43:03 Weiss: so gdb is only a way to make it easier to reproduce Jun 07 20:43:11 Anyways I'm wasted Jun 07 20:43:18 SO I think I'll go watch some video for a bit Jun 07 20:43:25 Ainulindale: hehe. it's irritating sometimes, but i think it's good for project ;) Jun 07 20:43:37 dos1|neo: well sadly I think it's always irritating Jun 07 20:43:39 fredrin: satellites are plan. using expanders would allow you to see it when having no 3d fix, and hide it when you have Jun 07 20:43:59 And doing that kind of job (that is somewhat enforcing procedures) gives me the bad cop role Jun 07 20:44:03 But still, someone has to do that Jun 07 20:44:15 And I don't mind if people thinks I'm an ass Jun 07 20:44:41 Ainulindale: pfff, when I say you nice thing you insult me, when I tell you bad things, you insult me. I am pretty sure that even if I would tell you nothing, you would still insult me :P Jun 07 20:44:50 onen|openBmap: heh :-) Jun 07 20:45:18 fredrin: could you be more specific about writing data on one big label? Jun 07 20:45:18 Ainulindale: my point is still: -dontpanic is just for some kind of people - not everyone will get the point, as not everybody read guide to galaxy Jun 07 20:45:21 Ainulindale: :) Jun 07 20:45:47 Ainulindale: but about procedure i agree with you Jun 07 20:48:09 onen|openBmap: I've submitter 2 times over 30 logs but can't see myself in the twitter feed (and yes I've deleted the files..) Jun 07 20:48:31 fredrin: rhkfin: I have been thinking 2 things: 1. have multiple views for gps, multiple views for gsm, all in expanders. thus people could select what they prefer Jun 07 20:48:32 lindi-: hang on, i'll try now.. Jun 07 20:49:36 * Weiss watches demos of Palm Pre, and notes that it fairly obviously has a compositing window manager, and is inspired Jun 07 20:49:50 fredrin: rhkfin: 2. let this one as a full data view, and design a complete different one, like a dashboard, where very interesting things are, in big letters (mcc/mnc, serving lac/cid/strength, gps speed only) Jun 07 20:49:52 onen|openBmap: nice Jun 07 20:50:28 number of collected cell would be nice to know Jun 07 20:50:54 rhkfin: yep, front server is up and running. but tweeter is down (my upload has not been tweeted neither). Jun 07 20:50:59 i don't care so much about mcc/mnc lac/sid/strength, i just trust that your program gets it right Jun 07 20:51:08 if want to use GPS things i start tangogps Jun 07 20:51:22 onen|openBmap: got twitter? Jun 07 20:51:26 rhkfin: back server has a harddisk failure. Nick works on this (thus the last tweet about server being on maintenance...) Jun 07 20:52:19 fredrin: # of collected cell is planned. # of discovered new cell will have to wait (need to have the db on the phone, and to get it updateds and so on) Jun 07 20:53:23 rhkfin: fredrin: to be clear, when I say: feature is planned == next version, I am working on it, is on todo list: I will see later if I do it Jun 07 20:53:39 k Jun 07 20:54:08 fredrin: tweeter... tweeter... (with some high pitched voice ;-) ) Jun 07 20:54:28 onen|openBmap: ok, great so I just need to wait for my name to appear there :) Jun 07 20:54:29 url, so i can stalk you Jun 07 20:54:38 http://twitter.com/openBmap Jun 07 20:55:06 fredrin: rhkfin: my dilemna is to stick to my liking: direct, simple interface, easy to use. || satisfy people wishes for more info, put it on screen but without cluterring it Jun 07 20:55:46 rhkfin: again, when you see your name here, your logs have *started* being processed Jun 07 20:57:27 onen|openBmap: got some GUI comments but don't got the time now. I'll try it tomorrow.. but short: you need a tab/something that explains shortly the abbreviations. Then visualize more: # of found cells (future: plot on map..). Move km/h next to the speed. Tell more about the satellites/GPS fix. Jun 07 20:57:51 fredrin: rhkfin: when I want more info about gps, i use zhone one, etc... so I very much agree with: obm should display what it uses, and possibly some more info for being more practical Jun 07 20:58:53 onen|openBmap: in the main view I'd like to see the status of GPS (=No of found & used satellites and if it's enough for OBM to work & my speed. Coordinates - not interesting..) On GSM side # of found cells is cool - I have no idea about the rest of the numbers... Jun 07 20:58:58 rhkfin: abbreviations in the app. +1. but low on priority, because I will try to explain it more on manual/wiki page Jun 07 20:59:13 onen|openBmap: wiki is a good start, nice! Jun 07 20:59:30 rhkfin: # of cell next release. Jun 07 20:59:50 onen|openBmap: great! Jun 07 20:59:55 rhkfin: plot on map, very interested (I saw some screenshots from omgps, seems pretty nice!) Jun 07 21:00:14 rhkfin: km/h in the new interface, in a table is not satisfying? Jun 07 21:00:36 rhkfin: satellites in next version. gps fix, probably too. Jun 07 21:00:37 onen|openBmap: the table thing is a mess. Lines are easier to read Jun 07 21:01:46 rhkfin: spent almost a day to get it right :'-( Jun 07 21:01:54 onen|openBmap: :/ Jun 07 21:02:48 onen|openBmap: it'd be great to see OBM integrated in fso: always when gps and gsm is on, there's a log written without a need to start a separate app for this. THe app could be used to monitor & upload -> a service.. Jun 07 21:02:51 does it run without X? Jun 07 21:02:55 * lindi- hides Jun 07 21:02:59 rhkfin: I find table easier to read, but looks a little bit more cluttered Jun 07 21:03:27 rhkfin: I have already thought about this. all things come with time Jun 07 21:03:38 onen|openBmap: depends on the data, yes, sometimes tables are easier to read.. Jun 07 21:03:48 rhkfin: but for me, no go for automatic logging. I like to keep control of when logging, for privacy Jun 07 21:04:06 onen|openBmap: ok Jun 07 21:04:22 rhkfin: so on the screenshot you think table is worse than current interface? Jun 07 21:04:26 onen|openBmap: yes Jun 07 21:04:45 rhkfin: someone liked it, you don't, so I have to find someone else :P Jun 07 21:04:47 ah MCC = mobile country code.. interesting :) Jun 07 21:04:48 lindi-: btw, I enjoy reading your adventures in wifi debugging on -kernel list. Jun 07 21:05:06 lac=local area code and mnc=mobile network code? Jun 07 21:05:11 onen|openBmap: i don't see the links "Register" "Screenshots" ... etc. on http://realtimeblog.free.fr/ when javascript is not allowed -- is this something that could be fixed easily? Jun 07 21:05:31 rhkfin: this makes me think my last idea could be quite good, more expanders, so you can have a view or another, details or not for every category Jun 07 21:05:47 onen|openBmap: possibly yes Jun 07 21:06:12 lindi-: I guess the menu uses it. I will ask Nick what is behind the menu. Please poke me about this again. Jun 07 21:06:14 khiraly1: any ideas about what to try next? Jun 07 21:06:36 onen|openBmap: ok, that's on my todolist now Jun 07 21:07:00 rhkfin: on the other hand, if I design a kind of dash board, with big simple data. Then the current intereface would move to a full data interface Jun 07 21:10:24 onen|openBmap: MCC is 99% not interesting? I don't know what are MNC and LAC but I'd guess those too - can I expect them to change on an average journey to a new place in my country? Jun 07 21:10:35 rhkfin: it is pretty difficult to do gui stuff. 1. you cannot satisfy everyone. 2. you break everything, and sometimes people don't like it and want the old one back ;-) Jun 07 21:10:41 onen|openBmap: I know :) Jun 07 21:11:04 lindi-: Not really. Im just surprised, that there are some enthusiastic people working on the low level stuff. And there are not many of them. So it was just a kind of thank you note. Jun 07 21:11:44 rhkfin: MCC is very much interesting. I was doing a road trip, and was happy to see the mcc change. I would prefer to write the country name directly, instead of the mcc, would be more sympathic Jun 07 21:11:54 As far as #2277 is concerned, I didnt dive into. I didnt use wifi on my freerunner (I pinged once google.com;) Jun 07 21:12:01 Concentrate on the interesting = changing information = cells & gps fix quality. (does GSM cell type ever change, can FR do anything else than GSM?) Jun 07 21:12:07 rhkfin: Mobile Network Code == the network operator code Jun 07 21:12:35 onen|openBmap: I guess MCC only changes when you cross to another country? = very rare. So's MNC - it changes when you change your operator? Jun 07 21:12:44 rhkfin: LAC is a bunch of cells belonging to one lac. (get tired, explanations become blurry, sorry) Jun 07 21:12:45 khiraly1: well thank you :) Jun 07 21:13:22 khiraly1: wifi is at least something much more manageable than the X stuff Jun 07 21:13:25 rhkfin: but I agree pretty much with you. some people want details (sth more like the current view). some others want few very interesting data (idea of a dashboard) Jun 07 21:13:36 so LAC might change on a 200km trip, MCC and MNC won't? It's nice to show as much information as possible, but maybe not in the main view Jun 07 21:14:03 onen|openBmap: i think the logger application should be use very little resources so that people can keep it running 24/7 Jun 07 21:14:10 s/be // Jun 07 21:14:26 lindi-: true.. Jun 07 21:15:08 rhkfin: right, so idea of two views. details / basic Jun 07 21:15:17 onen|openBmap: a 200-line python app that just uses dbus and gtk uses around 12 megabytes of RAM here Jun 07 21:15:23 lindi-: is there somewhere a list, what kernel bugs left? There are some wifi stuff, there is an ongoing(?) glamo rewrite, there is the gprs crash when high traffic. But Im not aware any other showstopper bug. Jun 07 21:15:25 rhkfin: but you see, it is already a mess to get an agreement with only two people :D Jun 07 21:16:33 rhkfin: lindi-: I try to always think about not wasting cpu. But when people want, let's say number of satellites in sight (what is not interesting me much, because I use another app to do so), I think it wastes cpu :P Jun 07 21:17:15 rhkfin: lindi-: and as someone pointed to me, the first very big cpu saving I would do, would be to move to vala/c instead of hungry python Jun 07 21:17:25 onen|openBmap: just have a really simple logger application and then a separate UI Jun 07 21:17:27 onen|openBmap: to be honest i dont care so much about the info, i just want to be sure that the app i running and connected, so i can just put it in my pocket and let it run. as lindi- said, less resources is a good thing too Jun 07 21:17:48 onen|openBmap: I'd think that when people start using it, a nice shiny GUI's nice to show what's happening but as people start learning & trusting, they just want it to silently do the job & not show a GUI.. Jun 07 21:17:51 khiraly1: good questions. Jun 07 21:18:26 true Jun 07 21:18:35 khiraly1: on my list the important kernel bugs are http://docs.openmoko.org/trac/ticket//2277 and http://docs.openmoko.org/trac/ticket//2294 Jun 07 21:18:44 -> I'd be happy to run it on CLI (through an icon) when I've learned how it works and what it saves etc.. Jun 07 21:18:55 khiraly1: we can't do anything about the GPRS crash Jun 07 21:18:57 rhkfin: it depends, you already would like to see the cell coverage on a map, to see where we have data or not and so on. I get more and more people asking for nice idea, but which in the end would make the logger become big, and cpu save just a dream Jun 07 21:19:12 lindi-: why? Jun 07 21:19:17 fredrin: we don't have source code Jun 07 21:19:25 :( Jun 07 21:19:55 lindi-: who to poke to fix it then? Jun 07 21:20:03 lindi-: how this should prevent a good hacker to reach success? ;-) Jun 07 21:20:16 s/to reach/from reaching// Jun 07 21:20:19 s/to reach/from reaching/ Jun 07 21:20:20 onen|openBmap meant: s/from reaching/from reaching// Jun 07 21:20:27 onen|openBmap: if I have GPS map app on to show me where I am, then yes, I'd like to see it on the map.. Jun 07 21:20:30 * onen|openBmap thinks: nevermind Jun 07 21:20:51 fredrin: i have no idea. afaik TI has not been very interested in this Jun 07 21:21:22 khiraly1: on the userland side we have the dbus bug Jun 07 21:21:23 onen|openBmap: and no, I didn't want to see the whole coverage on the map (well, sometimes it'd be handy too), just draw the line where I'm moving with a different colour when the cell changes. Jun 07 21:21:27 rhkfin: yep. I have to be carefull, what is an obm thing, and what is not. that is the reason why I would love to see my cells in omgps, but through a specific dbus service, as a source provide rfor it Jun 07 21:21:41 khiraly1: https://bugs.freedesktop.org/show_bug.cgi?id=19796 Jun 07 21:22:00 fredrin: not even OM has the source code. And people who worked on calypso are likely retired on a pension;) Jun 07 21:22:09 rhkfin: ok, my bad. But well I would like to see the whole coverage, because I could take roads where I don't have data yet :-) Jun 07 21:22:17 khiraly1: then we have the hardware bug #1024 that apparently just recently got fixed (yay!) Jun 07 21:22:22 khiraly1: :-D Jun 07 21:22:34 khiraly1: so thats how old the calypso modem is, lol Jun 07 21:22:40 lindi-: Im just testing the patch from this bug. mrmoku built a new .ipk with the patch Jun 07 21:22:49 reverse engineering? Jun 07 21:23:13 fredrin: this is the reason why OM cant source any info. Because there is noone who even remembers what calypso was Jun 07 21:23:14 ;) Jun 07 21:23:15 did not someone have the access to the code at OM, they made a firmware upgrade Jun 07 21:23:22 onen|openBmap: yes, sometimes that'd be handy (but I don't have a car -> I usually go straight from point A to B by bus/bike/someone else's car -> so far I haven't went out there to hunt cells but recorded as I move for other reasons) Jun 07 21:23:30 fredrin: OM only has a tiny part of the source Jun 07 21:23:48 rhkfin: fredrin: I tried to design my app so that I could turn it easily in a daemon, or dbus service. Then the gui is only a view+controller. It should not be difficult to separate them. But it is not high priority now Jun 07 21:23:50 onen|openBmap: I think you got the aspects of the needs Jun 07 21:24:05 onen|openBmap: nice forward thinking Jun 07 21:24:21 onen|openBmap: yes, that sounds great! Jun 07 21:24:47 This would allow it to more easily be integrated to other apps. Jun 07 21:25:29 onen|openBmap: 'Note: The GPS is started as soon as the application is launched.' Jun 07 21:25:31 rhkfin: yep. and anybody could design a gui in gtk/elementary/nameithere, while the engine would become stable and tested Jun 07 21:25:46 onen|openBmap: we really should have a mode "wait for unknown cell, then start GPS" Jun 07 21:25:49 onen|openBmap: a good logger should be the first pri and easy access of the data for other programs/views Jun 07 21:26:02 onen|openBmap: since 90% of time people will be moving in the same cells Jun 07 21:26:10 lindi-: true Jun 07 21:26:36 lindi-: the idea for me is start/stop, I control when I want to log (protect privacy) but I don't want to wait for gps fix when I want to log. so I let it run Jun 07 21:26:54 onen|openBmap: i don't want to need to consciously start the logging when I move to a new area Jun 07 21:26:56 lindi-: and we need data, even for known cells Jun 07 21:27:06 onen|openBmap: I might be driving a car for example, can't play with the phone in my pocket Jun 07 21:27:19 onen|openBmap: it should have different modes, like full logging mode, no suspend full gps +++, idle mode, just logg when awake, if new cell start gps +++ Jun 07 21:27:47 onen|openBmap: ok data for known cells makes sense yes, but you could let the GPS go down when you have sufficient data for some cell, right? Jun 07 21:27:49 lindi-: but you should try. Do you know how much fun using tangogps while driving? Jun 07 21:28:00 :P Jun 07 21:28:01 so many tiny buttons everywhere;) Jun 07 21:28:05 * rhkfin believes onen|openBmap will make good decisions about design :) Jun 07 21:28:13 * fredrin too Jun 07 21:28:23 lindi-: I will think about it. maybe do it configurable. But I, for privacy reason, don't want an automatic mode. But I write it down on my todo list Jun 07 21:28:56 'nite Jun 07 21:29:00 onen|openBmap: perhaps if you had a library for submitting the data to the project it would be easier for people to write clients? Jun 07 21:29:11 lindi-: does the GPS have some powersave mode that saves power and is fast to start & get the fix (or that'd even hold the fix?) Jun 07 21:29:32 rhkfin: yes Jun 07 21:30:08 rhkfin: but i think it'd still be better to stop it completely. loosing a few minutes of data can't be that bad Jun 07 21:30:20 lindi-: yes and no, as we don't know when we will have readche the 'borders' of a cell coverage. Jun 07 21:30:24 rhkfin: if the alternative is that people need to manually start logging (and thus often don't remember to start it) Jun 07 21:30:28 lindi-> onen|openBmap: we really should have a mode "wait for unknown cell, then start GPS" Jun 07 21:30:40 so this should be really doable with a fast fix ^ Jun 07 21:30:49 fredrin: I have noted all your modes, I like it very much. but could turn out to be pretty complex to implement... Jun 07 21:31:15 would be cool if calypso could wake the system up when an unknown cell is reached :) Jun 07 21:31:34 lindi-: when a new cell is reached..? Jun 07 21:31:43 ie. when the cell changes Jun 07 21:31:51 khiraly1: you are right, when I drive and turn on and off my two FRs for protecting my privacy, I probably protect much less my security :-S Jun 07 21:32:11 rhkfin: fredrin: thanks for you trust ;-) Jun 07 21:33:21 security < privacy :) Jun 07 21:33:28 lindi-: I was talking earlier about the design of my app, which was thought from the ground up to be turned into an engine with views. So the dbus service, command line, etc, would all be views of a same core engine, call it a library :-) Jun 07 21:33:35 onen|openBmap: sure man Jun 07 21:33:52 onen|openBmap: for example when i go to extremadura at debconf for a week and wander around i don't mind about my privacy Jun 07 21:33:56 lindi-: [2009-06-07 23:18:55] khiraly1: we can't do anything about the GPRS crash ||| is abyss been tested wrt this? Jun 07 21:34:07 DocScrutinizer: shouldn't we test cat first? Jun 07 21:34:17 what's cat? Jun 07 21:34:23 onen|openBmap: however, the battery won't last that week if gps is running all time Jun 07 21:34:23 lindi-: that is a reason I think about rewriting it in c/vala. for speed, portability, and being used by others clients Jun 07 21:34:28 DocScrutinizer: i mean cat /dev/ttySAC1 ? Jun 07 21:35:04 onen|openBmap: also, you could edit the logs later to maintain privacy Jun 07 21:35:04 why not, anyway I wonder how to create heavy gprs traffic that way Jun 07 21:35:27 DocScrutinizer: the ppp level pings will probably kill the connection indeed Jun 07 21:35:36 DocScrutinizer: but how about just using ppp without any muxer? Jun 07 21:36:08 rhkfin: lindi-: pb with stopping gps, if you are in canyon areas, pretty difficult to get a fix, when you finally have one, you don't want to lose it Jun 07 21:36:15 the Idea wasn't exactly the muxer might be a bad thing, it's more like abyss has fixed sw-flowcontrol Jun 07 21:36:27 onen|openBmap: no canyons in finland :) Jun 07 21:36:34 onen|openBmap: yes, that's why I was asking about the 'half-stop' that'd save power but not loose the fix.. Jun 07 21:36:35 rhkfin: lindi-: I used the app for hours, even gps on, it last 5 hours, IIRC Jun 07 21:36:46 lindi-: dunno if this applies to ppp or even cat Jun 07 21:37:09 onen|openBmap: I too had gps & OBM on for maybe, yes, around 5 hours. Jun 07 21:37:15 lindi-: calypso wake up: absolutely! Jun 07 21:37:33 onen|openBmap: how about this: 1) phone wakes up every our by RTC alarm to check if the current cell is known 2) if it is not known it starts GPS and logs data as long as it keeps seeing new cells 3) if no new cells are found it goes to sleep Jun 07 21:37:48 s/our/hour/ Jun 07 21:38:21 onen|openBmap: i'd fix the privacy issue by having the user edit the logs on his PC after his journey Jun 07 21:38:50 onen|openBmap: that way the user would see exactly what he is going to send Jun 07 21:38:55 lindi-: think we could set up modem to send unsol (=resume system) on new cell Jun 07 21:39:14 not 100% sure about it Jun 07 21:39:20 DocScrutinizer: yep but then it happens for every new cell Jun 07 21:39:43 aah, you are interested in *NEW* cells ;-) Jun 07 21:39:47 yeah Jun 07 21:39:48 rhkfin: lindi-: automatic wake up: when in a building, it will turn gps on, and draw your battery, with no luck to get a fix Jun 07 21:40:01 onen|openBmap: it can detect that GPS signal is low and give up Jun 07 21:40:31 lindi-: well, a short resume-check-suspend cycle every once in a while wouldn't hurt that much Jun 07 21:40:38 onen|openBmap: and start logging wlan base stations :) Jun 07 21:40:56 lindi-: wlan, ha! :) Jun 07 21:40:58 DocScrutinizer: probably not if you could keep the display off at least Jun 07 21:40:59 lindi-: an idea was to only log semester+year, instead of precise time => big privacy protection Jun 07 21:41:11 lindi-: and a lesser new cell is a better trigger than RTC I guess Jun 07 21:41:25 lindi-: I know some users will be able to do it by hand, but I want that user don't need to think about it Jun 07 21:41:48 DocScrutinizer: if you are moving in a car through an area of old cells then the phone will constantly wake up :( Jun 07 21:41:49 I like DocScrutinizer's idea of wake up on every new cell for a quick check. If it's new, start logging.. Jun 07 21:41:50 DocScrutinizer: neat :-) Jun 07 21:41:54 sw can decide easily if that'S a *NEW* cell, and then go back to sleep immediately Jun 07 21:42:28 lindi-: gps signal low in building: possibly, good idea Jun 07 21:42:33 DocScrutinizer: maybe we could have some intelligent scheme here. "if cell changes are rare, tell calypso to wake us up on cell change. otherwise wake periodically with RTC every hour" Jun 07 21:42:36 see, I got some 18h standby with IRC Jun 07 21:42:59 lindi-: even smarter :-) Jun 07 21:43:23 lindi-: tell Stefan he should ask me directly, and not through you ;-) Jun 07 21:43:48 5 years ago I dreamed that I had a phone that could detect when I arrive at work and shutdown my mobile. we still aren't there :) Jun 07 21:43:51 ~seen mickeyl Jun 07 21:43:52 mickeyl is currently on #openmoko-cdevel. Has said a total of 17 messages. Is idling for 9h 13m 3s, last said: 'Sup3rkiddo: yep, alarm sounds good'. Jun 07 21:44:19 onen|openBmap: noted, irc nick "stefan"? Jun 07 21:44:39 rhkfin: we could design a log uppon new cell. but we need many points for a unique cell for our algorithm. So this should be a degraded mode only Jun 07 21:44:42 lindi-: duh, why not there? Jun 07 21:45:19 DocScrutinizer: since calypso can't wake the system when I move to that specific cell Jun 07 21:45:48 DocScrutinizer: and I have to stop the car to turn off my mobile manually :( Jun 07 21:45:49 onen|openBmap: about privacy: you could log into two files. One without privacy, and the other with only the privacy data. So when uploading, it only needs the non-privacy file. Jun 07 21:46:06 In that scenario, everything is straightforward. Jun 07 21:46:08 hmmm, see my prev comment about cost of short wakes (which there's been a fsckng lot while IRC) Jun 07 21:46:09 lindi-: DocScrutinizer rhkfin: I have been thinking too, how to log *without* gps, with "I knew the position of last cell, so this new one should be near" Jun 07 21:46:31 DocScrutinizer: (I want to keep the phone on while I am travelling to work just in case somebody wants to reach me) Jun 07 21:46:49 onen|openBmap: Should be doable.. Jun 07 21:46:54 lindi-: yes you can. my dbus service (proof of concept but work) would allow you to shut down your phone at work Jun 07 21:47:03 no need to hand edit the file after logging, etc. And if you add a settings option "hide my privacy", it simply means it does not log the privacy file Jun 07 21:47:08 onen|openBmap: but how does the phone wake up from suspend? Jun 07 21:47:22 lindi-: stefan_schmidt is very interested in logging wifi Jun 07 21:47:24 lindi-: curiously, on my test just now, i can't reproduce your gdb hang.. Jun 07 21:47:40 Weiss: are you running too old kernel? Jun 07 21:47:48 Weiss: larsc was able to reproduce the hang when he upgraded Jun 07 21:48:18 well guys - my aproach is a completely different one yet (always been). We need one record per unique *position*, not per unique *cell* Jun 07 21:48:42 lindi-: i'm testing with the DRI-enabled stuff. the results are interesting because of the reduced Glamo-poking that goes on with this setup.. Jun 07 21:49:04 khiraly1: yep, that's an idea. But not too high on todo list. privacy is already pretty good. we will propose raw data without being linked to user id for download Jun 07 21:49:33 Weiss: if you tell me which exact kernel and xf86-video-glamo version you are using I'd like to test it Jun 07 21:49:35 unique position might be as little as 5m away from last recorded one, as neighbour cells, signal, wifi, a lot of things change for a different *location* while still you are same BTS Jun 07 21:49:48 DocScrutinizer: point Jun 07 21:50:28 lindi-: drm-tracking kernel was last synced with andy-tracking on 25-Apr-2009. i'm using the exact setup as detailed on http://www.bitwiz.org.uk/freerunner-dri Jun 07 21:50:30 hoory, at least one person seems to get my point at last \o/ Jun 07 21:51:07 lindi-: but, i thought you and larsc ruled out the command-queue (i.e. EXA) stuff earlier, by commenting out the glamo cmdq and 2D engine register poking..? Jun 07 21:51:33 Weiss: thanks, i'll put that to my todo-list Jun 07 21:51:55 Weiss: i'm not sure anymore :( I thought it proved that a userland program can crash the system which is bad Jun 07 21:52:05 DocScrutinizer: then you will love the obm logs http://myposition.wiki.sourceforge.net/log_format Jun 07 21:52:38 DocScrutinizer: I don'tunderstand the differenc ewith having a map of cell coverage, a map of wifi, etc... and cross the data to get your position? Jun 07 21:52:44 as detailed on Jun 07 21:52:46 lindi-: Xorg "thinks it's a kernel module". it's an innate problem with any pre-KMS setup.. Jun 07 21:53:25 DocScrutinizer: but for your approach you need a lot of points. so stop helping the guys designing a "log only uppon new cell approach" ;-) Jun 07 21:53:31 onen|openBmap: yup this log format looks quite decent first glance Jun 07 21:53:47 DocScrutinizer: by the way, Stefan asked for arfcn. do you know if this is safe to read it at any time? Jun 07 21:53:59 Weiss: yep Jun 07 21:54:00 onen|openBmap: i already did stop that ;-D Jun 07 21:54:10 Weiss: is that drm-tracking kernel now in a usable state? Jun 07 21:54:14 * onen|openBmap is happy DocScrutinizer likes my format :-) Jun 07 21:54:33 first had to see what it is at all (arfcn) Jun 07 21:54:41 onen|openBmap: it could be "log only on new location" approach too Jun 07 21:55:03 lindi-: good point Jun 07 21:55:15 lindi-: i've been running it as my day-to-day phone for some weeks :).. it works, just isn't very functional (e.g. no EXA) - and you must use all the matching libDRM, DRI-aware DDX, etc etc. the build process is a bit of a pain, but detailed in that link Jun 07 21:55:32 Weiss: i only want stable system :) Jun 07 21:55:38 lindi-: when you are not a known road. but as stated earlier, our algorithm needs many measurements, and DocScrutinizer approach too Jun 07 21:55:46 lindi-: i'm planning to dig into KMS a bit tomorrow. i'm expecting to stall pretty quickly until my debug board arrives, though Jun 07 21:56:03 KMS is really deeper than i wanted to dig at the start, but anyway.. Jun 07 21:56:03 Weiss: ah you don't have one yet? Jun 07 21:56:12 lindi-: so I am not sure to be willing to propose a way of logging which will hinder our algorithm... Jun 07 21:56:24 Weiss: will this be a starting point for other fixed-function gpus? Jun 07 21:56:46 DocScrutinizer: look for arfcn there: http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem Jun 07 21:57:08 lindi-: nope. until now, the changes are less major than they sound.. but moving to KMS involves gutting the entire graphics system, which is going to be practically impossible without a serial console Jun 07 21:57:51 Weiss: ok but you will get one soon? Jun 07 21:58:04 Weiss: I borrowed mine from a friend Jun 07 21:58:13 lindi-: fredrin: rhkfin: thanks all for your comments. Now I know that no matter how hard I will try, I will never satisfy all my users :-P Jun 07 21:58:22 onen|openBmap: aah, actual rf channel number. Yeah should be safe Jun 07 21:58:27 Weiss: msm has a ati imageon derived core we would like to support fast page flipping on at least Jun 07 21:58:50 DocScrutinizer: I thought so too, the frequency of an antenna never change, right? Jun 07 21:58:54 tmzt: yes. AFAIK this is the first implementation of DRI2/KMS/etc on a non-PCI device or on an ARM platform, and only about the fourth implementation on anything.. (or, ahem, will be when anything more than early stage experimental demos exist) Jun 07 21:59:07 onen|openBmap: not frequently ;-D Jun 07 21:59:10 onen|openBmap: you're doing fine :) Jun 07 21:59:13 DocScrutinizer: :-D Jun 07 21:59:54 lindi-: ordered from Truebox, hope to have it by the end of the week.. Jun 07 21:59:56 Weiss: that all sounds very complex. do we really need all that complexity just to have the simplest possible stable graphics? Jun 07 22:00:27 Weiss: (DRI/KMS/DDX/EXA..) Jun 07 22:00:28 Weiss: great, we have a lot to do before beginning work on this Jun 07 22:00:35 -> zzz Jun 07 22:01:20 Weiss: wonder why initrd with usbnet isn't enough though? Jun 07 22:01:53 onen|openBmap: btw older format isn't wellformed XML Jun 07 22:02:00 tmzt: can't set breakpoints in kernel Jun 07 22:02:09 ah Jun 07 22:02:33 tmzt: I try to follow htc-linux, but don't have time. I hope you will keep us up to date, on working/non working htc devices with linux Jun 07 22:02:34 does debugging work in kernel? Jun 07 22:02:39 tmzt: yes Jun 07 22:02:46 onen|openBmap: isn't closed Jun 07 22:02:46 Weiss: is u-boot the best place to look for a really simple way to talk to glamo? ;) Jun 07 22:03:00 onen|openBmap: will try :) Jun 07 22:03:13 lindi-: i thought that just had bits of glamo-fb copied into it? Jun 07 22:03:19 DocScrutinizer: why? Jun 07 22:03:31 Weiss: ah and that's not simple? Jun 07 22:03:39 DocScrutinizer: this is more the idea of the log format at the beginning. this is no real life log Jun 07 22:03:43 onen|openBmap: dunno why it's not closed ;-D Jun 07 22:04:09 makes parsing easier Jun 07 22:04:24 DocScrutinizer: correct, BT is not closed ;-) Jun 07 22:04:30 lindi-: well.. i guess it must be possible just to fix the current problems and make the fbdev route work stably. really difficult to say without properly understanding what the (timing? locking?) issues are which cause the current problems.. Jun 07 22:04:54 Weiss: but isn't xserver-xorg-video-fbdev stable? Jun 07 22:05:00 DocScrutinizer: oh sorry, I had missed you explaining that BT was not closed ;-) Jun 07 22:05:03 Weiss: and the problems are with xserver-xorg-video-glamo? Jun 07 22:05:22 lindi-: good question... Jun 07 22:05:29 tmzt: so is it working now? Jun 07 22:05:34 tmzt: and now? Jun 07 22:05:39 tmzt: now? Jun 07 22:06:13 but now away, need to sleep for a while Jun 07 22:06:20 * onen|openBmap is impatient Jun 07 22:06:27 lindi-: i'd be very interested to know if your gdb lockups happen with fbdev (should still be enter/leave VT routines to break on) Jun 07 22:07:08 * DocScrutinizer needs some time off now. Jun 07 22:07:19 ok guys good night Jun 07 22:07:53 rhkfin: lindi-: fredrin: thanks for the nice comments and comments. I will sleep well on it for now :-) Jun 07 22:08:02 onen|openBmap: np :) Jun 07 22:08:04 np bro Jun 07 22:08:58 s/comment and comments/comments and discussions/ Jun 07 22:40:44 tmzt: MSM was in HTC? Jun 07 22:43:16 as in* Jun 07 22:49:05 Weiss: touch pro, diamond, hd, etc Jun 07 22:49:57 Weiss: same gpu as the g1 which has a gles driver, but it's closed and in userspace Jun 07 22:50:27 kernel just exposes memory to userspace Jun 07 23:00:32 SHR: 03frazier.cameron 07shr-settings * r2065dfc1fbac 10/shr_settings_modules/shr_homedir.py: [HomeDir] Condensed/Consoledated the interface per dos' request. Should close #495 Jun 07 23:05:48 Ainulindale: Your requested /home/$USER archive system is now in git :) Jun 07 23:05:49 tracfeed: Ticket #495 (Create Archive/Restore System for /home/${USER}) updated Jun 07 23:14:31 Ainulindale: Can you delete user:TaxAudit from the wiki? It's spam'ed several pages Jun 07 23:14:48 who's frazier.c ? Jun 07 23:14:56 * Toaster` waves Jun 07 23:15:11 19 DIRECTORY_BLACKLIST = ['.e', ] Jun 07 23:15:14 comma? Jun 07 23:15:30 DATE_FORMAT = "%d%m%y-%H%M" Jun 07 23:15:46 in a python list a trailing comma has no effect Jun 07 23:15:55 date format: YYMMDD-HHMM, for sorting Jun 07 23:16:54 YYYY? Jun 07 23:18:06 good points Jun 07 23:18:29 SHR: 03seba.dos1 07shr-settings * r8b674cf85df4 10/shr_settings_modules/shr_bt.py: [bt] remove unused python modules Jun 07 23:19:17 342 archive_cmd = "cd /home/root; Jun 07 23:19:36 cd ${HOME}; ?? Jun 07 23:20:00 is there any reason shr-settings depends on sim card? Jun 07 23:20:11 heh, only place I used a static value for home Jun 07 23:20:35 os.env or equivalent might be better Jun 07 23:21:12 tmzt: I use os.environ['HOME'] earlier on in the code Jun 07 23:21:17 yeah, that Jun 07 23:21:59 is shr-settings running as the user? Jun 07 23:21:59 353 restore_cmd = "tar -xf \"" + self.activeFile[0] + "\" -C /home/root" Jun 07 23:22:33 damnit, ok two places Jun 07 23:23:31 tmzt: I would think that it is running as the user Jun 07 23:23:33 356 os.system(restore_cmd) Jun 07 23:23:49 -> try os.system(restore_cmd) Jun 07 23:24:24 huh? that's the same thing? Jun 07 23:24:34 oh, as in try: except: ? Jun 07 23:24:45 well, check for return code some way Jun 07 23:25:11 try only deals with exceptions though? Jun 07 23:25:53 345 os.system(archive_cmd) #same Jun 07 23:26:00 I'll have to adapt it to os.popen to get the return code I believe Jun 07 23:26:20 no idea, no py devel here ;-) Jun 07 23:31:17 SHR: 03seba.dos1 07shr-settings * red8391169d02 10/shr_settings_modules/shr_splash.py: [splash] add Preview function Jun 07 23:33:07 (01:19:42 AM) tmzt: is there any reason shr-settings depends on sim card? Jun 07 23:33:28 tmzt: how does it depends? Jun 07 23:35:59 dos1|neo: I don't have a sim card or capability to use one and it would fail after requesting gsm resource I think, it might have been the CFUN=1 code in ogsmd though Jun 07 23:45:09 tmzt: but what shr-settings has to do withhit? Jun 07 23:45:18 s/withhi6/with it/ Jun 07 23:46:24 well, GSM, Call and SIM modules would fail Jun 07 23:46:31 not sure, I'll need to try it again with my new patches Jun 07 23:46:34 but others shouldn't... Jun 07 23:46:39 (to ogsmd, phonekitd) Jun 07 23:46:53 ogsmd? Jun 07 23:47:03 i don't think it need patches Jun 07 23:47:12 yeah, I'm adding support for cdma and my cdma touch pro Jun 07 23:47:23 oh Jun 07 23:47:29 then ok ;D Jun 07 23:47:52 trying to get the whole shr stack working, including shr-settings Jun 07 23:48:00 but it's not the priority right now Jun 07 23:48:03 but i'm sure ophonekitd handles situation when there is no sim card Jun 07 23:48:56 so then it's ogsmd problem i suppose Jun 07 23:58:22 I fixed the one in ophonekitd but I'm not sure it was neccessary Jun 07 23:58:52 it turns out when something calls request gsm or antenna set or whatever, it calls CFUN=1 and then probes sim card Jun 07 23:58:57 in ogsmd Jun 08 00:08:45 I really don't like to hear about random patches, which even the devel doing them isn't shure about whether they are needed and how they are supposed to work. I bet any ratio this will almost ever introduce regressions, and nobody cares to do decent tests, until another random MrPatchmaster is trying to fix it with more guesswork Jun 08 00:10:51 SHR: 03frazier.cameron 07shr-settings * r859de969e3c6 10/shr_settings_modules/shr_homedir.py: Jun 08 00:10:51 SHR: [HomeDir] Several recommendations and bugs from irc actioned. Added file/dir Jun 08 00:10:51 SHR: and exit code checks for archive/restore commands, changed date format for Jun 08 00:10:51 SHR: better sorting, reversed sort of archive files (last is first), et al. Jun 08 00:11:15 That should address what you guys pointed out Jun 08 00:12:05 Toaster`: :-)) Jun 08 00:12:44 * DocScrutinizer passes toaster a beer Jun 08 00:12:50 hmm.. anybody experience with 'sim com 300/340' gsm modules and its favour of 'AT' ? Jun 08 00:14:47 roh: which favour? Jun 08 00:15:40 * Toaster` realizes an IRC beer, while appreciated is bit virtual, and he goes to make a martini Jun 08 00:15:48 eh flavour Jun 08 00:15:53 hayes-foo-flavour Jun 08 00:16:06 aaah Jun 08 00:16:20 sim com iss some chinese 2g/gprs module oem Jun 08 00:16:35 never heard of Jun 08 00:16:49 and they sell gsm-gps datalogger/tracker for 50-70E now.. including one of these and a sirf3 it seems Jun 08 00:17:06 wow Jun 08 00:17:27 BND will be happy ;-) Jun 08 00:17:28 Damn wiki spammers Jun 08 00:17:28 i would like to have a)working firmware in it (original is buggy and has one essential feature _not_ and b) ublox 5 if possible Jun 08 00:17:36 DocScrutinizer bike-thieves. Jun 08 00:17:55 hehe, a age old dream of me Jun 08 00:18:02 DocScrutinizer not mine, luckily... but the last one was one too many. the next one we recollect with some reinforcements Jun 08 00:18:45 really harsh reinforcements, please ;-) Jun 08 00:20:07 roh: remote emergency stop of the front wheels ? Jun 08 00:20:19 roh: do those modules have an AP Jun 08 00:20:20 ? Jun 08 00:20:42 dont think so.. think like 'calypso gsm blackbox' of it Jun 08 00:20:49 can do lcm and so... Jun 08 00:21:06 wpwrak: detonator under the seat. might use recycled airbag :-D Jun 08 00:22:28 DocScrutinizer: yeah, angle it slightly forward, in case there's a "thief gene" Jun 08 00:30:11 wpwrak: could you have a look at file:///home/jr/Documents/OpenMoko/batlog.txt.odf please. Esp the comments in "L" Jun 08 00:30:43 err, mompl Jun 08 00:30:51 DocScrutinizer: just a second while i break into yuor system ... ;-) Jun 08 00:31:31 http://people.openmoko.org/joerg/battery/batlog.txt.odf Jun 08 00:36:46 hmm, lots of data. anything you find especially troublesome ? Jun 08 00:37:18 well, the lines with comment in col "L" Jun 08 00:39:05 It shows very nicely the kernel-"bug" to switch state to reporting "charging" after 15min. It also shows why we must not stop system at CC = 0% Jun 08 00:40:43 most of column L is just state changes, not things that look like problems Jun 08 00:40:57 a plot would be really nice Jun 08 00:43:04 err... ? Jun 08 00:44:50 the plots of table2 are just prototypes. you can modify to meet you taste Jun 08 00:45:17 oh. there's a second page :) Jun 08 00:47:31 so .. do we know what causes the 5% jump ? Jun 08 00:48:06 the bq27k algo it seems Jun 08 00:48:49 it's consistent to jump the upper 3%, and the lower 5% Jun 08 00:49:55 but it doesn't matter anyway, as all genuine CC readings are strictly user info only. System must not care about any of those Jun 08 00:51:57 Why? Jun 08 00:52:30 because it's useless Jun 08 00:52:37 reference? Jun 08 00:52:48 ? Jun 08 00:53:06 documentation that describes why/how it is useless and should not be used? Jun 08 00:54:06 *me* is the documentation - as EE didn't care to give application notes for FR PMU MBC Jun 08 00:54:14 oh Jun 08 00:55:28 it's absolutely obvious the CC isn't reliable, and any system task related to bat management must rely on pcf50633 solely Jun 08 00:56:09 which isn't accurate either, for that matter. But oh well. Jun 08 00:56:38 reference to that? :-) Jun 08 00:56:51 Unless you have the calibration data we can use to compute the capacity from the current/voltage? Jun 08 00:57:02 to me it seems it's rather accurate Jun 08 00:57:40 system isn't interested in capacity Jun 08 00:57:45 reference: see the kernel list for URLs to speedevil's charts showing the non-linearity of the capacity on the GTA01. Jun 08 00:58:44 you'll find similar reference pointing to statments done by me, but... see last statement Jun 08 00:58:48 Of course the system is concerned about capacity - that's how you estimate various functions, from battery level indicator (non critical) to battery-too-low-must-shutdown thresholds of various sorts. Jun 08 00:59:11 Well, I'm not going to argue with DocScrutinizer, that's a waste of time. But neither do I accept your statements. Sorry. Jun 08 00:59:32 shutdown thresholds are in pcf50633 anyway Jun 08 00:59:33 CC may be wrong, but it's all we have right now. Jun 08 00:59:46 So someone will ha ve to come up with something that is demonstrably better. Jun 08 00:59:48 nope Jun 08 01:00:01 "demonstrably" is the operative term. Jun 08 01:00:02 I did Jun 08 01:00:11 It's easy to throw rocks, when you have no data. Jun 08 01:01:05 you have two thresholds for bat-low and sys_low in PMU. those can even resume the system (how would you manage to handle that with CC?!) Jun 08 01:03:54 and, as mentioned before: but it doesn't matter anyway, as all genuine CC readings are strictly user info only. System must not care about any of those Jun 08 01:04:25 emphasis on "system" Jun 08 01:04:53 DocScrutinizer: do you now check the flag that tells you if the capacity estimate is valid ? Jun 08 01:05:37 I don't. and honestly it gives us very few additional functionality Jun 08 01:06:25 you could change the color of bat-applet. nothing more Jun 08 01:06:52 "genuine CC readings are strictly user info only" <-- where is that documented? Jun 08 01:07:17 in the quoted line Jun 08 01:07:49 it's a conclusion from pondering reliability of those data Jun 08 01:08:07 Ah. So the company that manufactures those is creating random data, and by virtue of a brilliant and dishonest sales force is selling those batteries to other companies. I see. Jun 08 01:08:26 DocScrutinizer: well, it cuold tell you when the CC knows it's wrong. from what you told me, i would suspect the CC doesn't have valid data for most of the time. Jun 08 01:08:33 bah, nonsense speaking Jun 08 01:09:14 Yes, that's nonsense. Therefore there must be some valid use for CC info from a battery; and without more documentation I cannot accept that we should throw it out. Jun 08 01:09:18 what's the goddamn usecase for those CC data? Jun 08 01:09:48 mwester: perhaps you remember the analysis i posted a few days ? weeks ? ago, where i summarized what i found when joerg pointed me to that nonsensical data the first time Jun 08 01:09:49 it's obviously worth nothin than inform user to give him an idea of capacity Jun 08 01:10:37 wpwrak, nope. I've been way too busy with real life to keep close track of anything lately. In fact, I shouldnt' even be having this discussion. So I'll just bow out right now. Jun 08 01:10:47 mwester: the bottom line is that the cc "knows" when it doesn't have an accurate estimate. you can still read the data, but it's junk. there's a flag that tells you if the data is valid, but it seems that nobody uses it. Jun 08 01:11:05 yup, I remeber. I also remeber you made some conclusions from my words I hoped you would rethink when looking at batlog Jun 08 01:11:34 DocScrutinizer: oh, please just tell me where the contradiciton is :) Jun 08 01:12:08 DocScrutinizer: i'm keeping track of way too many things at the moment that i really remember every little detail we discussed :) Jun 08 01:12:33 you assumed sth about charge state and bat discharging or the like Jun 08 01:13:13 DocScrutinizer: that the CC only knows the real capacity after hitting both full and empty ? Jun 08 01:13:32 aah, exactly: if pmu enabled MBC charger, the bat can NOT discharge same time Jun 08 01:13:57 it's impossible Jun 08 01:14:19 DocScrutinizer: i don't think that's what i said. what i probably said that it wasn't discharging through the pmu Jun 08 01:14:43 nevermind Jun 08 01:14:54 DocScrutinizer: what the other power directly hanging off the batter do is beyond the control of the pmu Jun 08 01:15:00 s/power/power users/ Jun 08 01:15:01 wpwrak meant: DocScrutinizer: what the other power users directly hanging off the batter do is beyond the control of the pmu Jun 08 01:15:18 we even got the nonsense sys-shutdown at 5% removed from fso yaml rules now Jun 08 01:15:19 DocScrutinizer: that's also why you have that trouble when the modem is on Jun 08 01:15:55 DocScrutinizer: regarding the CC, i think you really want to retrieve that "is it valid ?" flag Jun 08 01:16:13 sure, still bat can't DIScharge while charger enabled Jun 08 01:16:40 (valid flag) to do exactly what? Jun 08 01:16:50 DocScrutinizer: if GSM or USB (host mode) is drawing more current than the charger delivers, why not ? Jun 08 01:17:16 hmm, that had to be sth like >800mA then Jun 08 01:17:49 DocScrutinizer: (valid) return some "this is not valid" indicator for the values that are affected. then those who are using the values may notice that they have to rethink their design Jun 08 01:18:10 DocScrutinizer: right now, they may think everything is fine, but it itsn't Jun 08 01:18:57 well, I dunno of any consumer of these values who had to rethink. after all these values are for user info *only* Jun 08 01:19:43 DocScrutinizer: still, confuse the user at your peril :) Jun 08 01:19:53 a system critical function MUST NOT and CAN not rely on bq27k Jun 08 01:19:58 DocScrutinizer: and it seems that at least you noticed that something was amiss :) Jun 08 01:20:19 ok, valid point. Jun 08 01:20:30 DocScrutinizer: i think the jury's still out on that. battery voltage and probably current look pretty decent. Jun 08 01:20:58 paul found he made a mistake by exporting the wrong register. prolly he'll fix that soonish Jun 08 01:21:02 DocScrutinizer: and we don't know what's the situation with the other values, because we don't even know if the CC itself believes they're valid Jun 08 01:21:11 ah, that wuold add to the chaos :) Jun 08 01:22:52 wpwrak: I'm not aware of any system action dependent of current_now. And for voltage_now we got thresholds in PMU which serve for the job much better than CC Jun 08 01:25:47 the premise is system should work exactly same reliable way with gta01/BL-5C bat as it does with gta02 bat. Of course the user info might be not that convenient, but all *system* functions MUST NOT rely on bq27k Jun 08 01:26:59 * DocScrutinizer wonders particularly mwester should like the idea Jun 08 01:28:55 :) That's why I'm asking questions -- can we justify to the powers-that-be that the work that Andy and others worked on so long to get pushed upstream should be significantly altered? Jun 08 01:29:09 DocScrutinizer: yeah, you shouldn't depend on anything you can't have if the CC isn't there Jun 08 01:29:34 I haven't heard any answers that satisfy me when I put myself in the "Andy" mindset. Jun 08 01:29:53 mwester: don't stay there too long :) Jun 08 01:29:58 hehe! Jun 08 01:30:05 I think upstream is fine so far Jun 08 01:30:19 mwester: what sort of radical changes did you have in mind ? Jun 08 01:30:58 it's only been FSO recently having a short erratic episode of connecting sys shutdown to CC Jun 08 01:31:13 I wouldn't say "radical", but I think this would pretty much amount to tossing the bq*.c sources. Jun 08 01:31:49 (not tossing out as in removing from kernel, but they would no longer be useful for anything practical) Jun 08 01:31:57 mwester: aii. that sounds pretty radical Jun 08 01:32:11 sure, for bat applet they are great Jun 08 01:33:24 but, as mentioned multiple times, bat applet is user info, not "system" Jun 08 01:34:05 bat management is entirely pcf50633 Jun 08 01:34:21 sys shutdown is pcf50633 Jun 08 01:34:41 If you are correct, then it is the case that the data we compute from the PMU information via some function of voltage/current woudl be more accurate than the CC -- then there is no point at all in exporting the CC information, is there? Jun 08 01:34:54 determining charging state is pcf50633 Jun 08 01:36:10 in pcf50633 we got thresholds triggering irq's. we got no actual voltage readout, and we don't need that for system purposes anyway Jun 08 01:36:50 err, (no v Jun 08 01:37:01 V readout) afaik Jun 08 01:37:05 True, but it would be nice to know what data the 50633 uses to do its determination -- because the gta01 could use that in the driver to "simulate" such an IRQ. Jun 08 01:37:07 DocScrutinizer: so .. the bottom line is that you're saying FSO should change the logic of its emergency shutdown ? Jun 08 01:37:50 ouch, pcf 50606 has *no* bat_low irq?? Jun 08 01:38:10 It does, but so low that we cannot resume/suspend if it is set to wake us. Jun 08 01:38:16 wpwrak: it actually has done this Jun 08 01:38:30 ouch, again Jun 08 01:38:44 yes, but not insurmountable as a problem. Jun 08 01:39:14 anyway, late here Jun 08 01:39:23 mwester: can't you just change the limit in BVMC ? Jun 08 01:39:26 good night guys :-) Jun 08 01:39:35 DocScrutinizer: so .. problem solved ? :) Jun 08 01:39:56 I think there is no current problem Jun 08 01:39:56 wpwrak, I think the discussions on this indicated that the variant we use is not programmable for this threshold. Jun 08 01:40:33 mwester: gaah. that again Jun 08 01:40:40 except of course that nonsense kernel bug switching state to charging, when actually it isn't Jun 08 01:41:22 mwester: "The register is reset at the initial start up of the PCF50606 (register type `S')." hmm ... sounds like from NoPower Jun 08 01:41:32 DocScrutinizer, I expect there will be opposition somewhere, but there is no reason we cannot pursue a patch that removes the CC, and replaces it with another mechanism (that has as a side effect that it works with the BL-5C dumb battereis as well). Jun 08 01:41:33 mwester: i.e., you could use it Jun 08 01:41:35 8 remeber wpwrak to guideline how to disable that Jun 08 01:41:57 wpwrak, I'll have to go check the datasheet again. :) Jun 08 01:42:14 * mwester makes a note to take a datasheet with him on his trip this coming week. Jun 08 01:42:22 mwester: that's never been my intention Jun 08 01:42:45 mwester: somewhere pleasant ? Jun 08 01:43:13 n8 Jun 08 01:43:46 wpwrak, at some point it will be pleasant, but I fear that right now it is probably home to many mice, spiders, crumbling bricks, and rotting windowsills... an old home that we have suddenly become responsible for. Jun 08 01:44:22 About 5 hours away, so one cannot just work on it in spare time. But neither can I let it crumble further, I fear. Jun 08 01:44:45 mwester: wow. i thought that sort of thing happened only to software projects :) Jun 08 01:44:53 Hehe! :D Jun 08 01:45:17 mwester: as long as it has power and internet access, you'll be fine :) Jun 08 01:45:32 Power it has. Internet access it does not. Jun 08 01:45:51 it is a fringe-area for GSM coverage as well. Jun 08 01:47:49 mwester: tricky. well, the neo seems to handle weak gprs quite well. a friend of mine is just using it these days at a farm. last time i've been there, my samsung x830 had trouble picking up anything if i didn't hang it off a tree Jun 08 01:48:10 Really? That's encouraging, actually. Jun 08 01:48:30 * mwester makes a note to take a gta02 along. Jun 08 01:48:37 mwester: yeah. there are things where the neo doesn't suck more than everyone else ;-) Jun 08 01:48:59 I'm actually rather fond of the little thing, with all its warts and problems... Jun 08 01:50:01 ;-)) Jun 08 02:29:34 /away **** ENDING LOGGING AT Mon Jun 08 02:59:57 2009