**** BEGIN LOGGING AT Thu Aug 18 02:59:56 2011 Aug 18 04:45:29 freesmartphone.org: 03morphis 07msmcomm * rd61098275375 10/libmsmhll/msmhll/linklayercontrol.vala: libmsmhll: fix spelling mistakes Aug 18 04:45:32 freesmartphone.org: 03morphis 07msmcomm * radbbb9fefa27 10/libmsmhll/msmhll/ (flowcontrolhandler.vala linkcontext.vala): libmsmhll: remove unneeded trailing whitespace Aug 18 04:45:34 freesmartphone.org: 03morphis 07msmcomm * r9f7f2603326b 10/libmsmhll/msmhll/ (6 files): libmsmhll: implement buffering of incoming data frames when link is not active Aug 18 04:45:35 freesmartphone.org: 03morphis 07msmcomm * r29ae73fbaa16 10/libmsmhll/msmhll/setuplinkhandler.vala: libmsmhll: switch to active mode after we got a config message from the remote side too Aug 18 04:45:36 freesmartphone.org: 03morphis 07msmcomm * r606d4e9926ce 10/msmcommd/src/modemcontrol.vala: msmcommd: fix spelling mistake Aug 18 04:45:38 freesmartphone.org: 03morphis 07msmcomm * r8d633260d683 10/libmsmhll/ (10 files in 2 dirs): libmsmhll: integrate fso framework logger Aug 18 04:45:39 freesmartphone.org: 03morphis 07msmcomm * rea8be6681a9c 10/libmsmhll/msmhll/linkcontext.vala: libmsmhll: check sequence and acknowledge number the right way Aug 18 05:08:02 pespin: yes Aug 18 05:09:47 mrmoku: to libphone-ui-shr? dos1 did and me too but too late :) Aug 18 05:12:02 gnutoo: http://wiki.shr-project.org/trac/wiki/Building%20SHR#Cannotparserecipesordo_rootfsafteropensslupgrade Aug 18 06:32:14 SHR: 03Martin.Jansa 07meta-smartphone * r32321c2c0ef1 10/meta-zaurus/recipes-bsp/kexec-tools/ (8 files in 2 dirs): kexec-tools: remove, moved to meta-oe Aug 18 06:32:24 SHR: 03Martin.Jansa 07meta-smartphone * r17ef9b363ba5 10/meta-shr/conf/distro/shr.conf: SHR: use empty dev_manager provider Aug 18 07:46:49 JaMa: ok...and moin :-) Aug 18 07:58:25 moin :) Aug 18 08:41:16 SHR: 03Martin.Jansa 07meta-smartphone * r374478776ffe 10/meta-shr/conf/distro/shr.conf: SHR: stop gpsd-udev from pulling udev to image Aug 18 08:57:32 DocScrutinizer51: one thing is still unclear to me... to _undo_ a route correctly I have to remember _all_ controls before applying it? Aug 18 08:57:57 lemme sort my thoughts Aug 18 08:58:05 and moin Aug 18 08:59:49 mrmoku: basically yes, each patch "object" keeps an image of the state it "came from" and restores that on pcm_close() Aug 18 08:59:59 path* Aug 18 09:00:18 only for the controls that actually get changed of course Aug 18 09:03:53 so for the contructor of a path-control-elem you read out the old state, store it loacally, and set the new state. for destructor yu restore the old state you stored locally. For non-OO make constructor control-set(string controlID, string newvalue), and make destructor control-reset(string controlID) Aug 18 09:06:04 DocScrutinizer: ok, thanks... and yeah moin :) Aug 18 09:06:31 the rationale behind all that is you don't need to bother about powersavings and idle, as each route/path cleans up behind it, so after last path got closed again the whole audio hw is back to idle default Aug 18 09:24:36 DocScrutinizer: what about the following... mplayer is playing... aci route for pcm_to_speaker is loaded... now a call comes in and gsm_to_speaker and mic_to_gsm routes are loaded... mplayer still playing but muted... then I stop mplayer will call is still ongoing Aug 18 09:25:10 if then the values get restored to what was remembered when mplayer started that would be bad, no? Aug 18 09:25:13 how do I have to handle that? Aug 18 09:25:33 s/will/while/ Aug 18 09:28:55 bbiab... got to take care of the little one Aug 18 09:43:31 mrmoku: hehe, good point Aug 18 09:44:02 yes, we definitely have to take care about that Aug 18 09:45:28 I already seem to have had a concept for that, it involved sth like swapping stored values of a control between an instance of path-control-elem object and the next instance Aug 18 09:46:04 I will think about it to see if I can rebuild the data in my brain, while sipping my 2nd coffee Aug 18 09:48:32 ok :) Aug 18 09:49:32 for now I think the ~path-control-elem has to check if it's the "topmost" or most recent instance for that controlID, and if it's not it has to pass the stored backup'ed value of the control to the successor instance which in turn replaces its own stored value by the one passed in by predecessor object Aug 18 09:50:08 and of course NOT do the restore dance then Aug 18 09:53:04 so instance A stores 'idle' for value of control and sets control value to 5, now instance B gets invoked and stores '5' and sets control to 99. When you close A now, ~A passes 'idle' to ~B so B replaces '5' by 'idle' in local backup storage. Now when you close B then ~B sets control from 99 to 'idle' Aug 18 09:54:05 ok... makes sense will have to think about how to implement that elegantly :-P Aug 18 09:54:11 ~X always passes 'value' to ~X+1 Aug 18 09:57:42 mrmoku: assuming you're not using OO and c++, you probably will keep one local array for the stored values stack of each control. "instances" are basically a counter var that also serves as pointer into that array, while a local pointer holds top of array and implicitly the number of instances. now if instance-pointer < local-counter-pointer, you simply delete the instance+1 elem in array. sth along that scheme Aug 18 10:00:01 if you replace the value[instance-pointer + 1] by NAN, your ~destructor would find its own value is NAN and step "down" the array until it finds the next non-NAN value to restore Aug 18 10:13:43 array[0]='idle'; array[1]=5; local-counter-pointer=2 //now instance that created array[0] runs destructor: instance-pointer=0; IF instance-pointer < (local-counter-pointer - 1) THEN array[instance-pointer + 1]=NAN ENDIF //status: array[0]='idle'; array[1]=NAN; local-counter-pointer=2 //now instance that created array[1] and has instance-pointer=1 gets closed: WHILE array[instance-pointer]==NAN DO instance-pointer--; ENDWHILE, then Aug 18 10:13:44 this instance restores control from 99 to array[0] which is NAN (don't forget to handle local-counter-pointer ;-D ) Aug 18 10:16:06 s/which is NAN/which is 'idle'/ Aug 18 10:16:06 DocScrutinizer meant: this instance restores control from 99 to array[0] which is 'idle' (don't forget to handle local-counter-pointer ;-D ) Aug 18 10:16:37 damn I knew I'd not get it without errors on first take ;-) Aug 18 10:24:28 mrmoku: given the instance count is different per control and not the same for all control-elem instances of one path, it's probably better to keep an abstract handle returned by control-set(string controlID, string newvalue) and pass that to control-reset(handle) Aug 18 10:25:35 this handle most likely would be your internal instance counter for that controlID Aug 18 10:35:18 DocScrutinizer: ok, thanks Aug 18 10:35:34 hope I've not been too weird and fuzzy :-) Aug 18 10:39:46 DocScrutinizer: I copied the log to a local text-file for studying while being away :-) Aug 18 10:39:58 but the principle is clear, yeah Aug 18 10:40:26 mrmoku: touchscreen is still in landscape mode when i switch to fbdev@portrait on N900 Aug 18 10:40:31 mrmoku: should i just recalibrate it? Aug 18 10:41:03 array[maxNumOfControls] of array[maxNestingOfPathes] of string control-value; maxNumOfControls ~= 200; maxNestingOfPathes ~=50 or less, maybe even 5; handle might be (index1 * 1000 + index2) Aug 18 10:41:38 actually... Aug 18 10:42:25 array[maxNumOfControls] of struct { string name-of-control; array[maxNestingOfPathes] of string control-value}; maxNumOfControls ~= 200; maxNestingOfPathes ~=50 or less, maybe even 5; handle might be (index1 * 1000 + index2) Aug 18 10:42:30 JaMa: ^^^ Aug 18 10:42:35 (about touchscreen) Aug 18 10:42:54 dos1: no idea Aug 18 10:53:15 dos1: using xinput-calibrator? Aug 18 10:54:03 dos1: it should work thanks to this patch http://git.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-graphics/xorg-xserver/xserver-xorg-1.10.2/randr-support.patch Aug 18 10:54:32 JaMa: there's no xrandr on N900 :) Aug 18 10:54:52 so probably just recalibrating is correct solution Aug 18 11:34:27 mrmoku: what's the module name for wifi in n900? Aug 18 11:37:11 mrmoku: nvm, wl1251 Aug 18 11:38:03 wl1251-spi iirc Aug 18 11:39:43 JaMa: modules are not loaded automatically here :( Aug 18 11:39:49 on shr-core@N900 image Aug 18 11:41:59 dos1: do you see ie /etc/modutils/wl1251-spi ? Aug 18 11:43:29 JaMa: in modutils there are only ipv6, rfcomm and rtc-twl Aug 18 11:45:55 dos1: and if you do opkg install kernel-module-wl1251-spi ? Aug 18 11:46:21 JaMa: i have no connection, neither usb nor wifi Aug 18 11:46:40 JaMa: wl1251-spi and wl1251 modules exist and i can modprobe them Aug 18 11:48:41 (but even after modprobing i can't get it to work - after "ifconfig wlan0 up" i get "ifconfig: SIOCGIFFLAGS: No such device") Aug 18 11:49:42 dos1: /etc/modutils/wl1251-spi is created in postinst so if you have them from modules.tar.gz then it doesn't exist Aug 18 11:50:02 JaMa: no, i didn't unpack modules Aug 18 11:50:30 JaMa: module was there in the image, but there is no entry in /etc/modutils Aug 18 11:51:16 och, nvm non-working wifi - it seems it was my fault Aug 18 11:51:46 eth0? :) Aug 18 11:51:55 no, firmware :D Aug 18 11:52:25 but still laptop does not detect n900 connected via usb Aug 18 11:52:36 either with g_ether and g_nokia Aug 18 11:53:14 but if there's wifi, then it's not a bit problem for now Aug 18 11:53:21 s/bit/big/ Aug 18 11:53:21 dos1 meant: but if there's wifi, then it's not a big problem for now Aug 18 12:01:49 SHR: 03Martin.Jansa 07meta-smartphone * ra3996a020a42 10/ (36 files in 13 dirs): initscripts-shr: remove in favor of initscripts.bbappend Aug 18 12:01:49 ouch Aug 18 12:02:07 wpa doesn't want to work :/ Aug 18 12:02:16 dos1: with iliwi? Aug 18 12:02:37 mrmoku: with wpa_supplicant :P Aug 18 12:02:46 ok, that worked for me Aug 18 12:02:57 mrmoku: on shr-core? Aug 18 12:03:02 no Aug 18 12:03:06 did not try there yet Aug 18 12:03:13 did not ever try a core image on n900 :P Aug 18 12:04:11 :P Aug 18 12:04:35 dos1: ahh, but there was one thing... you need load the aes kernel module Aug 18 12:04:43 without that it did not work for me Aug 18 12:04:47 modprobe aes? Aug 18 12:04:59 don't remember... I think there is aes_generic Aug 18 12:05:13 0022 mok@gonzales[pts/5]:~/src/openmoko/cornucopia/fsoaudiod/src/plugins/router_aci-> lsmod | grep aes Aug 18 12:05:16 aes_x86_64 7476 2 Aug 18 12:05:19 aes_generic 26106 1 aes_x86_64 Aug 18 12:05:21 for my laptop Aug 18 12:05:24 dunno if there is some aes_omap or something like that Aug 18 12:06:08 without that wpa_supplicant did hang IIRC Aug 18 12:06:36 mrmoku: find /lib/modules | grep aes returns nothing :/ Aug 18 12:07:52 dos1: modprobe configs; zcat /proc/config.gz | grep AES Aug 18 12:08:34 hmm, there is connmand running Aug 18 12:08:43 dos1: you have to install it first :P Aug 18 12:09:05 yeah, without wifi and usb it means shutdown and copy it to the SD on your host :P Aug 18 12:09:15 mrmoku: opkg list | grep aes returns nothing too :P Aug 18 12:09:23 hmm Aug 18 12:09:24 JaMa: FATAL: Module configs not found. Aug 18 12:09:29 heh Aug 18 12:09:46 :( then copy configs.ko too :/ Aug 18 12:10:27 they should be in modules.tgz, shouldn't they? Aug 18 12:10:40 yes Aug 18 12:10:50 if they are enabled by default Aug 18 12:10:56 because I don't see them in defconfig Aug 18 12:11:28 dos1: kernel-module-aes-generic_2.6.37+gitr0+7b81b4d55839514f2d801cd06855c8d422cfc3ac-r64.6_nokia900.ipk Aug 18 12:11:33 is what my shr-u build has Aug 18 12:12:18 JaMa, mrmoku: aes is in modules, but configs not Aug 18 12:13:04 mrmoku: "opkg list" wasn't probably a good idea cause i have never did "opkg update" yet :P Aug 18 12:13:22 ok, i'll copy those modules to rootfs Aug 18 12:22:07 dos1: hehe, yeah... update is quite important for list ;) Aug 18 12:35:56 * JaMa reflashing n900 to test new initscripts ;) Aug 18 12:36:17 ETA: 30min to download image :/ Aug 18 13:42:58 mrmoku: could you show me output of lsmod on n900 with shr-unstable? Aug 18 13:52:21 dos1: ok, moment Aug 18 13:55:45 dos1: uhhh. ooohh... I lied to you :-P Aug 18 13:55:54 I indeed did try an core image Aug 18 13:56:05 not a self-built one... but from the buildhost Aug 18 13:57:37 dos1: so no... sorry can't provid you that list now :/ Aug 18 14:02:00 mrmoku: but if you have usb working, then you can show list from shr-core too :P Aug 18 14:04:04 let me check Aug 18 14:04:37 dos1: well... X does not even start there and lsmod logged in from terminal tells me there is no /proc/modules Aug 18 14:04:43 looks like being very broken :P Aug 18 14:04:47 :D Aug 18 14:05:54 is it new image without initscripts-shr? Aug 18 14:16:47 JaMa: mine? is more than a month old Aug 18 14:18:08 does anyone have some quite working shr@n900 image here? :P Aug 18 14:20:06 ~seen morphis Aug 18 14:20:21 morphis <~morphis@p54899812.dip0.t-ipconnect.de> was last seen on IRC in channel #openmoko-cdevel, 5d 3h 49m 34s ago, saying: 'mickeyl: ping'. Aug 18 14:29:57 dos1: I have working shr-u but cannot reboot now and shr-c is being reflashed now Aug 18 14:30:11 waiting for spitz build to fix findutils/coreutils in my n900 image :/ Aug 18 14:31:24 JaMa: i'll try to chroot to SHR from Maemo and install udev :] Aug 18 14:31:59 I guess udev was installed Aug 18 14:32:13 if you have gpsd in your image Aug 18 14:32:33 BAD_RECOMMENDATIONS I have added for gpsd-udev somehow doesn't work with shr-core :/ Aug 18 14:33:19 JaMa: libudev0 is installed, but udev isn't Aug 18 14:33:48 bash-4.1# opkg info udev Aug 18 14:33:55 Status: install ok installed Aug 18 14:33:57 here Aug 18 14:34:36 but gpsd which pulls it is installed only because of tangogps and python-gpsd Aug 18 14:34:40 so maybe you don't have it Aug 18 14:34:49 I have meta-jama extra layer :) Aug 18 14:34:55 i have shr-lite Aug 18 14:35:45 with meta-dos containing only task-shr-dos with only git ATM ;D Aug 18 14:36:58 meta-jama is also quite small :) https://gitorious.org/shr/meta-jama/trees/master Aug 18 15:29:04 kernel-modules wasn't installed ;x Aug 18 15:45:36 JaMa|Off: cornucopia issue: Aug 18 15:45:38 | fatal: reference is not a tree: 1ed14d9d35d672257dbe159839c562bfdad17459 Aug 18 15:45:46 that's within oe-core Aug 18 15:46:03 with cornucopia stuff like the libfso* Aug 18 15:46:22 that rev exists Aug 18 15:46:25 I had that before Aug 18 15:46:32 but I don't remember how to fix Aug 18 15:46:51 | fatal: reference is not a tree: 1ed14d9d35d672257dbe159839c562bfdad17459 Aug 18 15:46:56 oops Aug 18 15:47:12 1ed14d9d35d672257dbe159839c562bfdad17459 <- this rev is valid in conucopia and is HEAD Aug 18 15:48:29 gnutoo, maybe different branch? Aug 18 15:49:34 master I guess Aug 18 16:02:54 ~seen morphis Aug 18 16:03:11 morphis <~morphis@p54899812.dip0.t-ipconnect.de> was last seen on IRC in channel #openmoko-cdevel, 5d 5h 32m 23s ago, saying: 'mickeyl: ping'. Aug 18 16:07:28 mrmoku: actually the answer is very simple and straightforward: when a path gets preempted, the state needs to be saved along with the path being preempted, not the one preempting it Aug 18 16:07:53 this way whenever the path gets active again, it's previous state can be restored naturally Aug 18 16:08:00 its Aug 18 16:09:05 idle/powersave handling is also fairly simple: just have a lowest-priority "idle" path that gets active whenever nothing else is Aug 18 16:09:32 (it's probably not entirely trivial though, as activating another path will change some controls, while others remain in the idle state...) Aug 18 16:09:57 DocScrutinizer: there is one thing that puzzles me... Aug 18 16:11:30 DocScrutinizer: AIUI, in your scheme once a process successfully opens a path, it can change the associated mixer controls directly. but what happens when the path gets preempted? how do we make sure it can't change the actual hardware controls in this state, but rather only update the state object in the audiod? Aug 18 16:12:06 or do we use some kind of virtual mixer device, that doesn't actually change the hardware state, but rather forwards all requests to the audiod? Aug 18 16:17:56 the recommended method to change controls that are meant to get changed by app is to send a dbus cmd to fsoaudiod. If an app uses direct alsamixer control access to change settings of a volume control, this change gets dealt with on tearing down the path, if the particular control is marked as a volume control exposed to app - in this case fsoaudiod reads back the recent setting from amixer and stores it to a dedicated Aug 18 16:17:58 .vol file. Next time this path gets established volumes are read out from the *.vol files. If an app is messing with arbitrary controls directly, there's nothing we can do about it first instance. On the long run we could replace the complete alsa lib to intercept those calls and treat them in a special manner - I don't see this coming any time soon though, also don't see a practical usecase for it Aug 18 16:26:46 regarding preempted pathes and direct audio control fro app: if we are lucky the hw control it wants to access is exclusive to the path the app opened. Then there's no problem at all. If however we get conflicting controls (i.e. when the headset abstract volume control and the mp3-speaker abstract volume control as exposed as a dbus method call by fsoaudiod use the same hw control in audiomixer chip) and the preempted app decides Aug 18 16:26:47 to change "its" hw volume control directly, this will obviously interfere with the current volume control and will result in setting e.g headset volume to the new value set to mp3-speaker volume by the mp3 app Aug 18 16:29:06 as mentioned above there's only so much we can do about it Aug 18 16:31:02 we *could* strace any 'preempted' muted app and intercept any direct alsactl calls Aug 18 16:31:51 we *could* wrap alsalib into a LD-PRELOAD wrapper and make all apps use this, to do same intercepting Aug 18 16:32:49 also alsa controlhooks have a method to 'lock' controls Aug 18 16:33:04 this might be exploitable to tackle the issue Aug 18 16:54:23 :( Aug 18 16:54:40 antrik: regarding your >> mrmoku: actually the answer is very simple and straightforward: when a path gets preempted, the state needs to be saved along with the path being preempted,<< -- No we won't do this, as that's again old scenario concept Aug 18 16:54:43 now still no usb, still no wifi and vala-terminal shows only cursor - nothing else Aug 18 16:56:05 but there is phonet0 now Aug 18 17:15:08 DocScrutinizer: well, the usecase is obvious -- if some app decides to change the volume while the path is preempted, I don't want it to mess with the volume of call audio or ringtone... I'm not sure how many apps do this, but this whole scheme sounds rather fragile if we can't prevent such situations :-( Aug 18 17:15:44 suggest a better scheme Aug 18 17:16:32 the app is not supposed to aces volume controls directly, as elaborated to epic length above Aug 18 17:17:18 if you can come up with a solution that allows app to do this and nothing 'bad' will happen, the please do Aug 18 17:17:49 keep in mind though we want to keep compatibility with mainstream alsa Aug 18 17:18:50 I'm sure PulseAudio can handle such things in a robust fashion... :-P Aug 18 17:18:54 * antrik ducks Aug 18 17:19:15 plonk Aug 18 17:21:43 regarding the state saving: how does saving the state along with the active path make this "scenario concept"? Aug 18 17:22:13 I think you're not aware we decided looong ago to give *each* app a dedicated softvol, so basicaly NO app is supposed to access hw controls (that are the only controls that might be shared) Aug 18 17:23:25 and no, I'm really not going into discussing scenario basics again, just to make your day less boring Aug 18 17:23:41 that's a good decision I support wholeheartedly... but I don't see how this is related to what I said about saving the state Aug 18 17:24:10 just so much: we NEVER save any states (except volumes in special dedicated volume files) Aug 18 17:25:32 then why did you write a page of text above about saving state when switching to a different path? Aug 18 17:31:07 meh, maybe it's me and I'm totally stupid, but I really get annoyed by your questions as I always think they are off the point and assuming things that are incorrect. So I revert to my previous behaviour of ignoring them Aug 18 17:49:50 DocScrutinizer: well, if I'm assuming things that are incorrect, set them straight. I'm pretty sure that if there are things unclear to me, they are unclear to the others here as well, so you will have to explain them anyways Aug 18 17:54:39 rereading mrmoku's question, perhaps talking about state is indeed off the point. he asked about saving controls, but that doesn't necessarily imply that these are actually mutable Aug 18 17:55:32 if we assume they aren't, this actually makes things even simpler: we don't have to save anything. we can always see which controls to reset to which value simply by comparing the paths to be activated/deactivated Aug 18 17:56:58 and the paths to activate/deactivate are a pure function of what devices are open; what was opened when is completely irrelevant Aug 18 18:14:48 DocScrutinizer: BTW, I think priorities shouldn't actually be attached to paths (GSM->headset, CPU->headset etc.), but rather to virtual devices (call audio, multimedia, ringtone etc.) Aug 18 18:15:33 if the paths currently associated to the devices conflict, the one associated to the higher-priority device wins Aug 18 18:16:19 there is no reason why speaker for example should have inherently higher priority than earpiece -- it all depends on what functions they currently serve Aug 18 18:19:26 and another interesting question: if we have two devices (e.g. multimedia and ringtone) both currently associated with the same path, they wouldn't conflict, so normally we would get them mixed. however, when playing ringtone for example, we don't want it mixed with multimedia, but rather multimedia should be muted. how do we express that? some "exclusive" flag attached to the virtual device? Aug 18 18:20:37 or never mix virtual devices, always muting the lower-priority one when they use the same path? Aug 18 18:27:10 antrik: fsoaudiod has it's own sort of priorities for that... way uplevel Aug 18 18:30:14 mrmoku: for path defs you may want to have an #include statement, that allows reusing one path definition in another one Aug 18 18:30:46 mrmoku, ping Aug 18 18:32:31 mrmoku: yeah, I realised that we need a more generic soft-conflict mechanism. the GSM->earpiece path for example probably doesn't conflict at a hardware level with CPU->speaker; yet we would want things going to speaker (e.g. multimedia) muted while in a call Aug 18 18:32:51 mrmoku: I wonder though how this inteacts with the path conflicts Aug 18 18:44:26 mrmoku, which e17 theme do you use? Aug 18 19:01:00 TAsn: where? Aug 18 19:01:10 home Aug 18 19:01:22 e17-theme-kde :-P Aug 18 19:01:49 I was using the one you told me though Aug 18 19:03:10 pfft Aug 18 19:03:14 what was it? Aug 18 19:03:16 dtrs? Aug 18 19:03:22 detorious? or efenheit? Aug 18 19:03:27 (can't spell either of them{ Aug 18 19:04:43 freesmartphone.org: 03morphis 07msmcomm * r11184b804f37 10/msmcommd/src/modemcontrol.vala: msmcommd: fix spelling mistake Aug 18 19:05:41 TAsn: detorious Aug 18 19:06:01 ah, ok. Aug 18 19:06:17 k-s is trying to make it the new default Aug 18 19:06:24 adn I just wanted to make sure this was the one you liked Aug 18 19:06:38 yeah :) Aug 18 19:06:52 there were some things that made me switch back to kde Aug 18 19:07:13 like segfaulting nm-applet on resume and sometimes e too Aug 18 19:07:16 was too fast it broke your monitor? Aug 18 19:07:22 :P Aug 18 19:07:36 e shouldn't seg. Aug 18 19:07:39 and the main killer argument for me was kdevelop not working correctly Aug 18 19:07:43 it did Aug 18 19:07:50 nothing _should_ seg :P Aug 18 19:07:52 as for nm-applet: use connman Aug 18 19:07:58 mrmoku, it shouldn't. :) Aug 18 19:08:07 gnutoo: isn't it still from broken git-native? Aug 18 19:08:17 wrt kdevelop: use vim, you gui-baby. :P Aug 18 19:08:29 dos1: kernel-modules shouldn't be installed :) Aug 18 19:08:36 dos1: just listed modules from machine.conf Aug 18 19:08:36 TAsn: I'm a connman noob Aug 18 19:08:50 JaMa|Off: ok Aug 18 19:08:52 that might change when we start to use it seriously on our phones Aug 18 19:09:02 mrmoku, it's still not used? Aug 18 19:09:04 yes maybe Aug 18 19:09:12 TAsn: it get's installed... but not used :P Aug 18 19:09:38 I'll bitbake git-native, I hoped that it would bitbake it automatically....before reading your wiki entry Aug 18 19:09:45 get_pty: not enough ptys Aug 18 19:09:59 neither xterm not vala-terminal want to work :( Aug 18 19:10:11 gnutoo: it cannot parse recipes without git-native (when using autorev) Aug 18 19:10:15 mrmoku, lol. Aug 18 19:10:20 ok Aug 18 19:16:20 dos1: new wizard looks nice :) Aug 18 19:16:28 dos1: dpi and connman settings Aug 18 19:16:43 JaMa: yep ;) Aug 18 19:16:52 JaMa: anyway, there is bug when udev is installed Aug 18 19:17:04 resulting in non-working virtual terminals Aug 18 19:17:09 xterm, vala-terminal, vte etc. Aug 18 19:17:39 mount /dev/pts I guess Aug 18 19:17:43 yep Aug 18 19:17:50 do you have initscripts alredy? Aug 18 19:17:57 but "mount" shows it as mounted... Aug 18 19:18:24 TAsn: is gui working for connman in e ? Aug 18 19:19:20 JaMa: no, i think i don't have them built Aug 18 19:19:45 JaMa: building task-shr-minimal won't be enough? Aug 18 19:20:19 mrmoku, yes Aug 18 19:20:27 and it should even work nicely for the phone Aug 18 19:20:33 i use it on my laptop Aug 18 19:20:38 and I'm pretty sure raster as well Aug 18 19:20:43 there are rough edges though Aug 18 19:20:54 dos1: no Aug 18 19:21:14 dos1: you have to update meta-smartphone, clean keymaps and task-core-boot Aug 18 19:21:22 dos1: and then rebuild image Aug 18 19:21:36 JaMa: i already cleaned them Aug 18 19:21:50 but task-shr-minimal only rebuilt keymaps Aug 18 19:22:00 opkg install -force-reinstall keymaps task-core-boot; opkg remove initscripts-shr; opkg install initscripts Aug 18 19:22:12 ok, building image atm Aug 18 19:22:15 task-core-boot is image dependency Aug 18 19:23:50 btw. when X are disabled, keyboard mapping in console is wrong Aug 18 19:24:04 well, there is really no keyboard mapping :] Aug 18 19:24:27 TAsn: last time I tried it did not... and that's not long ago. But I might have done things wrong dunno Aug 18 19:24:40 install connman Aug 18 19:24:42 add the module Aug 18 19:24:43 restart e Aug 18 19:24:45 that's it Aug 18 19:25:22 then I did not do it wrong :P Aug 18 19:25:41 will retry when I'm back from france :) Aug 18 19:26:32 heyho Aug 18 19:28:17 freesmartphone.org: 03rico 07cornucopia * r12b5e795318e 10/fsodeviced/src/plugins/openmoko_powercontrol/plugin.vala: fsodevice: add gps powercontrol Aug 18 19:28:33 Hi morphis! Aug 18 19:28:58 angelox|laptop: hi Aug 18 19:29:15 did you document your kexecboot issues on the trac bugreporting system? Aug 18 19:29:22 Hi gnutoo! Aug 18 19:29:31 mrmoku, france? wth? Aug 18 19:29:37 morphis: I must still write to palm, I didn't have the time until now, slow internet, no internet etc.... Aug 18 19:29:45 gnutoo: ok Aug 18 19:29:54 mrmoku: I'm in France too Aug 18 19:29:57 gnutoo: nope,i did take a lot of time fixing my N900 battery,since it wasn't working Aug 18 19:30:05 ok Aug 18 19:33:07 mrmoku: where are you in france? Aug 18 19:34:10 freesmartphone.org: 03morphis 07msmcomm * r403d2962da9a 10/msmcommd/src/modemcontrol.vala: msmcommd: don't shutdown and restart link layer when doing suspend/resume Aug 18 19:43:54 hm, HP will not produce anymore webOS devices ... Aug 18 19:44:20 what will they do instead? Aug 18 19:44:49 gnutoo: we'll go to Paris tomorrow morning Aug 18 19:44:59 stay there a day and then go to the bretagne Aug 18 19:45:12 TAsn: yeah... old man needs some holliday :) Aug 18 19:45:14 http://www.precentral.net/breaking-hp-shutting-down-webos-device-operations-will-continue-explore-options Aug 18 19:45:33 gnutoo: put it on PCs and give other produces licenses for webOS Aug 18 19:45:34 quote of the day: >>I don't need gentoo, I have a gitlfriend<< (sic!) Aug 18 19:45:38 so HTC with webOS Aug 18 19:45:43 or Samsung with webOS Aug 18 19:45:55 I'm near bordeaux Aug 18 19:46:05 mrmoku, you man too. Aug 18 19:46:11 ok Aug 18 19:46:15 young* Aug 18 19:46:17 men* Aug 18 19:46:20 wtf Aug 18 19:46:25 but much less :-P Aug 18 19:46:41 so Pre devices are a dead end .... Aug 18 19:47:45 gnutoo: ok, we'll stay the first part of the three weeks in north bretagne... and then go to the southern end of it... but not as far as Bordeaux Aug 18 19:48:12 Ainulindale: beware... car is packed ;) Aug 18 19:48:22 ok Aug 18 19:48:26 that sucks HP! Aug 18 19:48:40 any options I have now? Aug 18 19:49:07 hmmm Aug 18 19:49:20 1)wait for new not-hp webos devices Aug 18 19:49:30 hmmm Aug 18 19:49:32 I hate waiting ... Aug 18 19:49:36 ok Aug 18 19:49:44 n900 is great but a dead-end too Aug 18 19:50:13 full concentrate on gta04 Aug 18 19:50:20 or get a recent android device Aug 18 19:50:28 I thought about buying the pre 3 Aug 18 19:50:28 yes gta04.....is very good Aug 18 19:50:35 but with this news I don't want it anymore Aug 18 19:51:01 mrmoku: enjoy! Aug 18 19:51:07 DocScrutinizer: thanks :) Aug 18 19:51:49 the power...err my laptop is with me... so I'm hopefully not completely disconnected from the rest of the world Aug 18 19:51:58 and might find some time for fsoaudiod too Aug 18 19:52:16 JaMa: how to easly append something to kernel cmdline on n900? Aug 18 19:52:42 morphis: we all should fully concentrate on gta04 when it's reality Aug 18 19:53:00 mrmoku: so we need a way to archive all core developers get one Aug 18 19:53:32 and with "get one" I mean urgently after it arrives to make it the best foss user experience ever Aug 18 19:54:17 * mrmoku will miss the keyboard :/ Aug 18 19:54:58 morphis: how many core developers are we? Aug 18 19:55:48 mrmoku: I would say: you, gnutoo, JaMa, me, mickeyl, someone else? Aug 18 19:56:04 so full SHR/FSO power Aug 18 19:56:46 yup Aug 18 19:57:09 and we should maybe do some planing of the aspects we want to archive Aug 18 19:57:28 well, after all those coding on gta02 i'm even using software keyboard on N900 with SHR :D Aug 18 19:57:29 we want to get done and working Aug 18 19:57:34 basically gta04 may be a recent and acceptable phone Aug 18 19:57:39 gnutoo: yes Aug 18 19:57:45 *free bootloader Aug 18 19:58:02 and I should come back from the making-other-vendors-phones working trip Aug 18 19:58:08 *modem has no special power Aug 18 19:58:33 *will be recent enough Aug 18 19:58:56 morphis: oh yes... the planning we started to talk about... and then did not happen :/ Aug 18 19:59:01 having the same screen than gta02 also helps Aug 18 19:59:27 so let's do an irc meeting now....but my connections lags a lot Aug 18 19:59:33 gnutoo: case and screen we need to change, but the rest is ok :) Aug 18 19:59:38 I hate omgta02 case, why the hell reusing it? <- that's my idea on gta04 :P Aug 18 19:59:43 gnutoo: no, not yet please Aug 18 19:59:44 * mrmoku likes the case ;) Aug 18 19:59:45 I have to leave Aug 18 19:59:51 because it costs........ Aug 18 19:59:52 need to prepare presentation for froscon Aug 18 19:59:57 plastic costs a lot.... Aug 18 20:00:04 ok Aug 18 20:00:19 i like gta02 case Aug 18 20:00:33 mrmoku, gnutoo: we should do some IRC meeting in the near future and a FSOSHRUDCON again meet and talk in detail Aug 18 20:00:43 but I have to leave now Aug 18 20:00:45 bye Aug 18 20:00:50 morphis: I'm in france for three weeks Aug 18 20:00:53 too late :P Aug 18 20:01:19 and I'll work for one month soon if everything goes fine Aug 18 20:01:46 in france? or in italy? Aug 18 20:02:04 france Aug 18 20:02:18 italy....you don't get paid there Aug 18 20:02:26 yeah italy sucks these days :/ Aug 18 20:02:44 it costs less to pay the fine of not paying you than paying you Aug 18 20:03:27 yeah! Aug 18 20:03:33 lol Aug 18 20:03:41 working phonet, working battery *and* working terminal on N900 :) Aug 18 20:03:49 so now some networking... Aug 18 20:03:58 dos1: :-) Aug 18 20:04:09