**** BEGIN LOGGING AT Thu Oct 27 02:59:58 2011 Oct 27 06:36:42 SHR: 03Martin.Jansa 07shr-chroot * r695fa17daf32 10/ (1359 files in 46 dirs): system upgrade Oct 27 09:03:28 SHR: 03Martin.Jansa 07meta-smartphone * r591c1d5a9ccf 10/meta-shr/recipes-connectivity/openssh/ (openssh_5.8p2.bbappend openssh_5.9p1.bbappend): openssh: rename bbappend to match new version Oct 27 09:52:46 hi Oct 27 09:53:27 hi Oct 27 10:44:37 hi dos1|N900 Oct 27 10:48:11 dos1|N900: hi what are you working on? Oct 27 10:52:36 gnutoo: actually on my studies... Oct 27 10:53:14 gnutoo: but i think i'll today bitbake some fresh image and look at it Oct 27 10:53:50 i'll need static MAC address of WiFi card Oct 27 10:56:00 ok Oct 27 10:56:17 dos1|N900: since we don't want udev, maybe making a script like for g_ether is the solution? Oct 27 10:56:39 the problem is that the mac address would be in /dev/mtd1 Oct 27 10:56:57 use 0xFFFF on the target to identify the mac address in the cal partition Oct 27 10:57:17 dos1|N900: someone should also work on the telephony side: Oct 27 10:57:35 *there is still writei to take care of with the fsoaudiod plugin Oct 27 10:57:41 *there is no sms etc.... Oct 27 10:57:50 and when I tried the image It didn't register Oct 27 10:57:55 it did before Oct 27 10:58:06 so maybe check with phonet-utils if the address are correct Oct 27 11:04:17 dos1|N900: are you still there? Oct 27 11:04:52 yup, just on the phone, so not looking at irc window all the time ;) Oct 27 11:08:56 ok Oct 27 12:07:54 0xFFFF can read out CAL? Oct 27 12:08:20 gnutoo: ^^^ Oct 27 12:14:24 yes Oct 27 12:14:25 it can Oct 27 12:14:31 but it doesn't decode it Oct 27 12:14:38 it just say something like Oct 27 12:14:47 foo: 0x... 0x... 0x... Oct 27 12:19:56 you must cross-compile it tough Oct 27 12:20:24 because that part runs on the target Oct 27 12:33:10 -x extract configuration entries from /dev/mtd1 Oct 27 13:07:04 I still wonder why GTA04 is using GTA02 case, rather than e.g eten Glofiish M800 case (has same LCM, basically even same mainboard regarding SoC etc, it's a GTA02 clone with some improvements) Oct 27 13:23:43 JaMaOffELCE: the 2.6.39 resume alsa bug is now at https://docs.openmoko.org/trac/ticket/2478 Oct 27 13:34:15 I bought my Glofiish M800 for 200€ back when, now they seem more expensive and not that widely available, but still worth considering the alternative Oct 27 13:36:11 probably nowadays you could even get (USB broken, or otherwise mobo-defect) N900, for cheap money ;-P. OK they don't have that crappy LCM of GTA02 Oct 27 13:37:47 spare cases and touchpannels are available new from China as well, keymats and even domesheets are available as well Oct 27 13:38:07 MEH Oct 27 13:56:07 there was also m810 Oct 27 13:56:23 a friend had that pohne... Oct 27 13:57:29 M810 had no hw kbd Oct 27 14:00:52 I don't remember but I think it had one that didn't work out of the box Oct 27 14:02:38 he even did patch but didn't publish them at the end because the device was a dead end Oct 27 14:02:46 *did some patches Oct 27 14:05:45 lindi-: thanks Oct 27 14:06:34 JaMaOffELCE: I got systemtap working and am trying to track this down Oct 27 14:06:52 harald welte once worked on making kbd etc work on OM2008 for M800 Oct 27 14:06:58 JaMaOffELCE: do you remember who'd know more about the alsa stuff? larsc? Oct 27 14:07:27 yes larsc,mrmoku,gnutoo Oct 27 14:10:02 lars_: mrmoku`: gnutoo: ping? ;-) Oct 27 14:11:28 lindi-: pong, but I'm busy right now Oct 27 14:11:50 hi lindi- Oct 27 14:11:53 what's the issue? Oct 27 14:12:14 gnutoo, hi! good news: I get notified of calls on the Nexus S (I receive a message from teh modem with the incoming call number) Oct 27 14:12:22 that means I'm registered Oct 27 14:12:25 on the network Oct 27 14:12:30 gnutoo: 2.6.39 is not restoring alsa state correctly on resume: https://docs.openmoko.org/trac/ticket/2478 Oct 27 14:14:17 ah ok Oct 27 14:14:22 isn't that an userspace issue? Oct 27 14:14:34 usually you save it on reboot Oct 27 14:14:42 and restore on boot Oct 27 14:14:50 s/reboot /shutdown Oct 27 14:17:52 gnutoo: maybe I wasn't clear enough Oct 27 14:18:03 gnutoo: if you restore it there is no chance Oct 27 14:18:37 gnutoo: read the report more carefully :) "alsactl store" shows identical state before and after suspend but it still does not work Oct 27 14:20:50 ok Oct 27 14:21:04 I'll look when I'm back at home or during the course pause Oct 27 14:23:03 gnutoo: if you can make some hypothesis I can test it so you save time :) Oct 27 14:24:41 I'll have to read the bugreport for that Oct 27 14:24:48 I'll do as soon as possible Oct 27 14:24:55 but I'm in a database course right now Oct 27 14:35:41 paulk: WOW!!!! Oct 27 14:35:50 gnutoo, SMS too Oct 27 14:35:52 paulk: under SHR? Oct 27 14:35:55 replicant Oct 27 14:35:59 ok nice!!!!! Oct 27 14:36:08 yep :p Oct 27 14:36:22 btw do you know morphis has working GPRS on SHR? Oct 27 14:36:29 lindi-: basically suspend/resume loose the current state right? Oct 27 14:37:03 gnutoo: at least some of the state is lost yes but it "alsactl store" still shows the correct state Oct 27 14:37:12 ah ok Oct 27 14:37:14 hmmm Oct 27 14:37:23 gnutoo: so something in kernel caches the current state but the hardware does not match this Oct 27 14:37:31 yes it does Oct 27 14:37:38 as far as I remember Oct 27 14:37:50 maybe just restore that in the kenrel driver on .resume? Oct 27 14:37:54 like in the CODEC Oct 27 14:38:26 gnutoo: sounds good, I just haven't found the right point in code :) Oct 27 14:38:41 are there some datasheets of the wolfson CODEC? Oct 27 14:39:01 oops I meant are the datasheet still disponible Oct 27 14:39:51 gnutoo: yes, I've read the wolfson datasheets Oct 27 14:40:02 I've just forgot all the kernel parts :) Oct 27 14:40:14 gnutoo: disponible? Oct 27 14:40:15 basically it's alsa SOC Oct 27 14:40:26 should wm8753_resume get called on resume? Oct 27 14:40:27 I meant available Oct 27 14:40:28 sorry Oct 27 14:40:31 I think so Oct 27 14:40:40 to verify that just add a printk Oct 27 14:40:49 I'm trying to use systemtap :) Oct 27 14:41:06 stap -e 'probe module("snd_soc_wm8753").function("wm8753_resume") { printf("%s %s\n", probefunc(), $$parms); }' Oct 27 14:41:32 but that does not print anything in resume Oct 27 14:41:41 ah? Oct 27 14:41:51 I don't know system tap enough Oct 27 14:41:55 is that mainline? Oct 27 14:42:37 gnutoo: systemtap is a userland tool that compiles systemtap language to a kernel module that uses kprobes() to attach probe functions to live kernel Oct 27 14:42:37 paulk: did morphis had the same kind of success with FSO? Oct 27 14:42:48 ok Oct 27 14:42:51 gnutoo: kprobes is mainline since 2.6.18 or something Oct 27 14:43:00 ah that's what I wanted to know Oct 27 14:43:01 nice then Oct 27 14:44:16 gnutoo, yes I think morphis can receive calls and SMS too Oct 27 14:44:17 gnutoo: I do get traces like http://paste.debian.net/140401/ with just a few lines of systemtap code Oct 27 14:44:56 gnutoo, though he worked on GPRS instead. Oct 27 14:45:04 yes I eared Oct 27 14:45:52 gnutoo: hmm, dmesg does mention "soc-audio soc-audio: resume work item may be lost" Oct 27 14:46:43 the course is starting again....sorry Oct 27 14:47:17 gnutoo: np Oct 27 14:48:54 stap -e 'probe module("snd_soc_core").function("snd_soc_resume") { printf("%s %s\n", probefunc(), $$parms); }' Oct 27 14:49:04 that prints "snd_soc_resume dev=0xc7af5c08" on resume Oct 27 14:49:38 ok Oct 27 14:50:06 so snd_soc_resume gets called but wm8753_resume does not Oct 27 14:51:38 hmmm Oct 27 14:55:06 this schedule_work seems to fail only if if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))) { Oct 27 14:55:07 fails Oct 27 15:15:00 good afternoon Oct 27 15:25:23 hi Oct 27 15:29:04 hmmm Oct 27 15:32:46 I've to look in the code Oct 27 15:33:04 not to mention that I've not commit access to the om kernel Oct 27 15:38:37 gnutoo: I'm using the SHR git tree anyway Oct 27 15:41:30 $ stap -v -e 'probe module("snd_soc_core").statement("snd_soc_resume@sound/soc/soc-core.c+8") { printf("%x\n", $card->deferred_resume_work->data->counter); }' Oct 27 15:41:35 ffffffffc7814605 Oct 27 15:42:35 the lower part does look like a pointer Oct 27 15:42:49 comment says helpfully "The first word is the work queue pointer and the flags rolled into Oct 27 15:42:51 one" Oct 27 15:47:30 ( usually you save it on reboot) NOOOOOOOOO you don't!! Oct 27 15:54:16 on suspend, the audio hw (particularly amp) will need to get shutdown, on resume you want to revert that. This is - and always has been - a genuine duty of the driver which needs to support suspend/resume. No way you should employ alsactl store/restore for that. Oct 27 15:54:57 DocScrutinizer: yep Oct 27 15:55:45 and NEVER, I repeat NEVER EVER store audio state on shutdown and restore it after boot! After boot you want to load a virgin generic reset state to audio hw, not restore the last $RANDOM state it had on shutdown Oct 27 15:56:15 no need to shout :P Oct 27 15:58:30 DocScrutinizer: what would happen if did that? Oct 27 15:59:10 just for curiosity :) Oct 27 15:59:45 shut down with headset plugged in, unplug headset, boot -> audio "defect", terrible moaning and whining, "audio broke again, needed to reflash! :-(((" Oct 27 16:00:35 noooo, apt is dead again, wtf?? Oct 27 16:01:47 didn't know that audio can be broke so easy Oct 27 16:02:51 it's not broken, it's just abused and misconfigured Oct 27 16:04:17 hmm Oct 27 16:04:53 depending on audio-concept-of-the-week you may end with your default state being basically what's in headset.state and no way to get back the original sane setting Oct 27 16:06:20 e.g when inserting headset stores the current state to alsastate then loads headset.state, and on unplugging it restores alsastate which actually also is headset.state values saved on last system shutdown Oct 27 16:06:31 ~nf Oct 27 16:06:43 apt is dead Oct 27 16:07:05 nuttin new in newsflash since months Oct 27 16:08:57 (audio msg) i see... Oct 27 16:09:09 * jonwil is getting annoyed at this damn ARM assembler :( Oct 27 16:13:14 wb, apt Oct 27 17:07:40 back(on freerunner) Oct 27 17:09:15 bbs Oct 27 17:13:53 lindi-: did you succedd to fix the CODEC issue? Oct 27 17:14:04 hi paulk Oct 27 17:14:21 hi gnutoo Oct 27 17:49:12 gnutoo: not yet Oct 27 18:06:07 zub, hmm I lost the link to the dir with your patches, and I can't find it in logs :S if you are here pass it to me please, as I'm in the middle of a quite boring class :P Oct 27 18:08:22 http://linux.fjfi.cvut.cz/~zub/SHR/libeflvala/ Oct 27 18:08:26 pespin: ^ Oct 27 18:08:35 thanks :) Oct 27 18:08:43 de nada Oct 27 18:10:18 ok Oct 27 18:10:20 let me look Oct 27 18:10:39 oops Oct 27 18:10:45 lindi-, ok, let me look Oct 27 18:14:38 zub, hmm the elm->elementary patch seems like it's not handling the rename correctly? it seems it just copies all content in it when you did the patch to new file and removes old one Oct 27 18:14:59 I'll redo it here Oct 27 18:17:38 hmm stupid question... how do I grep for something starting with "--" ? it takes it as a grep option u.u Oct 27 18:21:47 pespin: which rename? Oct 27 18:21:58 pespin: grep -- -- Oct 27 18:22:11 zub, elm.vapi->elementary.vapi Oct 27 18:22:25 zub, I can't do grep -r --elm * Oct 27 18:22:49 for example Oct 27 18:22:54 $ echo --elm | grep -- --elm Oct 27 18:22:54 --elm Oct 27 18:23:38 yes, the file rename in diff is handled by remove + add Oct 27 18:23:57 zub, that's not good as the content changed Oct 27 18:24:00 right? Oct 27 18:24:12 heyho Oct 27 18:24:13 if the contents is ouf of that, then it's NG Oct 27 18:24:21 but then the patch would fail to apply Oct 27 18:24:36 GNUtoo|laptop: GPRS is now completely working on the nexus-s Oct 27 18:24:56 "out of date", blah, sometimes I wonder how do I manage to make such typos :-/ Oct 27 18:25:20 also, I re-created the patch after recent svn rebase, but if you did more changes, then it will fail to apply Oct 27 18:25:36 in fact, svn can track file renames, so it might be better to do svn mv ... Oct 27 18:25:46 that way history's not lost Oct 27 18:27:13 pespin: I suggest: apply, then svn revert elm.deps elm.vapi; rm elementary.deps elementary.vapi; svn mv elm.deps elementary.deps; svn mv elm.vapi elementary.vapi Oct 27 18:27:48 (apply to get the other changes; revert whatever happens to the patch-rename-attempt, then svn rename) Oct 27 18:28:02 morphis, wow I just opkg upgraded Oct 27 18:28:02 then commit and we can celebrate :D Oct 27 18:28:14 morphis, paulk has telephony(sms+calls) Oct 27 18:28:20 on replicant Oct 27 18:28:43 great Oct 27 18:28:53 I've looked with alsa Oct 27 18:29:12 I think the only possible solution is to backport the one from mainline Oct 27 18:29:27 because the normal one lacks idma etc.... Oct 27 18:30:32 normal one means the one from 2.6.35 Oct 27 18:31:06 (official 2.6.35, not the modified one for the nexus S) Oct 27 18:31:50 zub, I used sed + svn mv :) Oct 27 18:31:59 GNUtoo|laptop: I can make function call traces if you tell me the functions you want to include in the trace :) Oct 27 18:32:00 compiling + testing right now Oct 27 18:32:14 hmmm Oct 27 18:32:45 let me re-find the bugreport and all Oct 27 18:35:06 pespin: bueno Oct 27 18:40:22 GNUtoo|laptop: next step is to implement call + sms Oct 27 18:40:30 ok Oct 27 18:40:30 GNUtoo|laptop: but I need audio for call testing Oct 27 18:40:36 audio works Oct 27 18:40:40 ok Oct 27 18:40:40 but not well Oct 27 18:40:48 then I will test Oct 27 18:40:52 that is to say if you do hw:0 it works flawlessly Oct 27 18:40:56 I have not very much time now Oct 27 18:40:59 ok Oct 27 18:41:01 but it suffer from the limitation I told yesterday Oct 27 18:41:07 *limitations Oct 27 18:41:15 can we create audio scenarios to handle routing? Oct 27 18:41:22 yes Oct 27 18:41:24 all works Oct 27 18:41:34 but you must use hw:0 for mplayer and such Oct 27 18:41:37 that's all Oct 27 18:41:47 hw:0 suffer from 2 flaws: Oct 27 18:42:01 *no sound multiplexing Oct 27 18:42:14 *no sound conversion but plughw:0 works sometimes Oct 27 18:42:23 and does the android multiplexing or they don't do it? Oct 27 18:42:39 they do...in the upper abstratcions layer Oct 27 18:42:57 it's like if they had pulseaudio sitting on top of alsa and doing writei Oct 27 18:43:16 ah ok Oct 27 18:43:20 to get audio working: Oct 27 18:43:20 I ahve to leave now Oct 27 18:43:23 yes? Oct 27 18:43:30 you must load a scenario Oct 27 18:43:37 so alsactl -f ok.state restore Oct 27 18:44:35 ok Oct 27 18:44:44 do we have the state files already? Oct 27 18:44:56 no not yet Oct 27 18:45:06 http://www.pastie.org/private/nvh0hpzckmwsrkpds2naaa Oct 27 18:45:20 that is for headphones Oct 27 18:45:22 ok Oct 27 18:45:26 I have to leave now Oct 27 18:45:30 ok Oct 27 18:45:33 let's tal tomorrow or this weekend Oct 27 18:45:34 see you another day Oct 27 18:45:34 bye Oct 27 18:45:37 bye Oct 27 18:45:46 zub, I'm going home now, I'll apply it later Oct 27 18:49:03 ok back to the om-gta02 Oct 27 18:53:56 lindi-, so I did that Oct 27 18:54:04 mplayer ./some_music -ao alsa Oct 27 18:54:07 it plays it Oct 27 18:54:08 then I suspend Oct 27 18:54:15 and then nothing... Oct 27 18:54:23 it doesn't resume play at resume Oct 27 18:54:33 GNUtoo|laptop: yes same here Oct 27 18:54:35 and when I play again....no sound Oct 27 18:54:44 GNUtoo|laptop: does it play if you do the steps I listed under "more info"? Oct 27 18:54:57 I'll try Oct 27 18:55:04 btw, mplayer is not the most simple test application :) Oct 27 18:55:18 ok I should try aplay then Oct 27 18:55:56 yes it workarrounds it Oct 27 18:56:34 but only the second time Oct 27 18:56:40 I've to stop the first mplayer Oct 27 18:56:45 the one that was suspended Oct 27 18:56:47 let me try more Oct 27 18:57:44 same with aplay Oct 27 18:57:51 anyway let's try to fix your bug first Oct 27 18:59:02 so what should I do? try to backport the upstream fix? Oct 27 19:00:13 hmmm mplayer behave strangely Oct 27 19:00:36 like playing again some part of the song Oct 27 19:02:07 lindi-, you already traced that : .resume = wm8753_resume, ? Oct 27 19:02:09 I guess so Oct 27 19:05:56 lindi-, look line 1200 of soc-core.c Oct 27 19:06:46 see also the comment on top of that Oct 27 19:06:56 all that seem wrong Oct 27 19:07:15 so basically verify that it suspends Oct 27 19:07:24 look if codec->driver->suspend is called Oct 27 19:07:37 by tapping wm8973_suspend Oct 27 19:07:47 lindi-, ping? Oct 27 19:14:38 GNUtoo|laptop: wm8753_resume does not get called Oct 27 19:15:28 GNUtoo|laptop: I don't think the upstream fix is key here Oct 27 19:15:41 ah? Oct 27 19:15:55 look if wm8753_suspend is called Oct 27 19:16:04 GNUtoo|laptop: line 1200 is codec->driver->resume(codec); Oct 27 19:16:04 opk Oct 27 19:16:21 yes I know Oct 27 19:16:25 but I want suspend Oct 27 19:16:30 look at the comment Oct 27 19:16:33 on top of line 1200 Oct 27 19:16:39 ok Oct 27 19:19:59 stap -v -e 'probe module("snd_soc_wm8753").function("wm8753_suspend") { printf("%s\n", $$parms); }' Oct 27 19:22:31 GNUtoo|laptop: according to systemtap the function wm8753_suspend is never called Oct 27 19:22:39 ok Oct 27 19:22:54 GNUtoo|laptop: I'll give you a line number trace of soc_resume_deferred Oct 27 19:23:02 ok Oct 27 19:25:19 stap -e 'probe module("snd_soc_core").statement("*@sound/soc/soc-core.c:*") { printf("%s %s\n", pp(), $$vars); }' Oct 27 19:26:30 bit slow to add all those probes it seems ... Oct 27 19:26:52 ok Oct 27 19:34:19 I think we should ask what to do on alsa ml Oct 27 19:34:27 or ask lars_ Oct 27 19:34:45 because I'm lost here, even if the workarround is quite simple to achieve Oct 27 19:36:32 GNUtoo|laptop: a sec, I'm busy finetuning systemtap :) Oct 27 19:36:39 ok Oct 27 19:36:50 should I try a workarround? Oct 27 19:37:30 GNUtoo|laptop: what kind of workaround?= Oct 27 19:37:50 trying that: Oct 27 19:39:11 basically remove the case SND_SOC_BIAS_STANDBY etc... Oct 27 19:39:14 and suspend in all cases Oct 27 19:39:32 same for resume Oct 27 19:39:36 it's worth trying Oct 27 19:40:05 a sec still :) Oct 27 19:40:10 ok Oct 27 19:45:10 I can try it if you want Oct 27 19:45:27 well if you have time sure go ahead Oct 27 19:45:31 ok Oct 27 19:45:38 I'm fighting/enjoying systemtap :) Oct 27 19:45:43 ok Oct 27 19:45:46 GNUtoo|laptop: http://paste.debian.net/140492/ Oct 27 19:46:34 for some reason the third probe does not match and I'm asking on #systemtap Oct 27 19:47:22 ok Oct 27 19:49:00 let me cross compile the kernel Oct 27 19:49:13 will be ready very soon(cleaning it right now) Oct 27 19:52:14 bbs Oct 27 19:54:25 zub, applied. Please update and try it works correctly for you :) Oct 27 19:54:50 thx, I'll try Oct 27 19:56:41 back Oct 27 20:06:29 zub, I'm looking at ecore-evas patch now. Any thoughs you want to comment about it? Oct 27 20:06:49 I think nothing changed in ecore.vapi since 17 Oct, so it should apply right Oct 27 20:07:35 the immediate rationale was the linking issue I've whined about in #e and indeed everywhere, thought regardless of that, I think it makes sense to split it to match the .pc file names' Oct 27 20:07:45 if stuff changes, the patch must fail to apply Oct 27 20:07:48 changed Oct 27 20:08:19 pespin: btw rebuild updated libeflvala, works for me; thanks Oct 27 20:08:44 ok, I'll try to apply ecore-evas one Oct 27 20:08:51 grrr usb0 disapeared Oct 27 20:09:05 I'll use serial Oct 27 20:10:22 GNUtoo|laptop: so, after a lot of work. here's a complete trace Oct 27 20:10:29 GNUtoo|laptop: http://lindi.iki.fi/lindi/openmoko/2.6.39-alsa-resume-bug-2478-trace1.txt Oct 27 20:11:43 GNUtoo|laptop: does this help? Oct 27 20:21:11 zub, shouldn't ecore-evas.deps contain evas pkg? Oct 27 20:21:46 * zub is thinking Oct 27 20:21:48 as it's using Evas stuff in its vapi Oct 27 20:22:15 public Evas.Canvas evas_get(); Oct 27 20:22:18 aaah Oct 27 20:22:22 in that case obviously yes Oct 27 20:22:26 :) Oct 27 20:22:28 I'll add it Oct 27 20:22:32 good that you noticed Oct 27 20:22:36 por favor :) Oct 27 20:23:40 zub, and imo namespace is wrong Oct 27 20:24:14 back Oct 27 20:24:14 well, not necesarily, but we could be done differently maybe Oct 27 20:24:33 you mean the namespace EcoreEvas? Oct 27 20:24:37 yeah Oct 27 20:24:45 arrrg still no usb0 Oct 27 20:24:46 I only split the files, didn't think of the rest :-/ Oct 27 20:24:54 I don't even knwo what is ecore-evas good for Oct 27 20:24:58 I think we could use "namespace Ecore { namespace Evas { } } Oct 27 20:25:28 then vala would write good prefixes automatically afaik Oct 27 20:25:29 so there would be Ecore.Evas instead of EcoreEvas? Oct 27 20:25:34 zub, yeah Oct 27 20:25:47 zub, do you know if we need to change some example/text then? Oct 27 20:25:47 it would solve the prefixes Oct 27 20:25:55 but should ecore-evas be part of ecore? Oct 27 20:26:03 why shouldn't it semantically be Evas.Ecore? :-P Oct 27 20:26:21 zub, well, accordingly to C code no :P Oct 27 20:26:33 [ Oct 27 20:26:36 CCode (cprefix = "Ecore_Evas_", lower_case_cprefix = "ecore_evas_", cheader_filename = "Ecore_Evas.h")] Oct 27 20:27:00 well, there already is Evas namespace, should again Evas be in Ecore too? Oct 27 20:27:22 /etc/rcS.d/S02g_ether.sh: line 88: /etc/modprobe.d/g_ether.conf: Read-only file system and [ 2.835000] s3c2410_udc: debugfs dir creation failed -19 Oct 27 20:27:27 I'll add rw Oct 27 20:27:54 zub, good question ;) Oct 27 20:28:14 I don't know what is it good for, but I don't feel good about creating another-but-different evas Oct 27 20:28:19 it = ecore-evas Oct 27 20:28:38 ah it's there at boot Oct 27 20:28:45 but when xorg starts...it's gone Oct 27 20:30:46 zub, it's a module/backend of ecore or something similar, there are other like ecore-x, ecore-cocoa, ecore-directfb, ecore-wince, etc. Oct 27 20:32:06 we can create a namespace inside Ecore namespace for each fo that modules Oct 27 20:32:32 in that case adding it into Ecore sounds ok Oct 27 20:32:37 Ecore.EcoreEvas? :-/ Oct 27 20:32:43 too complicated I guess Oct 27 20:32:53 zub, do you know if there's some example/test actually checking there are no errors in the vapi? Oct 27 20:33:01 zub, Ecore.Evas Oct 27 20:33:18 mrmoku`, phonefsod now segfault Oct 27 20:33:27 (phonefsod:635): phonefsod-DEBUG: Configuration file read Oct 27 20:33:27 Segmentation fault Oct 27 20:33:30 pespin: in ecore.vala: var ee = new EcoreEvas.Window( "software_x11", 0, 0, 320, 480, null ); Oct 27 20:33:47 ok thanks :) Oct 27 20:33:49 I'll do it over wifi Oct 27 20:34:07 pespin: and two more, but that's all I'm aware of w.r.t. EcoreEvas + tests Oct 27 20:34:14 two more calls, the same file Oct 27 20:34:26 ok I'll try Oct 27 20:34:28 three, now I see :) Oct 27 20:34:32 but that's not much Oct 27 20:35:23 and fsousaged was down Oct 27 20:40:49 zub, nah, namespace conflicts ;) Oct 27 20:41:06 let's leave it as you did it :P Oct 27 20:41:28