**** BEGIN LOGGING AT Wed Dec 30 02:59:57 2009 Dec 30 07:21:37 Is there anyone who try to run SHR image on qemu-1973? Dec 30 08:24:39 jhlee: i was thinking about trying it about an hour or two ago. have you tried ? Dec 30 08:25:08 jhlee: i considered unzipping one of the tarball images and trying to start it up Dec 30 08:30:12 gonzoism: I still try Dec 30 08:40:09 jhlee: i will try too Dec 30 08:40:24 jhlee: any howto or anything you are working from ? Dec 30 09:02:23 jhlee: i read the wiki, and won't be trying for a while. i don't have the disk space or bandwidth to do that at the moment. i was excited with the idea and look forward to setting that up in the future. if you run into anything you want a second pair of eyes on, let me know, i'd love to see it. Dec 30 09:06:15 wpwrak: ping (OT) Dec 30 09:15:21 what about eglibc option "LIBM_BIG Option Group" for freerunner (replacing all double-precision math functions with single-precision)? could it be usefull? Dec 30 09:32:29 <|_0xEF|> guys, does remoko from SHR packages collection (testing) work for anyone?.. Dec 30 09:34:33 |_0xEF|: there was some work to port remoko to bluez4 but i'm not sure if it ever completed. Check remoko's repo. Dec 30 09:36:51 PaulFertser: pong ... *yawn* Dec 30 09:38:14 Hello , each time is required to connect internet , ipmasq should be stopped first , and then for sharing network starting it is needed , how to avoid doing so after each reboot ? Dec 30 09:38:28 wpwrak: is it morning for you? ;) Must be a good one. At least it's cool in here: -5C and plenty of nice snow. :) Dec 30 09:39:30 PaulFertser: it's nice and warm here. still way too early ... (having constructions work going on, hence the weird hours) Dec 30 09:39:50 wpwrak: i see. Now to the actual question :) Dec 30 09:42:29 wpwrak: we use input subsystem to report EV_ABS values from the g-meters. And sysfs nodes to set its parameters. Is it really a sane way to do things? I.e. the fact input layer suppresses events that are the same as previous makes e.g. averaging difficult. I'm asking because i'm trying to write a nice driver for a PCI DAQ board and i'm considering providing some simple API first (because the complex one with mmapping kernel buffers directly f Dec 30 09:42:35 ... userspace to achive maximum bandwidth would require me to make dma work and that is something i'm yet to try). Dec 30 09:44:08 PaulFertser: hmm, you should still be able to do the averaging, by using the timestamp, no ? Dec 30 09:44:53 PaulFertser: i would think it's a bit of an abuse of the input subsystem, but i'm not sure how common this sort of abuse is. Dec 30 09:46:19 wpwrak: yes, sure, timestamps in any input event is something very nice and that is the thing that made me think of using the input layer, but it is a bit too clumsy. I imagine i want to get like 10 samples, so i first do ioctl to get current values, store them, then do select with appropriate timeout on event device, then if there's something to read, i read and pad my userspace buffer according to the timestamp, then adjust timeout, do sele Dec 30 09:46:25 ... again etc. A little bit too clumsy for my liking ;) Dec 30 09:47:36 any opinion ? Dec 30 09:53:21 alabd: i would script it. Dec 30 09:53:32 alabd: i wouldn't use ipmasq in the first place Dec 30 09:54:11 PaulFertser: first place ? Dec 30 09:54:56 script you mean script stop it first then run it each time ? Dec 30 09:54:57 alabd: i mean i wouldn't use ipmasq at all Dec 30 09:55:23 PaulFertser: but it's required to share desktop internet into fr Dec 30 09:56:06 alabd: i doubt that, somehow managed to live without Dec 30 09:56:59 PaulFertser: hmm, wouldn't that work ? input does buffer a bit. so you may get <= N events and then you can reconstruct the timing. you don't even have to select, just wait and then read. Dec 30 09:57:41 wpwrak: what if the input voltage is so stable i do not see any changes at all? I'd sleep forever on my read() i guess ;) Dec 30 09:58:22 PaulFertser: who said it had to block ? :) Dec 30 10:00:41 wpwrak: well, one can go either non-blocking i/o or select way but it would look suboptimal anyway. Probably it would be nicer to have input subsystem pass all the events reported when explicitly asked. Dec 30 10:00:59 PaulFertser: select() on the fd will return for each event, so if you already know that you're not interested in the data before 10 of them have accumulated, that's not the right approach. of course, now you depend on the input layer doing enough buffering for you. not sure if it does. a few numbers are popping up in my head :) Dec 30 10:01:00 wpwrak: anyway, what's your opinion on a kernel-userspace API for a DAQ board. Dec 30 10:02:57 PaulFertser: hmm, what do the general ADCs use ? Dec 30 10:04:01 wpwrak: i was told there's no established interface for that. Dec 30 10:05:04 wpwrak: there's hwmon but it doesn't look it comes anything close to what DAQs need. Dec 30 10:05:08 PaulFertser: regarding a "return only after N samples" policy, i think that could be useful for high sample rates. Dec 30 10:05:42 hwmon is far. ah well, so there's your opportunity to earn eternal fame and design a new kernel API ;-) Dec 30 10:06:06 wpwrak: to me it seems high sample rates should be handled differently altogether, mmaping the buffers. Input subsystem was never about that. Dec 30 10:08:17 yeah, a general ADC is probably stretching the input subsystem's semantics too far. Dec 30 10:09:27 wpwrak: why do not g-meters? Dec 30 10:09:28 mmap'ed buffers sound good. you wouldn't want to enforce large buffering in the kernel anyway. you could make it work with a blocking read (so the buffer is available while you wait), though. but then you have to figure out how to live without double-buffering. or require multithreading ;-)) Dec 30 10:10:01 g-meters may as well. i don't know why they use the input subsystem. they're kinda inputish, perhaps that's why. Dec 30 10:10:15 I can't see much difference. Dec 30 10:11:28 i wonder if there's an ioctl path back through the input system. things like g-meters could definitely benefit from it, e.g., to set thresholds. Dec 30 10:12:12 wpwrak: also the fast and efficient solution (mmaping buffers to where the card dmas data) would be very card-specific which is ok when one needs maximum performance. But for many aux tasks something low-freq is enough and having a common enough (among DAQ boards) api would be beneficial. Dec 30 10:12:37 PaulFertser: as i said, i'm not sure why g-meters are done they way they are. for me, a different api could make sense. Dec 30 10:13:03 PaulFertser: mmap could also use a "normalized" format. it doesn't have to be raw bits from the card Dec 30 10:13:16 wpwrak: but then it's not the maximum performance one can get. Dec 30 10:13:39 anyway, gotta run. construction workers will show up soonish. Dec 30 10:13:59 modern cpus are fast ;-) and you can always have a "raw" mode without rules Dec 30 10:15:21 DRM for input devices? Dec 30 10:15:36 wpwrak: thanks for the talk and good luck :) Dec 30 10:18:03 Weiss: Hi, not sure why, but I already got WSOD twice, maybe without suspend involved for 2.6.32 with drm patches.. Dec 30 10:18:34 Weiss: I had fsoraw -r CPU,Display running.. that's why I hope that it wasn't trying to suspend and usb cable was connected for power Dec 30 10:19:18 Weiss: probably you have an opinion about DAQ boards and preferred api? Dec 30 10:27:59 PaulFertser: not an area I really know about.. Dec 30 10:28:14 JaMa: maybe it was trying to blank? Dec 30 10:28:31 Weiss: yes but imagine you're a researcher who needs to have some decent ADC in your PC to make measurements ;) Dec 30 10:29:09 hehe, yep... actually we use stuff borrowed from the particle physicists for that Dec 30 10:34:13 Weiss: even blanking should be disable after Display resource request Dec 30 10:34:53 Weiss: but maybe fsoraw/frameworkd failed bacause something in 2.6.32.. Dec 30 10:41:06 is frameworkd updates with all the new sysfs/ALSA names in 2.6.3{1,2}? Dec 30 10:41:10 updated* Dec 30 10:44:43 Weiss: mrmoku has simple script to update some.. Dec 30 10:45:09 http://build.shr-project.org/tests/mrmoku/switch-for-kernel Dec 30 10:47:29 oo, useful Dec 30 10:47:55 that means I should be able to switch to 2.6.32 more permanently and test thoroughly Dec 30 11:43:17 freesmartphone.org: 03mickey 07cornucopia * r9bde0a566880 10/fsogsmd/src/lib/atparser.vala: fsogsmd: parser: support a banner state that waits for a certain line until we move to the actual start state Dec 30 11:43:18 freesmartphone.org: 03mickey 07cornucopia * r14bb5da71bbc 10/fsogsmd/src/plugins/modem_ti_calypso/plugin.vala: fsogsmd: ti_calypso: set 'AT-Command Interpreter ready\r\n' as banner for parser Dec 30 11:43:53 mickeyl: changing the GSM parser? Dec 30 11:45:53 yes Dec 30 11:46:10 parser knows about the TI banner now Dec 30 11:46:29 or rather... parser supports configurable banners now Dec 30 11:46:41 TI being the only one that uses it for now Dec 30 11:47:23 as all my other modems don't tell something non-AT when they're alive Dec 30 11:47:27 :) Dec 30 11:47:48 well, we could change the firmware ;) Dec 30 11:49:03 w/ libgsm0710mux we no longer do the modem wakeup dance we did before Dec 30 11:49:13 like... sending \x1A until we receive an OK and so Dec 30 11:49:27 hence we need to acknowledge the modem wakeup banner Dec 30 11:57:45 mickeyl: can you please give me op at #openmoko? Dec 30 11:58:09 once or for all? Dec 30 11:58:22 mickeyl: through chanserv so i can get it whenever needed Dec 30 11:59:01 mickeyl: there're some occassions when it's desirable, e.g. some guy with flaky connection spamming the channel by join/part. Dec 30 11:59:11 And you're away and i'm not. Dec 30 11:59:40 try to OP yourself now Dec 30 12:00:16 *nod* Dec 30 12:00:18 mickeyl: yo, thanks :D Dec 30 13:31:39 I am building SHR image from shr-project.org, but I stopped compiling due to vala-bootstrap-native Dec 30 13:32:19 I couldnt find openembedded/recipes/vala/vala-bootstrap-native.bb Dec 30 13:41:59 vala-bootstrap is no more, just build vala-native Dec 30 13:58:44 freesmartphone.org: 03mickey 07cornucopia * r9665cf8bf218 10/ (TODO fsogsmd/src/lib/atparser.vala): fsogsmd: parser: yank banner idea; it's way better to treat such a thing as a regular URC Dec 30 13:59:06 freesmartphone.org: 03mickey 07cornucopia * r0cb0ed9e7b07 10/fsogsmd/src/plugins/modem_ti_calypso/plugin.vala: fsogsmd: ti_calypso: only open two channels for now Dec 30 13:59:43 mickeyl: uh, even more changes? scary :) Dec 30 14:00:21 hehe Dec 30 14:00:51 it's going to be a while until fsogsmd will be stable Dec 30 14:01:31 maybe i'll upgrade to it in 2012 :) Dec 30 14:01:39 yeah, by then it should be rock solid Dec 30 14:01:49 as a matter of fact, it works fine for singleline modems since a while though Dec 30 14:02:13 mickeyl: does it resend PIN regularly? ;) Dec 30 14:02:13 i don't fancy the TI Calypso integration, it works so nice for other modems... Dec 30 14:02:31 no housekeeping tasks until functionality is done Dec 30 14:02:38 does it autodetect when calypso crashes on heavy gprs use? ;) Dec 30 14:02:59 no, like i said, no calypso integration whatsoever yet. just started with that Dec 30 14:03:13 ok, all i have is calypso Dec 30 14:03:56 i know. ogsmd was started with the calypso in mind Dec 30 14:04:09 that's why some things are baaad Dec 30 14:04:14 now i'm going the other way round Dec 30 14:05:57 hmm, i need to have the EVB closer to me... it sucks that i have to manually reset it everytime i go out of MUX Dec 30 14:06:05 * mickeyl needs a remote control arm Dec 30 14:06:06 mickeyl: EVB? Dec 30 14:06:16 GT001 Calypso evaluation board Dec 30 14:06:26 mickeyl: what's that for? ;) Dec 30 14:06:29 that's what i'm working with atm. Dec 30 14:06:39 more convenient that to use the FR Dec 30 14:06:43 s/that/than/ Dec 30 14:06:44 mickeyl meant: more convenient than to use the FR Dec 30 14:06:48 mickeyl: can't you powercycle it easily anyway? Dec 30 14:07:14 by standing up from my chair, going over, pressing the reset button Dec 30 14:07:39 mickeyl: how about echo 0 > power_on in gta02? Dec 30 14:07:52 yes, that works on the device Dec 30 14:08:02 but as i've said, i'm using the EVB connected to my workstation now Dec 30 14:08:21 is it using the same firmware? Dec 30 14:08:28 yes, i flashed it yesterday Dec 30 14:09:11 moko11 now Dec 30 14:10:08 i had good results with serial forwarding the FR modem as well Dec 30 14:10:15 but the power cycling sucks a bit Dec 30 14:10:21 on both vairants Dec 30 14:11:48 I'm thinking of using the channels 2-4 round-robin in fsogsmd Dec 30 14:12:10 to improve throughput and hammer the modem more :D Dec 30 14:14:39 as for calypso crashes on heavy gprs use, i can't reproduce that any more with libgsm0710mux Dec 30 14:14:46 do you still see these? Dec 30 14:14:55 mickeyl: how long does it take for FR to wake up from suspend, check the current cell and go back to sleep? Dec 30 14:15:08 mickeyl: yes Dec 30 14:15:11 are you still on gsm0710muxd? Dec 30 14:15:14 yep Dec 30 14:15:15 that would explain Dec 30 14:15:32 it doesn't happen with our muxer Dec 30 14:15:39 mickeyl: i'm not so confident :) Dec 30 14:16:15 well, honoring flow control seems to improve things Dec 30 14:16:21 but I can on SHR Dec 30 14:16:31 mickeyl: if the issue is that the muxer can't read data fast enough from serial port then this can happen with any software since we have no hard realtime support Dec 30 14:16:42 (heavy gprs use -> crash) Dec 30 14:16:55 at least modem stops working Dec 30 14:17:00 no, the issue seemed to be feeding data to it when it is already fed up Dec 30 14:17:05 not the other way round Dec 30 14:17:07 but only when Im in bus Dec 30 14:17:20 (suspending, checking cell, resuming), it largely depends on kernel, of course, but worst case 2 seconds I'd say Dec 30 14:17:29 mickeyl: how many AT commands? Dec 30 14:17:34 25? Dec 30 14:17:48 2 Dec 30 14:18:02 or 3 Dec 30 14:18:17 we would not send anything but the cell queyr Dec 30 14:18:17 mickeyl: isn't ogsmd sending all kinds of "please now start to report unsolicted message X" commands on resume? Dec 30 14:18:30 right now, yes Dec 30 14:18:50 but of course we would not do this if we add the notion of silent resumes Dec 30 14:19:07 ok, afk. Dec 30 14:26:35 freesmartphone.org: 03mickey 07cornucopia * r7944b3eeb388 10/fsogsmd/src/plugins/lowlevel_openmoko/plugin.vala: fsogsmd: lowlevel_openmoko: give up opening the modem after 5 unsuccessful tries Dec 30 14:43:57 freesmartphone.org: 03mickey 07cornucopia * r6b5243604834 10/fsogsmd/src/plugins/lowlevel_openmoko/plugin.vala: fsogsmd: lowlevel_openmoko: destroy the interrim transport after lowlevel init done Dec 30 14:43:57 freesmartphone.org: 03mickey 07cornucopia * r3a017cd75609 10/fsogsmd/src/lib/atparser.vala: fsogsmd: parser: escape escape sequences Dec 30 14:43:57 freesmartphone.org: 03mickey 07cornucopia * r6a37422027c4 10/fsogsmd/src/plugins/modem_ti_calypso/commands.vala: fsogsmd: ti_calypso: fix regexp for %CSTAT Dec 30 15:04:27 wpwrak: ping? Dec 30 15:07:39 mickeyl: *yawn* Dec 30 15:07:52 wpwrak: good morning! out of curiousity, ever looked into how fluid actually updates the gsm firmware under the hood? like, is it sending AT commands or moving the modem into a special binary mode? Dec 30 15:08:26 it's some binary protocol. the boot loader runs before the at interpreter is started. Dec 30 15:09:01 ah, so it waits a tiny bit to check whether some strange commands are sent Dec 30 15:09:07 and if that doesn't happen, it falls into AT mode? Dec 30 15:09:44 yup. that is, i think the initial sequence is not a "normal" command block, but a pair of bytes or so Dec 30 15:10:06 if that arrives, we stay in the boot loader. if not, off to at land Dec 30 15:10:14 righto, interesting, thanks Dec 30 15:10:35 np :) Dec 30 15:14:09 There's also some interesting stuff like ROM and flash bootloader, probably those are activated in a slightly different way but i haven't checked. Dec 30 15:17:45 wpwrak: btw, i've another gsm-related question. Dec 30 15:20:21 if you hurry Dec 30 15:20:24 wpwrak: i've heard rumors that the usa can arbitrary shutdown any gsm network they want by sending some stuff from sattelites. Dec 30 15:21:07 like laser beams ... vaporizing the base stations ? Dec 30 15:21:10 a orbital laser ray ? Dec 30 15:21:33 or worst, a phone call with a lawyer ? Dec 30 15:21:47 wpwrak: like some secret codes making gsm equipment inoperable. Dec 30 15:22:09 wpwrak: or probably just some simple way to interfere enough to make network inoperable. Dec 30 15:22:27 goldeneye style, a emp ? Dec 30 15:23:09 misc: i'm serious. Dec 30 15:24:24 PaulFertser: well, EMP does exist http://en.wikipedia.org/wiki/Electromagnetic_pulse Dec 30 15:24:30 PaulFertser: well, your gsm phone doesn't necessarily have a satellite receiver. and base stations don't have to have one either Dec 30 15:25:02 PaulFertser: you can ask harald if he has found any sat receiver in the bs-11 (?) he collects Dec 30 15:25:36 wpwrak: what makes it impossible to emit something on the frequencies GSM equipment can receive? Dec 30 15:27:33 PaulFertser: nothing. but i don't think the antennas are really good for this Dec 30 15:27:55 gotta run Dec 30 16:05:18 opkg install http://www.aitel.hist.no/~helgehaf/openmoko/illume-keyboards-norwegian-no_0.1_all.ipk Dec 30 16:05:19 after running above command , should not layout be accessiable Dec 30 16:05:19 ? Dec 30 16:21:29 any opinion ? Dec 30 18:22:36 lol, alabd ran away again. :P Dec 30 19:20:11 freesmartphone.org: 03mickey 07libgsm0710mux * reab4ceed3cc2 10/gsm0710mux/ (manager.vala multiplexer.vala): Dec 30 19:20:11 freesmartphone.org: fsogsmd: add debug option that leaves mux mode alone to ease startup/shutdown during development. To Dec 30 19:20:11 freesmartphone.org: activate: Dec 30 19:20:11 freesmartphone.org: [session] Dec 30 19:20:12 freesmartphone.org: leave_mux_alone = 1 Dec 30 19:24:46 ** (process:15625): WARNING **: atparser.vala:183: Detected missing \r\n on start of line for incoming URC; ignoring v.250ter violation gracefully Dec 30 19:25:07 * mickeyl shakes head... i think we're too nice now ;) Dec 30 19:25:17 And polite Dec 30 19:25:22 hehe Dec 30 19:25:38 ah well, for those who read logs... they deserve it ;) Dec 30 19:35:36 hmm, that looks good Dec 30 19:36:36 random IRC poll... do you have a SIM PIN or not? Dec 30 19:36:52 yes Dec 30 19:36:55 not Dec 30 19:37:00 not Dec 30 19:37:03 no Dec 30 19:37:28 1:3 Dec 30 19:37:47 and lindi- is weird. Dec 30 19:37:49 :P Dec 30 19:37:50 hehe Dec 30 19:38:04 did all of you use some proprietary software to disable PIN? Dec 30 19:38:18 no, fso :) Dec 30 19:38:22 I used my friend's phone Dec 30 19:38:45 no Dec 30 19:38:48 lindi-, I just got it without pin. Dec 30 19:39:09 without a SIM PIN, the calypso reads the SIM phonebook and the SMS directory into its own RAM right from power up. I'm pretty confident that with a sane init system, we can get 30 seconds until first phone call Dec 30 19:39:16 perhaps less Dec 30 19:39:16 lindi-: same here, by default sims come without a pin Dec 30 19:39:35 mickeyl, sweet :) Dec 30 19:39:55 yeah, just need to prevent resetting when we say +CFUN=1 Dec 30 19:40:02 i guess that goes via the 2nd parameter Dec 30 19:40:07 * mickeyl tries Dec 30 19:41:54 atm cold boot to first call takes HOURS :P Dec 30 19:42:09 no sim pin Dec 30 19:42:23 mickeyl: in the US, nobody has a sim pin Dec 30 19:42:38 really? Dec 30 19:42:43 in europe it's pretty vice versa Dec 30 19:42:44 And nobody follows internation standard for phone numbers ;) Dec 30 19:42:50 or do you mean CDMA? Dec 30 19:42:54 :) Dec 30 19:42:56 mickeyl: no, I mean gsm Dec 30 19:43:02 k Dec 30 19:43:55 mickey|sofa: the US likes to do things differently. We like to play different sports than everybody else, measure everything differently, and to have different phone systems (cdma, different gsm frequency) Dec 30 19:43:57 mirko: sigh Dec 30 19:44:00 mickeyl, btw, same here. Dec 30 19:44:08 most of the people (israel) don't have sim pin. Dec 30 19:44:26 mickeyl: yes (PIN) Dec 30 19:44:38 budfive_: if only that were the worst things about the USA :( Dec 30 19:44:40 here in Poland almost all have PIN Dec 30 19:45:01 at least it was always enabled by default for every SIM card I have seen Dec 30 19:45:09 PaulFertser: :) Many good things about it too Dec 30 19:45:37 Sie sind nicht angemeldet. Das Produkt kann Ihnen nicht zugeordnet werden. Bitte loggen Sie sich ein. Hier gelangen Sie zum Login. Dec 30 19:45:41 budfive_: oh really? I thought any european country is better :| Dec 30 19:45:42 what does this translates to? :P Dec 30 19:46:19 I don't have an appropriate account to log in with? Dec 30 19:46:47 ok, interesting. i think the key is also to drive the calypso a bit differently. like, you should really leave it alone during this readying-phb-and-sms-into-sdram phase, blocking all commands until it's redy Dec 30 19:47:09 * mickeyl writes that to the TODO Dec 30 19:47:22 PaulFertser: I wake up in the morning and decide whether I want to surf or to ski that day. One could do worse Dec 30 19:48:13 btw. SIM *lways* comes with PIN. Just disabled by default in some countries. In .tw for example. DKAY told me "uh' here all PIN are 0000" :-D Dec 30 19:48:36 sure, i was abbreviating Dec 30 19:49:08 mickeyl: (leave alone) thought you're handling things like that Dec 30 19:49:51 also nota bene not all SIM have PIN-disabling enabled Dec 30 19:49:54 DocScrutinizer51: no, ogsmd does not do that Dec 30 19:50:06 fsogsmd will Dec 30 19:51:56 ok, when my new GSM antenna comes, i will do the PPP support Dec 30 19:51:57 budfive_: i would like to visit the states one day too see it all myself. I'm not sure i'll do that before they will cancel the mandatory fingerprinting of all the foreigners or introduce that for every citizen. Dec 30 19:52:03 mickeyl: where's your '|flu' gone? Dec 30 19:52:12 DocScrutinizer51: almost gone Dec 30 19:52:16 feeling much better Dec 30 19:52:23 nice Dec 30 19:52:43 new gsm antenna? Dec 30 19:53:09 ya, need one for the GT001 Dec 30 19:53:15 otherwise receiption is almost non-existing Dec 30 19:53:24 they didn't wire an antenna Dec 30 19:53:33 but it almost works without one Dec 30 19:53:40 mickeyl: tried a random wire? Dec 30 19:53:48 It worked here that way Dec 30 19:53:48 i'm not much into soldering... Dec 30 19:53:54 mickeyl: now with FSO's constant messing of gsm antenna with gsm modem you now reached the point of total confusion for guys like me Dec 30 19:54:12 hehehe Dec 30 19:54:23 * mickeyl hugs org.freesmartphone.GSM.Device.SetFunctionality() Dec 30 19:54:49 look here: Dec 30 19:54:51 >>> gsmdevice.SetAntennaPower(True) Dec 30 19:54:51 Traceback (most recent call last): Dec 30 19:54:51 File "", line 1, in Dec 30 19:54:51 File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__ Dec 30 19:54:51 **keywords) Dec 30 19:54:54 File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in call_blocking Dec 30 19:54:56 message, timeout) Dec 30 19:54:58 DBusException: org.freesmartphone.Unsupported: Please use org.freesmartphone.GSM.Device.SetFunctionality instead. Dec 30 19:54:59 * DocScrutinizer51 gives a kick on top of the hug. For free Dec 30 19:55:01 >>> Dec 30 19:55:03 :) Dec 30 19:56:01 mickeyl: i had a gsm unit here and it didn't work without antenna too. I just took some random small wire or regular staple, pushed it a bit in the connector and got enough reception. Dec 30 19:56:46 yep Dec 30 19:56:51 usuall Dec 30 19:56:54 PaulFertser: right, might as well try that, but until now i didn't need to register; moving in and out of MUX and reading SIM and PHB was enough for testing. Besides, it's already ordered :) Dec 30 19:57:45 mickeyl: btw, it's awesome you still work on that and that you're constantly moving forward. If only more targets appeared... Dec 30 19:57:49 mickeyl: what was that strange paste above? Dec 30 19:58:30 dbus command and response Dec 30 19:58:43 didn't you read the python dbus tutorial yet? you should've understood the traceback then ;): Dec 30 19:59:04 org.freesmartphone.GSM.Device.SetAntennaPower() raises an exception now Dec 30 19:59:15 aah Dec 30 19:59:16 that tells you to use something else Dec 30 19:59:36 (staple) that was a paper clip in fact Dec 30 19:59:54 so you think I should read all those facts from that few lines of backtrace? lol Dec 30 20:00:04 DocScrutinizer51: sure, that's obvious ;) Dec 30 20:00:55 you ever googled for SetAntennaPower? Dec 30 20:02:31 http://marcboon.com/rfiduino/code/SM130/classSM130.html#4d80dc09c7c48b09bf4ccd9a5fcc0067 Dec 30 20:02:35 not FSO :D Dec 30 20:02:45 * DocScrutinizer51 waves and curses his flu. Should send it to mickey's to learn to behave Dec 30 20:02:57 get well soon Dec 30 20:03:07 * mickeyl drops out of coding for today Dec 30 20:04:18 budfive_: ? Dec 30 20:04:37 not even drink up my coffee. Eeew that's a bad sign Dec 30 20:04:55 mirko: ? Dec 30 20:05:49 budfive_: you highlighted me Dec 30 20:06:38 mirko: oh yeah, oops. mistake. sorry. Dec 30 20:10:14 freesmartphone.org: 03mickey 07cornucopia * rf3b544f0b03a 10/fsogsmd/src/plugins/ (2 files in 2 dirs): Dec 30 20:10:14 freesmartphone.org: fsogsmd: ti_calypso: show number of channels currently open in repr() Dec 30 20:10:14 freesmartphone.org: same for cinterion mc75 Dec 30 20:30:47 budfive_: ah, ok Dec 30 23:00:04 my moko wouldnt awake from suspend :( Dec 30 23:16:04 Hardy_: there's a bug reported on trac, gstatus4 is the last thing seen in the resume kernel log. Dec 30 23:21:44 PaulFertser: is that actually something that is printed during resume? Dec 30 23:22:58 PaulFertser: (just that you shouldn't call it resume log since it is actually a message printed when the kernel goes to suspend) Dec 30 23:26:10 hi,on top-left of the pcb near aux button like in http://wiki.openmoko.org/wiki/Image:Gta01b_v3_case_top_open_pcb_lift_white.jpg is there something soldered on gta02? Dec 30 23:26:38 becuase my aux button is broken Dec 30 23:27:35 ah yes found it Dec 30 23:28:20 is there a method to resolder it? Dec 30 23:28:26 because it's unsoldered Dec 30 23:42:52 ah thnx PaulFertser Dec 31 00:34:03 done but it's a little bit too much on the right **** ENDING LOGGING AT Thu Dec 31 02:59:57 2009