**** BEGIN LOGGING AT Mon Jun 27 02:59:57 2011 Jun 27 05:35:29 ~moo Jun 27 05:35:29 * apt mooooooooo! I am cow, hear me moo, I weigh twice as much as you. I am cow, eating grass, methane gas comes out my ass Jun 27 05:53:38 GNUtoo|laptop: yo, was asleep Jun 27 05:53:46 and moin Jun 27 07:16:31 moin GNUtoo|laptop Jun 27 07:17:43 hi Jun 27 07:17:59 I'll push something and I'll be available for talking right after pushing Jun 27 07:20:11 ok Jun 27 07:24:53 freesmartphone.org: 03GNUtoo 07cornucopia * rc0f5e13caa40 10/fsousaged/src/plugins/lowlevel_android/plugin.vala: Jun 27 07:24:53 freesmartphone.org: fsousaged: lowlevel_android plugin: Whitespace and cleanup fix Jun 27 07:24:53 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 27 07:24:54 freesmartphone.org: 03GNUtoo 07cornucopia * r4ec5ef5b96cb 10/fsousaged/src/plugins/lowlevel_android/plugin.vala: Jun 27 07:24:54 freesmartphone.org: fsousaged: lowlevel_android plugin: add support for userspace screen resume Jun 27 07:24:54 freesmartphone.org: Add that in the [fsousage.lowlevel_android] fsousaged configuration section to activate it: Jun 27 07:24:54 freesmartphone.org: screen_resume_type = userspace Jun 27 07:24:54 freesmartphone.org: screen_resume_command = chvt 1;chvt 2 Jun 27 07:24:55 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 27 07:28:07 mrmoku, hi Jun 27 07:33:44 freesmartphone.org: 03GNUtoo 07cornucopia * r1ca7deba8382 10/fsousaged/conf/nexusone/fsousaged.conf: Jun 27 07:33:44 freesmartphone.org: nexusone's fsousaged.conf: add userspace screen resume config Jun 27 07:33:44 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 27 07:33:58 GNUtoo|laptop: give me ten mins to get myself a nice capuccino and then I'm almost all yours :) Jun 27 07:34:09 ok Jun 27 07:48:01 freesmartphone.org: 03GNUtoo 07cornucopia * r8f1107c4beb8 10/fsousaged/conf/nexusone/fsousaged.conf: Jun 27 07:48:01 freesmartphone.org: fsousaged: nexusone's config: activate suspend(remove debug_do_not_suspend) Jun 27 07:48:01 freesmartphone.org: Now that we have implemented the screen userspace resume, we can suspend/resume. Jun 27 07:48:01 freesmartphone.org: Signed-off-by: Denis 'GNUtoo' Carikli Jun 27 08:00:02 GNUtoo|laptop: ok, back Jun 27 08:05:39 mrmoku, where were you left with the better sound routing plugin? Jun 27 08:05:54 mrmoku: \o/ wb Jun 27 08:06:56 welcome back indeed Jun 27 08:07:10 DocScrutinizer, any idea about the n900 call plugin problems? Jun 27 08:07:14 hi btw Jun 27 08:07:29 problem? Jun 27 08:08:41 yes it works very badly Jun 27 08:09:04 as I said before the sound quality is worse than the one without the temporary buffers and the threads Jun 27 08:09:05 code review pending Jun 27 08:09:08 ok Jun 27 08:09:09 thanks Jun 27 08:09:12 I'll wait Jun 27 08:09:16 DocScrutinizer: thx Jun 27 08:09:56 GNUtoo|laptop: don't remember and did not try much yet Jun 27 08:10:31 GNUtoo|laptop: I remember you suspected your landline phone to be part of the problem? Jun 27 08:10:35 maybe that's the thing to finish before finishing modem Jun 27 08:10:40 mrmoku, ah that Jun 27 08:11:01 mrmoku, I thought you were talking about your audio routing work Jun 27 08:11:05 about my work: Jun 27 08:11:20 I made a plugin that works a lot better that is checked in Jun 27 08:11:31 but then DocScrutinizer told me how to do it even better Jun 27 08:11:38 to get a decent sound Jun 27 08:11:42 like a normal phone Jun 27 08:11:54 but that didn't work well because I surely made some errors Jun 27 08:12:00 ok Jun 27 08:12:14 and that is pushed in a branch Jun 27 08:12:20 not in master Jun 27 08:12:22 so first thing would be DocScrutinizer and me taking a look at the code? Jun 27 08:12:59 mrmoku: 2 ringbuffers, one for cmt->alsa and one for alsa->cmt. Normal FIFO Jun 27 08:13:17 http://git.freesmartphone.org/?p=cornucopia.git;a=blob;f=fsoaudiod/src/plugins/gsmvoice_alsa_cmtspeechdata/cmthandler.vala;h=052345501928e661ee933d827e782db531307269;hb=7644e4111d1770cb38b8853df3b13ede67851239 Jun 27 08:15:34 mrmoku: aiui GNUtoo|laptop is using a blocking writei() and readi() as ther vala bindings don't provide the callback way, and I suspect issues Jun 27 08:16:30 you have 2 virually separate programs, one for cmt->alsa and one in opposite direction Jun 27 08:16:58 I'm referring to one of those now... alsa->cmt Jun 27 08:17:08 it's for mic obviously Jun 27 08:18:49 GNUtoo|laptop: and that works just sound quality is bad, right= Jun 27 08:18:50 ? Jun 27 08:19:24 as soon as alsa buffer got filled, blocking readi() will return with a chunk of 160(?) frames, and the "input" process to FIFO will have to see if FIFO has enough free space (check distance writepointer to readpointer ahead), then move the chunk to FIFO and adjust writepointer Jun 27 08:19:33 mrmoku, yes Jun 27 08:20:32 if you find there's not enough free space in FIFO, this means your "output" side of FIFO which is the cmt end, is too slow. You have to handle this xrun in a smart way Jun 27 08:21:08 the easiest smart way is a do-nothing which just drops the data chunk from alsa readi() Jun 27 08:21:48 now for the "output" end of the queue, the FIFO->cmt process: Jun 27 08:22:20 it needs to block on cmt-write, or use callback, or whatever Jun 27 08:23:00 when it gets started aka blocking call cmtwrite() returns, this code has to do: Jun 27 08:23:41 check if there's enough data in FIFO for a new chunk to transfer to cmt-write - whatever the size of that chink is defined Jun 27 08:24:01 for this check distance from readpointer to writepointer ahead Jun 27 08:24:35 if there's enough ddata, transfer it and done, you're blocking again on cmt-write() Jun 27 08:25:18 if there's NOT enough data in FIFO, you have xrun situation - alsa capture is too slow for cmt. You need to handle in a smart way Jun 27 08:26:01 ok, I have to build that thing and try it Jun 27 08:26:04 most easy smart way is to re-use same chunk of data again that you already wrote to cmt-write() on last turn Jun 27 08:27:28 on both xrun events (overrun on alsa input side, underrun on cmt output side) you should do some diagnostic logging, so we can see what's going on Jun 27 08:27:58 mrmoku: you're following? Jun 27 08:28:35 I'm mostly following Jun 27 08:28:40 apart that: Jun 27 08:28:43 good :-) Jun 27 08:29:02 "check distance writepointer to readpointer ahead" Jun 27 08:29:09 what's the code equivalent Jun 27 08:29:11 ? Jun 27 08:29:51 readptr - writeptr > (FCOUNT * 2) ? Jun 27 08:29:56 that's what you have now Jun 27 08:30:19 it's usually sth like "distance=readpointer -writepointer" Jun 27 08:30:24 ok Jun 27 08:30:49 GNUtoo|laptop: gsmvoice_asa_cmtspeechdata+buffer_threads is the one Jun 27 08:30:50 ? Jun 27 08:30:51 but it's more complex as you need to handle wraparounds at FIFO borders Jun 27 08:31:04 yes I handled that Jun 27 08:31:08 if I remember well Jun 27 08:31:48 ok so the distance is mostly what I do Jun 27 08:32:04 I wans't sure on the code translation but I suposed it was that Jun 27 08:32:08 better beeing sure Jun 27 08:32:35 given your readpointer never can run over the readpointer, nor other way round, you usually just add sizeof(FIFO) if the equation has a negative result Jun 27 08:34:03 you usually just add sizeof(FIFO) if the equation has a negative result means: Jun 27 08:34:04 you substract sizeof(FIFO) if any pointer is > FIFO size Jun 27 08:34:08 ok Jun 27 08:34:21 yes that's what I do Jun 27 08:34:28 I substract 480 if I remember well Jun 27 08:35:27 if this basic concept works fine, you can start adding more nifty ways to tune speeds between input and output Jun 27 08:35:43 yes that's my problem I guess because Jun 27 08:35:51 when I create some buffer underruns Jun 27 08:35:55 sometimes it ajjust the speed Jun 27 08:36:00 and the sound becomed perfect Jun 27 08:36:12 like dropping/dupplicating one frame / N frames, where N gets adjusted for every xrun you encounter Jun 27 08:36:50 ah maybe I found an error Jun 27 08:36:51 480 Jun 27 08:36:56 it must be 960 Jun 27 08:36:56 NB you *never* should run into genric ALSA or cmt xruns Jun 27 08:37:00 480 is in frames Jun 27 08:37:38 and we're in bytes here Jun 27 08:37:38 as those would mean your code hasn't been keeping up with servicing the write() and read() calls Jun 27 08:37:55 that's something you must avoid by all means Jun 27 08:38:04 ok Jun 27 08:39:03 xruns are a "normal" situation in your code, when the equation writeptr-readptr (or other way round) is indicationg a speed missmatch Jun 27 08:39:32 the cmt and alsa framework should NEVER have an xrun condition Jun 27 08:40:23 hmmm Jun 27 08:40:29 indeed there are a lot of xruns Jun 27 08:40:37 if they do, it means you need to prioritize (renice) your code, so the "callbacks" (or returns from blocking writei() etc) get serviced in time Jun 27 08:40:52 ok I'll try that Jun 27 08:42:02 recovering from an ALSA xrun is a heavy and awkward process, that should get avoided. IMO Jun 27 08:42:40 also ALSA xruns generally tend to really ruin your audio Jun 27 08:42:49 yes Jun 27 08:42:51 it does Jun 27 08:42:59 as ALSA has no means to handle them in a nice way Jun 27 08:43:32 anyway we're realtime in the network sense(like udp) Jun 27 08:43:39 so it makes sense to drop the frames Jun 27 08:43:54 ls Jun 27 08:43:55 oops Jun 27 08:44:12 yes, but do that in your code, not let ALSA or cmt do it on a buffer xrun Jun 27 08:44:20 ok Jun 27 08:55:04 DocScrutinizer, I tried -20 and I've still buffer underruns Jun 27 08:55:11 and I corrected 480->960 Jun 27 08:55:36 then maybe your threads block each other, or sth Jun 27 08:55:54 I'll try desactivating a thread Jun 27 08:55:59 I always had that problem Jun 27 08:56:06 disabling record Jun 27 08:56:14 gave a better playback sound Jun 27 08:56:18 let me re-disable record Jun 27 08:56:55 you must have 4 threads: ALSA->FIFO1, FIFO1->cmt, cmt->FIFO2, FIFO2->ALSA Jun 27 08:57:10 ahhh Jun 27 08:57:27 so memcpy is an operation that costs a lot? Jun 27 08:57:38 usually not Jun 27 08:57:46 then I need only 2 threads Jun 27 08:58:06 Memory.copy == memcpy Jun 27 08:58:12 your CPU usually can memcpy several MB/s Jun 27 08:58:40 GNUtoo|laptop: nope, with 2 threads all the concept does not work Jun 27 08:58:52 ah? Jun 27 08:59:02 and obviously inevitably will run into xruns Jun 27 08:59:18 maybe that's the issue then Jun 27 08:59:35 could you explain more why the concept fails with only 2 threads? Jun 27 08:59:57 nope, as I can't even see how to implement it with 2 threads Jun 27 09:00:09 how can I do 4 threads Jun 27 09:00:16 I'll look Jun 27 09:00:35 I explained in epic length above about the 2 threads for alsa->FIFO->cmt Jun 27 09:00:49 you need another 2 threads for the opposite direction Jun 27 09:01:02 I need to put the memcpy in threads Jun 27 09:01:05 I'll look Jun 27 09:04:46 you got 4 blocking calls: pcm_writei(), pcm_readi(), cmt_write(), cmt_read(). Each of those is the ONLY blocking call of one thread Jun 27 09:05:18 ah ok Jun 27 09:05:22 cmt_read and cmt_write Jun 27 09:05:23 ok Jun 27 09:05:27 now I understand Jun 27 09:11:30 NB I never looked int cmtspeechtest code or anything about cmt at large. So all that I say is based on general considerations, assuming cmt hardware is built and working in a "normal" way Jun 27 09:12:16 if there are no blocking cmt_write() / cmt_read() calls, then my concept is wrong and I have to learn more about cmt and how it works Jun 27 09:12:36 ok Jun 27 09:12:55 maybe I could do that: Jun 27 09:13:15 some time ago with the old code....recording inflluenced playback quality Jun 27 09:13:20 so maybe I fix playback alone Jun 27 09:13:24 and then thread it better Jun 27 09:14:02 sure, playback and record should be completely unrelated. could as well be two separate programs Jun 27 09:15:25 again, unless cmt does some nasty interleave between playback and record data that would connect the blocking of both the cmt_write() and cmt_read() call Jun 27 09:15:54 please point me to the way how you write data to cmt Jun 27 09:16:35 I've no idea on how it works, since I use a library Jun 27 09:16:40 but I know it's mmaped memory Jun 27 09:16:56 point me to that lib's code then Jun 27 09:17:05 ok, luckly it's in C Jun 27 09:17:12 to the API specs, whatever Jun 27 09:17:25 ok let me find it Jun 27 09:18:34 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech_nokiamodem.c Jun 27 09:19:11 and indeed it is blocking Jun 27 09:19:14 if it was async Jun 27 09:19:20 the API would look different Jun 27 09:40:16 I'm at line ~680 now ans so far seems it's a "simple" interface, yes Jun 27 09:41:11 after some fixes, it sounds a bit better Jun 27 09:41:15 but still underruns Jun 27 09:50:32 hah, nice interesting functions (though unrelated to our audio problem): http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line359 Jun 27 09:53:41 AHAAA -> http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line398 Jun 27 09:54:26 so I cannot use threads for that? Jun 27 09:54:36 (for the aquire)) Jun 27 10:01:29 it seem to work better with snd_pcm_recover than with snd_pcm_prepare Jun 27 10:01:30 strange Jun 27 11:02:19 I doubt experimental approach will yield good results in a finite timespan Jun 27 11:13:13 so what should I do? Jun 27 11:15:51 see how cmtspeechtest is using the API aka lib interface. Jun 27 11:16:24 btw there's a bug it seems: http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line481 has a dup in http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line489 Jun 27 11:19:42 obviously the cmtdata API must have some way to release a buffer with new data: http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line431 -- either this call is blocking, or there has to be a way the lib signals user-app about the fact this call can and shall get used *now* to receive next chunk of inbound audio data Jun 27 11:21:10 I don't think you have to poll this call to detect when it actually has valid new data and signals this by an according set of flags Jun 27 11:21:15 that'd be insane Jun 27 11:23:08 after you got a chunk of data from 431 int cmtspeech_dl_buffer_acquire(cmtspeech_t *context, cmtspeech_buffer_t **buf); Jun 27 11:24:06 ...you copy the data to FIFO, and immediately return / release the buffer to the lib for recycling: 443 int cmtspeech_dl_buffer_release(cmtspeech_t *context, cmtspeech_buffer_t *buf); Jun 27 11:24:21 so much for getting audio *from* modem Jun 27 11:25:54 . Jun 27 11:27:46 for upstream data sent to network from microphone you acquire a buffer slot ( http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line395 ), fill it with data from FIFO, and release (http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line415) it to the modem. Jun 27 11:28:16 I'm just unclear where's the timing from for this, as I think modem should provide clock source Jun 27 11:28:30 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line400 Jun 27 11:28:52 . Jun 27 11:29:15 cmtspeechtest.c (or whatever the name) should have example how to properly do that Jun 27 11:33:25 some recommended reads: Jun 27 11:33:28 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/doc/README-devel.txt Jun 27 11:35:39 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/raw/master/doc/libcmtspeechdata_api_docs_main.txt hmmm, wonder how to properly display it rendered raher than raw Jun 27 11:50:41 mmmpff, where's he gone? Jun 27 11:51:36 please pojnt him to chanlog when he's back - here comes how to properly handle DownLoad: Jun 27 11:53:45 >>Once library instance is open, application should monitor for possible events by polling (with e.g. poll() or select()) the file descriptor returned by cmtspeech_descriptor(). If the descriptor becomes readable, application should immediately call cmtspeech_check_pending(). Jun 27 11:54:34 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line245 Jun 27 11:55:14 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line89 #define CMTSPEECH_EVENT_DL_DATA (1 << 1) /**< DL frame available */ Jun 27 11:56:10 ---> get frame http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line431 int cmtspeech_dl_buffer_acquire(cmtspeech_t *context, cmtspeech_buffer_t **buf); Jun 27 11:56:37 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/cmtspeech.h#line443 int cmtspeech_dl_buffer_release(cmtspeech_t *context, cmtspeech_buffer_t *buf); Jun 27 12:06:46 . Jun 27 12:06:51 HAH! http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/doc/libcmtspeechdata_api_docs_main.txt#line257 Jun 27 12:08:10 obviously for uplink the timing source is NOT the modem, so there's no event telling "please send next data chunk of audio". Rather this is based on a timer in APE land, and modem can request to adjust the parameters of this timer any time Jun 27 12:08:49 so blocking call of FIFO2->cmt thread obviously is a timer() call Jun 27 12:09:57 . Jun 27 12:11:19 anyway most of this should be implemented in that ofono_cmtspeechdata_test program, maybe minus the timing-adjustment handling Jun 27 12:19:29 >>NOTE: Unlike uplink frames, which are sent all the time during a call, there can be gaps in the stream of downlink data frames. This can happen e.g. at start of the call before call is connected and during call hold. It is important that the application's playout mechanism can handle this case. Jun 27 12:19:42 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/doc/libcmtspeechdata_api_docs_main.txt#line317 Jun 27 12:20:56 "handle this case" means you mustn't get upset about underruns on cmt->alsa Jun 27 12:21:07 rather output silence in that case Jun 27 12:24:01 . Jun 27 12:24:53 >>Once a call is established, the only libcmtspeechdata activity that needs to be triggered by the application (e.g. based on audio hardware interrupts, or using a system timer to wake up), is sending of uplink speech frames. The frames need to be sent according to the timing information provided by CMT. All other actions are triggered by either inbound events from the CMT, or by call signaling related DBus events. Jun 27 12:25:05 http://meego.gitorious.org/meego-cellular/libcmtspeechdata/blobs/master/doc/libcmtspeechdata_api_docs_main.txt#line351 Jun 27 12:25:50 we want opt for "...or using a system timer to wake up" as we might use other than ALSA hw for input of audio to cmt Jun 27 12:26:32 so this is exactly the timer() wait of the FIFO->cmt_write() thread mentioned above by me Jun 27 12:27:25 darn, I doubt there's ever been a more detailed spec on how to code something in IT history than what I just posted ;-P Jun 27 12:27:50 so, time for some RL Jun 27 12:27:51 . Jun 27 12:27:53 . Jun 27 12:28:18 .please point gnutoo to chanlog as soon as he rejoins here Jun 27 12:30:59 nslu-logs are so fubar butt-ugly and clumsy Jun 27 12:31:03 :-( Jun 27 12:31:33 could use some love by mgedmin Jun 27 12:37:45 *nod* will point him to that. i think that we are pretty much exactly doing that though Jun 27 12:38:05 :nod: Jun 27 12:38:24 whatever, I hope it's quite clear now Jun 27 12:44:04 heyho Jun 27 12:59:09 * DocScrutinizer wonders if mgedmin still is hosting a chanlog for here on his own server Jun 27 12:59:33 can't recall what's been the name of his logbot Jun 27 13:00:05 nrirclog: status Jun 27 13:00:10 nrirclog: help Jun 27 13:00:15 nrirclog: info Jun 27 13:00:22 nrirclog: ? Jun 27 13:30:38 sorry, I'm back Jun 27 13:39:36 Hey GNUtoo Jun 27 13:40:03 that fix didn't work... :( Jun 27 13:40:10 ok Jun 27 13:40:13 complain to morphis Jun 27 13:40:21 I cannot know everything :) Jun 27 13:42:37 ok,thank you! Jun 27 13:42:56 morphis: ping Jun 27 13:45:30 GNUtoo: DocScrutinizer posted a lot of stuff, please check backlog Jun 27 13:45:54 mickey|office, ok thanks Jun 27 13:49:19 angelox|pc: pong Jun 27 13:50:16 morphis: Hi! Did you get this sometime when using fso's OE to build aurora/shr? http://pastebin.com/D0M1G3Y8 Jun 27 13:51:58 angelox|pc: check our local.conf for ENABLE_BINARY_LOCALE_GENERATION Jun 27 13:52:40 should i change to 1 ? Jun 27 13:53:17 is it set to 0? Jun 27 13:53:27 yes... Jun 27 13:54:10 btw,i couldn't use your env that you gave me some days ago,i didn't understood what scripts should i set,run,etc...sorry! Jun 27 13:58:45 DocScrutinizer, mickey|daddy I read the log Jun 27 13:59:09 you keep talking about buffer->cmt Jun 27 13:59:59 but I wanted to handle first the issue that the sound quality outputed on my headphones/speakers is bad Jun 27 14:00:05 it's easier and faster to test Jun 27 14:18:49 morphis: ? Jun 27 14:30:00 angelox|pc: sorry, I was a little bit busy with other things Jun 27 14:30:25 angelox|pc: for my build env it's simple Jun 27 14:31:04 just execute . ./setup-env Jun 27 14:31:11 then you are ready for using bitbake Jun 27 14:31:19 it's the same as you would build shr Jun 27 14:31:25 iirc it asks me about a topdir.conf... Jun 27 14:31:26 with the shr-makefile Jun 27 14:31:48 hm ok Jun 27 14:32:02 then create a conf/topdir.conf with the content TOPDIR='YOURBUILDIR' Jun 27 14:32:43 hmm ok,thank you i'll try it now,and btw,sorry disturb you... Jun 27 14:33:29 no problem :) Jun 27 15:57:15 morphis: is it my impression or it is cloning from git.openembedded.org instead git.freesmartphone.org/openembedded (i mean,with your build env)? Jun 27 15:58:03 hm, yes it's using git://git.openembedded.org/openembedded Jun 27 15:58:11 but should be no problem Jun 27 15:58:18 as the fso git as new remote in the repository Jun 27 15:58:21 and fetch from it Jun 27 15:58:29 then checkout the aurora/development branch Jun 27 15:58:56 ok,thank you! Jun 27 16:01:48 should i do so "git checkout aurora/development" inside openembedded directory? it isn't working..or i understood wrong (bad English understanding here,sorry) Jun 27 16:04:31 do a: git remote add fso git://git.freesmartphone.org/openembedded.git Jun 27 16:04:35 then: git fetch fso Jun 27 16:04:44 and then: git checkout -b aurora/development Jun 27 16:06:41 ok,thank you! and sorry newbie-git question! Jun 27 16:20:04 Fucking shit, we've spent several days at work trying to make an SDRAM module on our board work, found an epic pin numbering mistake but fixing it didn't make it fully work. And now i've finally downloaded an errata for the SoC (imx.25) and guess what, it's incompatible with this kind of memory :-E fucking freescale. Jun 27 16:37:07 how to read a buffer from a file in vala? Jun 27 16:37:11 why is it so hard Jun 27 16:37:21 ? Jun 27 16:37:49 basically put a small file in a buffer Jun 27 16:37:50 I Jun 27 16:37:56 I'm doing that: Jun 27 16:38:30 ssize_t count = Posix.read( fd, buffer, 27612 ); Jun 27 16:38:37 and printing the buffer like this: Jun 27 16:38:45 stdout.printf("%s\n",((string)buffer).strip()); Jun 27 16:38:58 it prints only the beginning of the buffer Jun 27 16:52:46 GNUtoo: %s is for NUL terminated strings Jun 27 17:04:14 ok Jun 27 17:04:22 I feared that Jun 27 17:04:28 so there is some null here Jun 27 17:04:34 bbl Jun 27 17:11:59 lindi-_: hey, ready for a little qi chat? Jun 27 17:35:42 PaulFertser: maybe Jun 27 17:47:54 lindi-_: have you seen my previous messages? Jun 27 18:08:45 got it, it's vala structs that are not C structs Jun 27 18:08:55 I'll see what they say on #vala Jun 27 18:13:10 PaulFertser: no :) Jun 27 18:13:26 PaulFertser: how many of them? ;) Jun 27 18:14:09 PaulFertser: and hmm, should buy some food now before it's too late :) Jun 27 18:14:18 lindi-_: i suggest http://paste.debian.net/120917/ (or even puts("\n"); for the first hunk) Jun 27 18:14:49 lindi-_: as to the "Starting" problem, i guess it's because Qi doesn't flush TX buffer before starting the kernel and your kernel on the second partition has early_printk (wild guess). Jun 27 18:16:15 PaulFertser: I'm booting the same kernel Jun 27 18:16:55 but yes, sorry, will be away for 30 mins or so Jun 27 18:17:13 lindi-_: np Jun 27 18:44:39 so my Palm Pre is reassembled, but I lost three keys .... Jun 27 18:47:57 lost..like they're broken,or you did lost the buttons? :) Jun 27 18:54:18 does someone knows well the ioctls Jun 27 18:54:24 I tried to do an ioctl with mioctl Jun 27 18:54:26 and I failed Jun 27 18:54:34 I did that: Jun 27 18:54:42 strace mioctl /dev/audience_a1026 0x40087501 0 2>&1 | grep ioctl Jun 27 18:54:47 and it gave me that: Jun 27 18:54:52 ioctl(3, SMB_IOC_GETMOUNTUID, 0) = -1 EINVAL (Invalid argument) Jun 27 18:55:20 0x40087501 is #define A1026_BOOTUP_INIT _IOW(A1026_IOCTL_MAGIC, 0x01, struct a1026img *) Jun 27 18:55:49 with #define A1026_IOCTL_MAGIC 'u' Jun 27 18:55:54 it's the 2.6.37 Jun 27 18:59:26 angelox|laptop: like they are broken :) Jun 27 19:00:19 * GNUtoo is good at hardware disassembling and morphis is good at software disassembling Jun 27 19:00:20 GNUtoo: did you compute the number by inserting it into a C program and checking the output? Jun 27 19:00:26 yes Jun 27 19:00:30 good Jun 27 19:00:31 GNUtoo: :) Jun 27 19:00:32 usually I do it by hand Jun 27 19:00:38 but here I wanted to be sure Jun 27 19:00:54 GNUtoo: disassembling is not the problem, assembling the pre is more Jun 27 19:00:57 it's not that easy Jun 27 19:00:57 the argument is a struct, is it? Jun 27 19:01:03 mickey|daddy, yes it is Jun 27 19:01:03 you can't give structs via mioctl Jun 27 19:01:08 I know Jun 27 19:01:10 how should that work? :) Jun 27 19:01:20 basically by telling me the command is ok Jun 27 19:01:31 and not returning EINVAL Jun 27 19:01:34 but failing later Jun 27 19:01:43 I tried ioctls in vala Jun 27 19:01:50 I tought to do a quick thing Jun 27 19:01:53 but what if '2' is an invalid value? Jun 27 19:02:01 what do you expect other than -EINVAL? Jun 27 19:02:04 and I'm there since when I stopped working on alsa Jun 27 19:02:10 0 Jun 27 19:02:45 there is no 2 Jun 27 19:02:48 2 is the fd Jun 27 19:02:52 oops, right Jun 27 19:02:56 stderr > stdout Jun 27 19:02:56 so '0' is the argument Jun 27 19:02:58 there is 0 Jun 27 19:03:00 yes Jun 27 19:03:10 is the ioctl allowed to give a 'null' structure pointer? Jun 27 19:03:11 cryptic Jun 27 19:03:12 the source of the kenrel is here: Jun 27 19:05:07 https://gitorious.org/htc-msm-2-6-32/leviathan-incoming/blobs/nexusone/drivers/misc/a1026.c Jun 27 19:05:46 case A1026_BOOTUP_INIT Jun 27 19:06:01 I tried in vala before Jun 27 19:06:28 PaulFertser: back Jun 27 19:06:33 how did you try? can you pastebin the codeß Jun 27 19:06:42 yes Jun 27 19:07:00 PaulFertser: back Jun 27 19:07:04 lindi-_: yo Jun 27 19:07:07 PaulFertser: and yes, http://paste.debian.net/120917/ makes sense Jun 27 19:07:35 http://pastie.org/2130511 Jun 27 19:07:48 I think that I'll change the license to match fso Jun 27 19:08:01 since I took only from the android headers Jun 27 19:08:05 I guess that's permited Jun 27 19:08:25 the important part is here: Jun 27 19:08:44 private static void init_mic() Jun 27 19:11:14 ok, so based on the assumption that the ioctl is well formed Jun 27 19:11:27 the only path that gives back -EINVAL is #169 Jun 27 19:11:46 do you see the pr_err in dmesg? Jun 27 19:12:10 I'll look Jun 27 19:12:50 I don't Jun 27 19:12:54 I guess it's malformed then Jun 27 19:13:05 hmm Jun 27 19:13:12 but the invalid size is very plausible Jun 27 19:13:27 * angelox|laptop loves ERROR 404: Not Found. when OE fetches something :\ Jun 27 19:13:56 * GNUtoo will add more prints Jun 27 19:13:58 i'd add some printk and recompile the module Jun 27 19:14:01 heh, right Jun 27 19:14:04 best way Jun 27 19:14:15 thanks so much Jun 27 19:14:16 or do we have a kernel debugger these days? Jun 27 19:14:24 there are some Jun 27 19:14:32 some which work without jtag? Jun 27 19:14:32 but here it's tricky Jun 27 19:14:41 yes, function tracer Jun 27 19:14:57 cool, i'm completely out of the loop wrt that Jun 27 19:15:06 kgdb is out because it requires serial Jun 27 19:15:12 I'll add some printk Jun 27 19:15:14 it's easier Jun 27 19:17:19 GNUtoo: systemtap? Jun 27 19:17:34 a lot more flexible than function tracer Jun 27 19:17:52 ok Jun 27 19:17:55 needs patches? Jun 27 19:18:15 [18387.270660] a1026_ioctl: invalid command 1 Jun 27 19:18:17 anyway Jun 27 19:18:22 that's clearly in default Jun 27 19:18:36 GNUtoo: it's been in mainline for a while Jun 27 19:18:41 pr_err("%s: invalid command %d\n", __func__, _IOC_NR(cmd)); Jun 27 19:18:42 ok Jun 27 19:19:11 mickey|daddy: hey... how's the young family :) Jun 27 19:20:14 mrmoku: hi! exhausting, but ok. little one has problems with flatulences and sleeping long, but i'm afraid that's very common. Jun 27 19:21:21 the times when she doesn't scream, she's an angel Jun 27 19:21:26 but she has a _very_ loud voice Jun 27 19:21:32 i'm afraid she's gonna sing operas later... Jun 27 19:25:00 mickey|daddy: yeah... flatulences are very common indeed :P Jun 27 19:25:32 and women have to train their voice from early on ;) Jun 27 19:25:50 that's part of the story why I ordered only men :) Jun 27 19:29:07 morphis: ping! Jun 27 19:29:14 angelox|laptop: ping Jun 27 19:29:43 morphis: i got the same error with eglibc trying with your build env... Jun 27 19:30:45 hm Jun 27 19:32:14 can show me the error again? Jun 27 19:33:07 sure Jun 27 19:33:50 morphis:http://pastebin.com/D0M1G3Y8 Jun 27 19:34:02 a friend helped me and it was the kernel * Jun 27 19:34:16 removing the pointer made it work Jun 27 19:37:29 lindi-_: i'd commit it if you say which way you like. Jun 27 19:37:50 lindi-_: as to the "Starting", i really see no reason, if you're willing to test i can try to add buffer flushing to it. Jun 27 19:39:19 PaulFertser: well they way in http://paste.debian.net/120917/ looks fine Jun 27 19:39:33 PaulFertser: I can of course test these before you commit to git.openmoko.org if you want Jun 27 19:39:34 lindi-_: but i haven't actually tested it. Jun 27 19:39:46 PaulFertser: sure no problem, I can test and send you tested patches back Jun 27 19:39:59 Also i doubt if adding an extra line is better than using puts("\n") instead of putchar('\n') Jun 27 19:40:58 PaulFertser: you should have abstract_putc that calls (putc_func)('\r'); (putc_func)('\n') :) Jun 27 19:41:38 abstractions ftw ;) Jun 27 19:44:19 PaulFertser: so now there's only the serial flushing, ubifs and glamo timing issues :) Jun 27 19:49:51 angelox|laptop: you removed tmpdir completly? Jun 27 19:50:58 morphis: yes,i was using angstrom-setup-scripts and as you said me how to use your build environment,i removed everything(i only leaved my downloaded sources) and started again with your build env! Jun 27 19:51:09 ok Jun 27 19:52:49 you changed the machine? Jun 27 19:53:16 yes,to nokia900..i shouldn't ? Jun 27 19:53:36 hm Jun 27 19:53:42 can you try with palmpre? Jun 27 19:53:48 just to check Jun 27 19:54:16 ok,but i don't remember a thing,changing the machine i need change tmpdir ? Jun 27 19:54:51 no Jun 27 19:54:53 freesmartphone.org: 03morphis 07aurora * r37ceee451759 10/aurora-systemmanager/Makefile.am: aurora-systemmanager: we don't need the m4 directory Jun 27 19:54:53 freesmartphone.org: 03morphis 07aurora * r910e05b08327 10/aurora-systemmanager/systemmanager/controller.vala: aurora-systemmanager: when pressing POWER key the display gets now enabled/disabled Jun 27 19:54:58 freesmartphone.org: 03morphis 07aurora * r5f9472a0c24e 10/aurora-systemmanager/systemmanager/controller.vala: aurora-systemmanager: simplify power key handling when backlight is on Jun 27 19:54:58 freesmartphone.org: 03morphis 07aurora * reb4af13e2da9 10/aurora-systemmanager/systemmanager/controller.vala: aurora-systemmanager: finally got the idle state handling correct Jun 27 19:54:59 just edit setup-local Jun 27 19:55:14 and then build again Jun 27 19:55:19 ok,thank you!trying... Jun 27 19:55:25 angelox|laptop, it's when you change distro that you need to change tmpdir Jun 27 19:56:06 GNUtoo: ah yes,i forgot! thank you! Jun 27 19:57:14 GNUtoo: you should :) Jun 27 19:57:40 yes he grepped the kenrel Jun 27 19:57:57 and he found only normal structs Jun 27 19:57:59 not struct * Jun 27 20:02:07 mickey|daddy: you are still here? Jun 27 20:02:54 angelox|laptop: btw. I will restructure the aurora-daemon Jun 27 20:03:05 doing everything within one QML thing is not good Jun 27 20:05:42 morphis: ok... Jun 27 20:06:10 the app layout will still be the same Jun 27 20:06:26 so you don't have to change too much for your settings app Jun 27 20:10:08 ok,i still trying to install fso things on my laptop to continue codding it,but script that pespin gave to me doesn't work well these days (due source updates,versions...)... Jun 27 20:11:00 so,at least i'll try build a image to run it on my n900 and try to code a bit of it seeing how it will be at the phone... Jun 27 20:12:36 * angelox|laptop don't know if he explained well,since his English is bad! Jun 27 20:13:28 morphis: didn't work with palmpre..should i do bitbake -c clean eglibc and after bitbake eglibc (i'm not sure that it will help...no idea) Jun 27 20:21:51 angelox|laptop: try it Jun 27 20:22:02 I have no idea how to solve this problem Jun 27 20:22:08 maybe you should ask at #oe Jun 27 20:22:33 hmm,do_package generate the .ipk file isn't ? Jun 27 20:24:33 morphis: what linux distribution do you use on your development desktop ? Jun 27 20:24:43 angelox|laptop: ubuntu 11.04 Jun 27 20:25:03 morphis: ok thank you i'll install it to don't get any problem :) Jun 27 20:25:27 angelox|laptop: no Jun 27 20:25:33 try to use the shr-chroot Jun 27 20:25:34 env Jun 27 20:25:53 it isn't said that you don't get problems with ubuntu Jun 27 20:25:59 use a debianchroot for example Jun 27 20:26:22 angelox|laptop: setup the shr-chroot and then use the aurora tree for building Jun 27 20:26:43 ok Jun 27 20:27:16 thank you Jun 27 20:30:00 * angelox|laptop is crazy,that's what everyone thinks,he format all his partition and re-install all another distro only to get something work ! :) Jun 27 20:30:33 :) Jun 27 20:30:36 so I am off Jun 27 20:30:37 gn8 Jun 27 21:03:47 good night Jun 27 21:04:01 mickey|daddy, thanks a lot for the help on the ioctls Jun 27 22:01:40 mickey|daddy: hi. I am tring my chance here perhaps you are still there. how do I do to build my version of fsodeviced ? Jun 27 22:02:31 I am trying this http://trac.shr-project.org/trac/wiki/Building%20SHR#Makingchanges by replacing libphone-ui-shr by fsodeviced but withou success : it does not end to build Jun 27 22:04:57 http://pastebin.com/raw.php?i=dTrcS6vj Jun 27 22:10:09 hmm is it possible that someone pushed a commit while you were building fsodeviced with AUTOREV? That could mean that it now looks for its stuff in another directory (since the githash changed through the commit) Jun 27 22:10:24 i'd try calling clear on fsodeviced and building it again Jun 27 22:11:38 hi fellas Jun 27 22:13:10 mickey|daddy: are you up because it's (*she* is) too loud for going to sleep, or because you finally got the silence to do some work? ;-D Jun 27 22:15:33 hey DocScrutinizer. actually i didn't go to bed when i was supertired a couple of hours ago... with the effect that now i'm awaken and can't sleep... mummy is in bed and Lara Marie sleeps on the tummy of Grandma... and I'm writing the first pages of a new book Jun 27 22:16:19 heh, new book :-) Jun 27 22:16:44 ya, the other day i had the idea to write some of the crazy things that happened during the birth and during the first couple of weeks with the newborn Jun 27 22:17:11 with some irony between the lines Jun 27 22:17:32 it was about time i write something non-IT :) Jun 27 22:17:47 hehe Jun 27 22:18:09 * DocScrutinizer has a hard time figuring any non IT activities Jun 27 22:18:26 which is actually kinda scary Jun 27 22:18:50 oh uh :) Jun 27 22:18:57 it is Jun 27 22:19:22 * angelox|laptop didn't know that Mickey is daddy,Congratulations! :) Jun 27 22:22:09 angelox|laptop: thanks :) Jun 27 22:22:18 12 days now Jun 27 22:22:21 and it's an adventure... Jun 27 22:22:30 nah Jun 27 22:22:30 20 days Jun 27 22:22:33 can't count Jun 27 22:23:24 i think that you are too happy that you can't do anything for example,count! I'm right ? :) Jun 27 22:25:59 hehe Jun 27 22:25:59 right Jun 27 22:26:11 i'm happy that she sleeps now... she has a hell of a voice :) Jun 27 22:26:22 L O U D Jun 27 22:26:23 :) Jun 27 22:27:36 hehe :) Jun 27 22:29:44 mickey|daddy: congrats Jun 27 22:32:43 thanks zub Jun 27 22:37:51 * zub is thinking of the design of a program he's writing Jun 27 22:38:20 anybody a clue how programs decide whether they run "interactive" or "in a script"? Jun 27 22:38:47 sometimes I don't see any nice solution (or a solution clearly better than the other solutions I can think of) and it slows me down terribly :-/ Jun 27 22:39:03 same here Jun 27 22:39:14 DocScrutinizer: isatty? Jun 27 22:39:23 o.O Jun 27 22:39:38 i.e. test if stdin is a terminal (or stdout? or...) Jun 27 22:39:48 not in $PATH ;-) Jun 27 22:40:21 man 3 isatty :) Jun 27 22:40:26 yeah, something along that line Jun 27 22:40:38 aah Jun 27 22:40:42 3 :-P Jun 27 22:40:51 thanks Jun 27 22:41:23 don't know how to do that in a shell script, if that's what you're looking for Jun 27 22:41:37 yeah Jun 27 22:41:55 stat /proc/self/fd/0 doesn't show that Jun 27 22:42:05 or well, it shows it's a symlink to /dev/pts/N Jun 27 22:42:35 well, actually the problem is quite complex (though I had my head wrapped around it some time ago, not now anyway): Jun 27 22:42:54 if you have a postinstall script Jun 27 22:43:15 and you want to tell user about "WARNING! bla blub" Jun 27 22:43:46 how would you decide whether to use a X based notifier popup, or rather a msg to stderr Jun 27 22:44:33 if user is running apt-get install, a X popup might actually never get noticed as the X screen is somewhere else but not in fron of user Jun 27 22:45:35 if you use a echo "WARNING!" >&2; then you won't be lucky with users running the install from graphical installer tools Jun 27 22:46:06 now add to that you want or need user to "click 'OK' " Jun 27 22:46:14 and you get headache Jun 27 22:47:07 we've seen installs failing as the X11 link wasn'T possible or functioning Jun 27 22:47:54 we've seen installs never returning as the notifier with OK button was on the device 2 floors down of the ssh session Jun 27 22:48:36 and waiting for a "hit return!" from stdin is doomed to fail most of the time I'd guess Jun 27 22:49:02 http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/posix/isatty.c doesn't help much :-/ Jun 27 22:50:05 not on the problem as I just managed to comprehensively describe it now Jun 27 22:50:28 yeah, I'm still focused on the intial question Jun 27 22:50:42 got interested in it regardless of the development, sorry :) Jun 27 22:50:51 hehe Jun 27 22:50:57 :-) Jun 27 22:51:29 TADAAA Jun 27 22:51:34 :-D Jun 27 22:52:05 apt knows when hildon app manager is started and refuses to do anything. And vice versa Jun 27 22:52:05 DocScrutinizer: okay Jun 27 22:52:20 apt: GRRR Jun 27 22:52:20 it has been said that grrr is you're hungry? :) Jun 27 22:52:42 ~forget knows when hildon app manager Jun 27 22:52:43 DocScrutinizer: i forgot knows when hildon app manager Jun 27 22:52:53 sometimes i talk too with apt,so i'm not strange :D Jun 27 22:53:24 ~useless Jun 27 22:53:24 * apt starts crying and hides from docscrutinizer in the darkest corner of the room. :( Jun 27 22:55:29 maybe ppidof(ppidof($SELF)) == $someshell should work as well to detect if the install script runs under apt-get Jun 27 22:56:53 or wasn't there that "new" thing called process groups? Jun 27 22:57:43 which should probably be all under xterm for apt-get, and all under generic X for AppManager? hmmmm Jun 27 22:58:35 * angelox|laptop reboots **** BEGIN LOGGING AT Tue Jun 28 00:11:47 2011 **** ENDING LOGGING AT Tue Jun 28 02:59:58 2011