**** BEGIN LOGGING AT Sat Oct 04 02:59:57 2008 Oct 04 04:05:48 mwester: koen syncing our python w/ poky's version broke some tools Oct 04 04:05:59 i fixed pyrex and cython Oct 04 04:06:05 checking whether fso-image now runs through agian Oct 04 04:33:59 :( I think there's more broken, but there are some troubles with other things, so I'm not clear on what's only FSO and what is more global. :( Oct 04 04:35:07 I need to delete tmpdir more often on the autobuilder to make debugging easier, because I can't say that the toolchain issues are or are not due to recent events... Oct 04 07:19:45 freesmartphone.org: 03mickey 07framework * r068eb4ac1e2d 10/framework/subsystems/ogsmd/modems/abstract/ (mediator.py modem.py): ogsmd: fix enabling direct SMS sending. Todo: add unsolicited handler for CMT Oct 04 10:42:03 Hey Oct 04 10:47:18 alphaone: are you awake? Oct 04 10:52:36 rwhitby: Just fyi: I found the reason, why raster's scripts did not work. Bitbake changed with revision 1090 so that only whitelisted env vars are processed. Oct 04 11:15:42 emdete: pong Oct 04 11:50:47 Ainulindale, here? :) Oct 04 12:05:40 is there a reason why i cannot play a sound via pygame on my freerunner (running FOS), or is this my programming fault? Oct 04 12:09:15 IOhannes, is sound working at all? Oct 04 12:14:01 what's the jffs2.summary file on http://downloads.openmoko.org/framework/milestone3/ ? should there be a plain jffs2 file? Oct 04 12:14:29 quickdev, yes; i can playback sounds via "aplay" Oct 04 12:15:02 IOhannes, then I don't know Oct 04 12:15:24 Weiss, afaik a summary image boots a few seconds faster Oct 04 12:18:22 quickdev: ok - i (and someone on OM-Community) was wondering... Oct 04 12:21:26 i found the problem: pygame only works with OSS devices; so i had to initialize the alsa oss-emulation... Oct 04 13:49:31 can anybody tell me how i can change the default application that gets started in the FSO framework? currently this is zhone, but i would like to change that Oct 04 13:49:58 grepping all through /etc /usr/lib/python2.5/site-packages and ~/ has not reveiled much... Oct 04 13:51:22 IOhannes, zhone is started in /etc/X/Xsession.d/80zhone Oct 04 13:51:30 s/X/X11/ Oct 04 13:52:38 quickdev, you are my wondrous savior Oct 04 13:52:56 * IOhannes must have done something wrong with rgrepping /etc then Oct 04 13:53:41 /usr/bin/zhone-session iirc Oct 04 13:57:20 alphaone, ping Oct 04 13:58:46 or mickey|tw ? Oct 04 14:04:54 sometimes framework doesn't handle a call release, the ring tone is still played: http://rafb.net/p/WbgHLT26.html Oct 04 14:22:33 alphaone, did we talk about sim unlock timeout? Oct 04 14:44:14 alphaone, would be fine if you could fix a little bug (just changing one line) Oct 04 14:59:09 has anybody any experiences with using dbus and pygame? Oct 04 14:59:20 which mainloop should be used? Oct 04 14:59:29 or run both in separate threads? Oct 04 16:10:42 alphaone: i think in gpschannel.py self.datapending is always growing, never truncated... seems a bug to me Oct 04 16:11:07 quickdev: ping Oct 04 16:11:30 emdete: looks like it Oct 04 16:11:37 emdete: Thanks, I'll take a look at it Oct 04 16:11:42 quickdev: What bug? Oct 04 16:12:31 alphaone, sim unlock() produces a timeout, what I did: 1) set the timeout for CPIN 2 seconds higher and 2) added the timeout parameter in the sim unlock call Oct 04 16:14:40 quickdev: okay, sounds reasonable Oct 04 16:15:01 mickey|tw, btw, I'm suffering from the oscillating gsm bug. Haven't ever had a consistent connection more than two minutes. I think many more users are affected than thought. The bug will raise attention when software for the phone is more mature. What do you think? ;) Oct 04 16:15:17 alphaone: also the modularisation looks strange to me, there is dbus stuff at the protocol layer ubx.py, ubx stuff (reload of aiding info) at hardware layer om.py... Oct 04 16:15:43 quickdev: which modem sw version do you have? Oct 04 16:15:58 quickdev: i'm desperate wrt. 1024 Oct 04 16:16:09 emdete: You're my hero! Oct 04 16:16:12 emdete, how to find that out? Oct 04 16:16:28 You just found the cause of some weird thing I've been seeing Oct 04 16:16:30 emdete, uboot? Oct 04 16:16:32 mickey|tw: have you ever checked an old gta01 / old fw for CREG flapping Oct 04 16:16:37 quickdev: modem ;) Oct 04 16:16:52 emdete: IIRC yes, same problem Oct 04 16:16:56 emdete: need to recheck though Oct 04 16:17:18 for me the bug makes the phone useless because many incoming calls are rejected :( Oct 04 16:17:24 emdete, one moment Oct 04 16:17:29 mickey|tw: you should - fgau reports the flapping with his gta02, same condition don't show it with gta01... Oct 04 16:17:30 quickdev: in the dump you pasted, what did you do? receive a phone and immediately hang up ? Oct 04 16:17:33 s/phone/call/ Oct 04 16:17:58 mickey|tw, after very few seconds, yes - but I assume sometimes it happends later, too Oct 04 16:18:07 hmm Oct 04 16:18:08 mickey|tw: we have the same behavior with %CPI, it wrrks fine with gta01, it does not reliable with gta02 Oct 04 16:18:22 interesting Oct 04 16:18:28 emdete, where does fgau report it? Oct 04 16:18:34 alphaone: what for? the bug or the wishes? :D Oct 04 16:18:41 quickdev: to me ;) Oct 04 16:18:56 emdete, om employee? :) Oct 04 16:19:13 quickdev: i am doing a mobile stack pyneo which he is using. no, i'm not payed for it Oct 04 16:19:16 emdete: The bug Oct 04 16:19:30 alphaone: and now the bad news: Oct 04 16:19:44 emdete: The dbus stuff in ubx.py is just some debug interface shoragan added Oct 04 16:19:56 The generic stuff should be all in gpsdevice.py Oct 04 16:20:25 And yeah, I though about adding the aiding code to ubx.py and just having it enabled through the config file. Oct 04 16:20:27 alphaone: if i do the init only once, i often dont get it through. if i repeat the init it works. through your non-trnucating code this may work for you but wont in the futre Oct 04 16:20:56 alphaone: may i do an proposal? Oct 04 16:21:11 quickdev: (dump) is that really all you get? Oct 04 16:21:17 emdete: Yes I know Oct 04 16:21:34 alphaone: the need for redoing the init? you have that too? Oct 04 16:21:46 I was waiting to see if the tasklets would help there Oct 04 16:21:57 emdete: Occasionally Oct 04 16:22:13 not that often because you reinit all teh time ;) Oct 04 16:22:22 The init procedure doesn't wait long enough after powering the chip Oct 04 16:22:34 so does the ublox answer each sendet block? Oct 04 16:22:47 it should Oct 04 16:23:07 kind of accs? so you could wait for an acc and do the next? Oct 04 16:23:22 That's why I was seeing multiple ACK where I (though I) only sent one CFG packet Oct 04 16:23:23 mickey|tw, next time I can give you the whole log from system startup on, but did you noticed ": unhandled unsolicited data incoming: '+CRING: VOICE'" ? Oct 04 16:23:45 yes, that was the plan (send a packet, wait for ack, send next) Oct 04 16:23:46 emdete, is it possible to downgrade firmware? Oct 04 16:23:47 you will use tichy's tasklets in fso soon? Oct 04 16:24:07 quickdev: shure, not yourself but om can do as far as i know Oct 04 16:24:08 emdete: We already do in some places Oct 04 16:24:25 pygsmd has a similar aproach already. works great Oct 04 16:24:32 I don't quite understand them enough yet. Oct 04 16:24:51 it just turns around the flow :) Oct 04 16:26:07 quickdev: that's expected. we don't use CRING+VOICE Oct 04 16:26:34 quickdev: i think i know what happened Oct 04 16:26:52 quickdev: thanks anyways, your dump helps me Oct 04 16:27:18 mickey|tw: what's wrong in the dump? Oct 04 16:27:28 mickey|tw, I just see, maybe my application quit after hangup and gsm was disabled? ringing still on? Oct 04 16:27:49 quickdev: exactly Oct 04 16:28:01 ah, fine :) anyway that shouldn't happen :) Oct 04 16:28:04 emdete: nothing per se, just the new resource handling has some races on shutdwn Oct 04 16:28:06 sure Oct 04 16:28:14 i'm not handling disabling resource gracefully Oct 04 16:28:17 yet :) Oct 04 16:28:22 ~lart mickeyl for being lazy Oct 04 16:28:27 will do that next week Oct 04 16:28:40 need to hang up if a call is ongoing and wait until the queues are drained Oct 04 16:28:44 alphaone, mickey|tw : is your modem firmware version listed in the detail for bug #1024? Oct 04 16:28:49 mickey|tw: ah, okay, i thought maybe you have a similar problem like i have with %CPI Oct 04 16:29:05 mwester: sure, tried with all kinds of firmwares -- noone made a difference Oct 04 16:29:16 emdete: no, CPI was (until now) 100% reliable to me Oct 04 16:29:18 Ok. Oct 04 16:29:52 mickey|tw: it /always/ tells you "end of call"? Oct 04 16:30:07 mickey|tw: better: it /always/ tells you "end of ringing"? Oct 04 16:30:35 mickey|tw: we have poblems when the other end gives you a call & ghangs up. do that 3 times in a row Oct 04 16:31:01 mickey|tw, so you already tested a neo gta02 with an old hardware? Oct 04 16:31:05 emdete: can't confirm that yet, but will do Oct 04 16:31:19 quickdev: old hardware? Oct 04 16:31:29 mickey|tw, s/hard/firm/ Oct 04 16:31:34 ah Oct 04 16:31:35 yes, i did Oct 04 16:31:44 firmware differences did not make a difference Oct 04 16:31:49 (for me) Oct 04 16:31:56 it's a pity :( Oct 04 16:32:02 *nod* Oct 04 16:32:14 mickey|tw, what about borrowing a TI worker for two weeks? :) Oct 04 16:32:43 And a length of chain to make sure he doesn't leave the desk until it's fixed. Oct 04 16:32:45 quickdev: by now i doubt there's still anyone in TI that knows about this code Oct 04 16:33:20 ~lart EOLed chips Oct 04 16:34:29 mickey|tw, could you imagine that openmoko will collaborate with them in order to fix it? or is there no intention from openmoko or the relationsship too bad? Oct 04 16:37:23 ... the channel falls silent as everyone waits for a possible response to that policitally-sensitive issue... ;-) Oct 04 16:38:59 i don't know, really Oct 04 16:39:11 relationship is not the best Oct 04 16:39:21 and TI already looked at the dumps, but found nothing Oct 04 16:39:27 (that's what they said...) Oct 04 16:39:42 mickey|tw, they looked at the high level gsm dumps? Oct 04 16:40:12 iirc low level Oct 04 16:41:33 i do not know more than is written in #1024 Oct 04 16:42:19 I hope openmoko management is informed about it and that it's fixed in the next months, but I doubt. However it could become more serious than the gps ttf bug, if it's a widespread problem...let's pray :) Oct 04 16:44:35 mickey|tw, a last question towards 1024: Did you notice: "This wasn't a problem when I worked with gsmd some months ago." ? Oct 04 16:45:01 sure i noticed that Oct 04 16:45:03 i wrote that Oct 04 16:45:16 (I'm the reporter of that bug) Oct 04 16:45:23 but i think I got it wrong Oct 04 16:45:29 gsmd was very unstable back then Oct 04 16:45:31 mickey|tw, ah, right, sorry - thought sean was it Oct 04 16:45:50 i think the whole system was just not stable enough to have anyone really see it Oct 04 16:45:56 which is different nowadays Oct 04 16:46:23 and the visibility will increase with better software, hehe ;) Oct 04 16:46:49 yep Oct 04 16:49:31 mickey|tw, is there anything I could to for 1024? Maybe getting much more statistics about the incidence? Oct 04 16:50:34 more data doesn't hurt Oct 04 16:50:48 but there's a solid theory by now Oct 04 16:51:03 which seems to stabilize the more we look into Oct 04 16:51:19 (depending on cell traffic) Oct 04 16:54:17 mickey|tw, why not publishing such theories? People could verify it ;) Oct 04 16:59:01 freesmartphone.org: 03jluebbe 07framework * rc8c70b0d02c4 10/framework/persist.py: persist: fix loading empty file Oct 04 17:00:31 why isn't available an updated image of shr on bearstech? Oct 04 17:01:15 the last image is dated "15th september" Oct 04 17:03:33 quickdev: well, that's mwesters baby :) Oct 04 17:03:37 mickey|tw, what about cell broadcasts sent every ~1 minute? Maybe that's why it cancels that often? Oct 04 17:03:39 i meant "we" as in community Oct 04 17:03:58 there are no cellbroadcasts in germany Oct 04 17:04:03 (except on o2) Oct 04 17:04:13 :( Oct 04 17:04:33 mickey|tw, so there's nothing sent once registered and if there are no events? Oct 04 17:04:45 nope Oct 04 17:07:42 * mwester didn't publish the theory on cell traffic because further evidence seemed to disprove it. Oct 04 17:07:50 really? Oct 04 17:07:58 how can you tell? Oct 04 17:08:05 [the amount of concurrent cell traffic] Oct 04 17:09:03 Collecting data over a week showed no real correlation, and found another reason to explain why it goes away sometimes. Oct 04 17:09:52 The 4.3.3 Qtopia image on the Neo with the firmware I have on the 850 Neo will stop the bouncing after either an incoming or outgoing call is complete. Oct 04 17:10:08 It will start again as soon as the modem is reset. Oct 04 17:10:25 No other images do this, no matter what I try. Oct 04 17:10:36 hi, my setup was this: a prepaidcard in gta02/moko8 fw and we see a flapping as emdete has described, then I have tested this with my gta01/moko1 fw and all works fine. so i think the firmeware updates are the failure part Oct 04 17:10:56 mwester: interesting. please give me links to your qtopia testing image. Oct 04 17:11:05 Nor can I make it stop bouncing if I do the same GSM AT commands in the same sequence as the Qtopia image does, so it would seem timing plays a part. Oct 04 17:11:26 mickey|tw: http://moko.mwester.net/brc.html Oct 04 17:11:30 thank Oct 04 17:11:31 s Oct 04 17:12:30 I reset it early last week, made a call to make it stop bouncing, then took the GTA01 on a business trip -- 800 miles, driving, including a trip into Canada, and while it changed cell sites often it did no bounce at all. Oct 04 17:13:02 Upon resetting it halfway back on the trip in the middle of nowhere in Michigan, it began bouncing again. Oct 04 17:13:46 There is a pattern in the data I have, I just do not know what it is, but I have a strong feeling that there's something in there. Oct 04 17:15:37 fgau: Yep, I think the modem firmware is a factor as well. My problem here (in the US) is that the old neo with the old firmware is 900MHz only and has no good coverage here, so I can't really confirm for myself. Oct 04 17:15:41 freesmartphone.org: 03daniel 07framework * rbd4b1b4080cf 10/framework/subsystems/ogpsd/gpsdevice.py: Oct 04 17:15:41 freesmartphone.org: ogpsd: Make Gypsy .Server methods callable if the resource is disabled Oct 04 17:15:41 freesmartphone.org: Without this fix standard Gypsy programs wont work Oct 04 17:15:42 freesmartphone.org: 03daniel 07framework * r686ab06b63be 10/framework/subsystems/ogpsd/gpschannel.py: Oct 04 17:15:44 freesmartphone.org: ogpsd: Clear sendbuffer after sending stuff (emdete) Oct 04 17:15:46 freesmartphone.org: Before we would resend everything that has ever been sent again and Oct 04 17:15:48 freesmartphone.org: again. Big thanks to emdete for discovering! Oct 04 17:15:50 freesmartphone.org: 03daniel 07framework * r0c5bca63bac7 10/framework/subsystems/ogpsd/om.py: Oct 04 17:15:53 freesmartphone.org: ogpsd: GPS epoch is Oct 6th not Oct 5th 1980 Oct 04 17:15:55 freesmartphone.org: With this fix the time should be calculated correctly for the GPS Oct 04 17:15:57 freesmartphone.org: receiver. Also slightly increase the time we wait after power on so the Oct 04 17:15:59 freesmartphone.org: first configure packets don't go astray. Oct 04 17:17:55 and now to quickdev's bug Oct 04 17:18:08 quickdev: 7 seconds is okay for Unlock Oct 04 17:18:10 ? Oct 04 17:18:39 mwester: the firmware is released from Om, and I see the bug in the firmware upgrades they have made Oct 04 17:21:14 fgau: that's a bit of an assumption -- I think it might be true, but I would assume that Om has already looked very closely at the firmware changes they have made to see if they may have caused this. Oct 04 17:21:26 Certainly that's what I would expect anyway... Oct 04 17:22:22 alphaone, I think I tried 9...but 7 should be ok, yes Oct 04 17:24:13 mwester, very interesting! Keep on doing such great work :) Oct 04 17:34:57 mickey|tw, you said it is a heisenbug, because gta #60 emitted the bug before and didn't emit it in modem-stress-test? Maybe the modem-stress-test forced the gsm part not to fall into sleep and thus network was not released? Oct 04 17:35:31 the comment about the heisenbug was because after all, _no_ usage pattern really made a difference Oct 04 17:35:45 i have never been able to reproduce it at a given time or make it stop by will Oct 04 17:36:05 and leaving it on for several days here make it appear, then stop, then appear Oct 04 17:38:26 mickey|tw, is there a way to force gsm to be awake? Oct 04 17:40:01 yes Oct 04 17:40:04 send a command every 6 seconds Oct 04 17:43:47 mwester, I'll try your image, too Oct 04 17:52:17 freesmartphone.org: 03daniel 07framework * r6d30d6eb5e13 10/framework/subsystems/ogsmd/ (gsm/const.py modems/abstract/mediator.py): ogsmd: Replace timeouts of individual commands with command classes Oct 04 17:52:51 okay, rebuild... Oct 04 18:05:27 alphaone, it works. Thanks again for your fast fix :) Oct 04 18:10:22 quickdev: Thanks for reporting :-) Oct 04 18:12:54 If 7 seconds is not enough we can increase them, but let's try to start conservative Oct 04 18:14:07 Sascha: ping Oct 04 18:14:50 Sascha: When ogpsd isn't reporting any time at all tangogps somehow confuses the date and shows weird stuff. Oct 04 18:15:00 Do you know why that is? Oct 04 18:15:01 alphaone, yeah, and it works for our boucing rubber calypso ;) Oct 04 18:15:17 quickdev: :-) Oct 04 18:17:26 alphaone: pong Oct 04 18:17:44 jepp Oct 04 18:18:31 tangogps doesnt check if there are valid timestamps in nmea rmc sentences Oct 04 18:18:49 Oh, okay :-/ Oct 04 18:19:19 Anyway, as soon as the aiding data is working fine you should get the correct time pretty soon Oct 04 18:19:58 :) Oct 04 18:25:56 :) Just updated bug 1024 -- I stumbled on a command in the enfora documents, and everything just fell into place. Oct 04 18:26:40 quickdev, mickey|tw: send "AT%SLEEP=2" to the calypso. Oct 04 18:27:38 mwester, so luckily my thought was right :) Oct 04 18:28:26 quickdev: Yep. That was another bit of the puzzle that I hadn't considered too much until you mentioned it. Oct 04 18:28:31 I actually tried that Oct 04 18:28:41 and set up Qtopia to poll -- and it worked. Oct 04 18:29:23 But that was some time ago, and I dismissed it as the calypso not sending unsolicited unregister/register events because the serial port was kept busy. Oct 04 18:29:48 In fact, it's more probable that it kept the calypso from sleeping and hence it worked. Oct 04 18:29:52 mwester: Cool find! Oct 04 18:30:17 We'll need to check whether that fixes 1024 on all occasions, but it looks promising Oct 04 18:30:59 Now we need Om to go back to the GSM code and find out why it won't enter deep sleep. The Enfora docs suggest a very large difference between power used in what they call "big sleep" and "deep sleep". Oct 04 18:31:46 alphaone: :) If you can put some diag/test code in FSO, it'll get tested quickly I suspect. I'll put a qtopia patch together. OM2008.9? meh, nobody uses that! Oct 04 18:32:15 FSO patch would be fine :) Oct 04 18:32:16 mwester: mickey|tw is already on it Oct 04 18:32:27 great teamwork here :) Oct 04 18:32:32 :-) Oct 04 18:33:01 So what exactly does AT%SLEEP still allow the Calypso to do when idle... Oct 04 18:33:26 Battery runtime, fixing 1024 - choose one Oct 04 18:33:29 I dunno. I have only the enfora enabler II docs, and they do not explain it much either. Oct 04 18:33:34 interesting find Oct 04 18:33:39 But it's a great lead Oct 04 18:33:51 what puzzles me is that this is yet _another_ command that is not listed in our proprietary documentation Oct 04 18:33:53 *grr* Oct 04 18:34:20 alphaone: Yes, that's true -- but the oscillating calypso wasn't sleeping either. So a patch that ONLY disables the deep sleep when oscillation begins might be the best compromise we can find. Oct 04 18:34:28 Seems we need the proprietary undocumentation as well :-) Oct 04 18:34:40 mickey|tw: om has the code of the at interpreter - shouldnt that give all commands? Oct 04 18:34:48 mickey|tw: And hidden -- it is accepted as a command but will not work as a query. Oct 04 18:34:48 mwester: Yeah, sounds good Oct 04 18:35:30 BTW, a quick set of notes and description is in the bug report too. Oct 04 18:36:12 And the qtopia hack has booted up, registered to the network, and now sits quietly. Nice. Oct 04 18:36:48 I'm leaving, good success! Oct 04 18:36:54 have a nice day :) Oct 04 18:37:01 bye quickdev Oct 04 18:45:22 Enfora Enabler lists "Big sleep" (%SLEEP=2) at 25mA current drawn by the GSM, while "Deep sleep" (%SLEEP=4) is only 5mA --- it would be a real shame to have to disable deep sleep to fix this. Oct 04 18:45:46 alphaone: i have 2 other strange issues with ubx: sometimes it shows it has a fix while lat/lon are 0/90 and sometimes the height is in the latitude field. have you seen something like that too? Oct 04 18:45:53 Also, the "drops the first character sent" behavior is associated with Deep sleep. Oct 04 18:47:19 The height in the latitude field? Oct 04 18:48:45 emdete: No, I haven't had that Oct 04 18:52:42 and the other one with the fix before a fix is there? Oct 04 18:53:39 alphaone: regarding tangogps and time: the real course is in tangogps's parse_nmea_rmc function, which doesnt check the length of the timestamp string and thus reads garbage data if it is shorter than expected... just if you want to forward the bug to the tangogps author... Oct 04 18:55:17 Sascha: Okay, thanks. Oct 04 18:55:28 emdete: Not sure I saw that before. Oct 04 18:55:31 Could be Oct 04 18:59:20 is the code in handle_NAV_STATUS() correct? looks strange ;) Oct 04 19:04:20 emdete: Yeah, it is Oct 04 19:05:51 that's because ubx has invalid/no/2d/3d/dead-reckoning/.../ fix modes Oct 04 19:06:05 while gypsy only supports no/2d/3d Oct 04 19:07:16 so if in flags bit 0 is set you have a fix anyway? Oct 04 19:07:28 hmm, i cannot call the ogpsd methods any longer while the device is powered off... is this expected? Oct 04 19:12:22 alphaone: in that case i would turn around the function - first ask for the bit and only if its not set do the rest Oct 04 19:12:46 No, if it is not set I don't have a fix Oct 04 19:13:13 fixstatus=1 in gypsy means no fix Oct 04 19:13:14 it says: if data["Flags"]&0x01 == 0: self.gpsfixstatus = 1 Oct 04 19:13:19 ah, okay Oct 04 19:13:28 2 is 2d and 3 3d Oct 04 19:13:47 so why dont you do the 2 lines before in an else: part of that if? Oct 04 19:14:45 No special reason Oct 04 19:15:13 speedup ;) just because the bugreport that gpsd takes 40% cpu Oct 04 19:15:35 heh Oct 04 19:15:49 Well, it's only a speedup if I don't have a fix Oct 04 19:16:12 okay, you're right :) but i have e hint for you :D Oct 04 19:16:24 i tested around with gps and the high load Oct 04 19:16:45 I think this is the time where I hint at "send patches" :-) Oct 04 19:16:46 and came to a strange conclusion: enablign threads for glib/dbus/... takes alot cpu resources Oct 04 19:16:56 oh, okay Oct 04 19:17:07 do we enable threads? Oct 04 19:17:10 so pyneo will seperate that Oct 04 19:17:21 shure, gsm needs it as far as i know Oct 04 19:17:45 there will be daemons with threads that enable it and the other wont Oct 04 19:17:46 ogsmd does not use threads Oct 04 19:17:57 so look for that, maybe... Oct 04 19:18:04 nothing uses threads in frameworkd Oct 04 19:18:10 teh other problem is the 8-byte kernel-turnaround Oct 04 19:18:18 that's why we have the tasklets Oct 04 19:18:33 ./framework/subsystems/ogsmd/objects.py: from gobject import threads_init, MainLoop Oct 04 19:18:46 ./framework/subsystems/ogsmd/objects.py: thread.start_new_thread( run, () ) Oct 04 19:18:53 ./framework/patterns/asyncworker.py: gobject.threads_init() Oct 04 19:19:24 emdete: Yeah, that's only in the testing code Oct 04 19:19:30 throw away that thread-init and try. pyneo run much faster without Oct 04 19:19:48 okay, maybe. that's sad Oct 04 19:20:18 have you seen that you always read 8 bytes if you get called taht data is ready to read? Oct 04 19:21:32 maybe there is some optimizing possible Oct 04 19:22:05 emdete: Yeah, I have seen that as well Oct 04 19:22:25 though are you sure that reads are always just 8bytes? Oct 04 19:22:29 i always thought the fifo is 16 bytes... Oct 04 19:22:37 quite shure, yes Oct 04 19:23:13 that doesn't have anything to do with the fifo since the kernel buffers as well afaik Oct 04 19:23:31 maybe py-serial than? Oct 04 19:24:17 emdete: how did you get the figure 8? Oct 04 19:24:32 i debug-printed the reads Oct 04 19:24:54 in the channel? Oct 04 19:24:59 yes Oct 04 19:25:10 okay Oct 04 19:25:43 We need a way to tell gio to wait for n ms after first data is available. Oct 04 19:26:02 so we can queue up the data and just do one read Oct 04 19:26:28 did you know that pyserial does a select() call also for each read? Oct 04 19:27:01 I already had a look at it some days ago but it didn't seem too easy to fix Oct 04 19:27:05 it does? Oct 04 19:27:09 hmm Oct 04 19:28:21 If you like please open a bug about the 8-byte reads Oct 04 19:28:37 hm, will check that further... Oct 04 19:35:59 mwester: %sleep=2 is the best setting Oct 04 19:38:12 fwiw, the command can not be found in our source code. it's hidden in the TI libs where we only have object code for. Oct 04 19:38:17 amazing find anyways Oct 04 19:38:19 g'night Oct 04 19:46:44 * mwester has a patched neo w/Qtopia and a freerunner w/qt extended, both happily quiet and no longer bouncing sitting upon his desk... Oct 04 19:48:54 i have never seen the reg/dereg on a gta01 Oct 04 19:49:52 what firmware? Oct 04 19:50:05 GSM, that is? Oct 04 19:50:30 not sure, the gta01's are at work Oct 04 19:50:54 * mwester has what he suspects is an unusual GTA01 -- it's an 850MHz GTA01 with Moko5 firmware. Oct 04 19:51:43 I should do more tests with the old 900MHz Moko 1 firmware, but it has such lousy cell sites here (1800 is urban only, and I'm waaaay out in the suburbs) Oct 04 19:52:39 I am trying a patch that adds SLEEP=2 in modemservice reset/wake and SLEEP=4 in suspend funcitons. Oct 04 19:52:55 sp far seems to be working well Oct 04 19:53:05 interesting idea. Oct 04 19:53:23 mickey|tw|zzZZzz: what exactly does sleep=2 do? Oct 04 19:53:39 If you can send a link with the patch, I'll be happy to test on a couple of devices that are VERY bouncy indeed, and see what happens. Oct 04 19:53:46 ok Oct 04 19:54:04 gotta run for a bit, bbiab... Oct 04 19:58:27 just saw it re-register Oct 04 19:58:29 ;( Oct 04 20:01:10 hmm. maybe I hadn't uploaded the new plugin.. hehehe Oct 04 20:08:24 hmm .. maybe SLEEP=0 Oct 04 20:40:41 so far so good Oct 04 20:41:17 after the initial crud of reset() being called 3 times, it seems to be stable here. Oct 04 20:41:34 with 4.4.1 Oct 04 20:47:47 Cool. Oct 04 20:48:27 Also, the %CSQ needs to be put back in, as +CSQ is not able to work as an unsolicited message. Oct 04 20:49:00 (glad that you're seeing the 3x reset problem too, I thought maybe I screwed something up in my patches. Oct 04 20:49:02 ) Oct 04 20:52:18 mwester: cool patch the sleep=2. it's solved my flappy CREG. thx Oct 04 21:14:08 nomeata: I'm having trouble running the install script with neo. Do you have any advise? Oct 04 21:16:27 hi nomeata, have you got a moment? Oct 04 21:18:53 I am hoping to get a few tiny patches into zhone and zhone-session, so that they can detect and work nicely with a toolbar I have written Oct 04 21:22:00 the aim of the toolbar is to have functionality that should not be in zhone (such as the recently removed battery meter) so hopefully it will be a fairly obvious thing most current zhone users will want to run Oct 04 21:27:30 dgym: brightness control is what i'd need most Oct 04 21:28:01 it already has that iirc Oct 04 21:28:53 mwester: hows that patch going? seems to work even without your other reg/re-reg patch Oct 04 21:30:02 it does already have brightness control, but I have seen commit logs in frameworkd and zhone that mean they will not need any further changes Oct 04 21:31:57 once those changes have been brought into their respective debian packages I will just have to rework my controls Oct 04 21:32:25 dgym: why exactly do you need to change zhone? Oct 04 21:32:32 nomeata: any idea what it would take to get xserver-xfbdev in armel if xserver-xglamo is in fso-pkg? Oct 04 21:32:38 emre_: With a neo1973? or a Freerunner? Oct 04 21:32:59 nomeata: on 1973. Oct 04 21:33:17 tmzt_: no idea, I’m very much into the X server issues. Is xserver-xfbdev in Debian experimental, but not built for armel? Oct 04 21:33:29 nomeata: When I run: ./installDebianOnNeo.sh fso It says: "zhone-session: Depends: fso-frameworkd but it is not going to be installed" Oct 04 21:33:51 nomeata: it was, but seems to have dissapeared Oct 04 21:34:01 emre_: it’s not neo1973 specific, but hasn’t been debugged yet. Oct 04 21:34:01 nomeata, I just need a command line option in zhone to stop it locking its window - the toolbar does a system wide screen lock so it works with any running applications Oct 04 21:34:20 nomeata: I built it by hacking up control, and removed gl1 dependency Oct 04 21:34:42 emre_: can you run "apt-get install fso-frameworkd" in the Debian chroot manually? Oct 04 21:34:43 nomeata: sorry, built it for armel Oct 04 21:34:51 ok Oct 04 21:35:02 tmzt_: it was removed from experimental? do you know why? Oct 04 21:35:25 nomeata: no, it had the build logs online from a link, but can't find them again Oct 04 21:35:26 I also need the patches to disable zhone's brightness control, they are in upstream Oct 04 21:35:37 nomeata: no, I had the build logs ... Oct 04 21:35:50 nomeata: It says "fso-frameworkd: Depends: gstreamer0.10-plugins-good but it is not going to be installed" Oct 04 21:35:52 dgym: hmm. I assume that this feature ought to be removed in upstream zhone anyways, so I’ll have to ask you to discuss it with them. I’d rather avoid patch zhone too heavily for debian Oct 04 21:36:08 emre_: ok, now apt-get install gstreamer0.10-plugins-good, and see the next error message Oct 04 21:36:38 ok, I agree, do you know who I need to contact at all? Oct 04 21:37:14 tmzt_: it is still in experimental: http://packages.debian.org/experimental/xserver-xfbdev Oct 04 21:37:23 tmzt_: why did you have to change the control file for it to build? Oct 04 21:37:38 dgym: sorry, no. smartphone-userland would be the appropriate mailing list, though. Oct 04 21:37:44 nomeata: the problem is: libcucul0 needs libcaca0 (>= 0.99.beta15-1) but 0.99.beta14-1 is to be installed. Oct 04 21:38:04 emre_: ok, so it’s the armel buildd lagging behind, as can be seen here: Oct 04 21:38:07 that bugs has already been reported at bugs.debian.org/libcaca0 Oct 04 21:38:23 ok, thanks nomeata Oct 04 21:38:27 nomeata: it FTBFS, it's not just slow Oct 04 21:38:30 funny name :) Oct 04 21:38:36 http://buildd.debian.org/pkg.cgi?pkg=libcaca Oct 04 21:39:07 oh, ok. yes, then whatever lindi- says :-) Oct 04 21:39:59 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500492 has a proposed patch Oct 04 21:40:01