**** BEGIN LOGGING AT Thu Oct 29 02:59:57 2009 Oct 29 05:35:24 freesmartphone.org: 03mickey 07specs * r3e7aa345d72b 10/ (3 files in 3 dirs): org.freesmartphone.GSM.SMS: add API for computing how many SMSes necessary to send a text Oct 29 06:04:32 freesmartphone.org: 03mickey 07cornucopia * r3d2471890b87 10/fsogsmd/ (9 files in 3 dirs): fsogsmd: sending arbitrary long SMSes works now transparently Oct 29 06:40:06 what's up with the eject recipe :) Oct 29 06:44:50 this 52 recipes from shr-feed are failing here http://pastebin.ca/1647515 Oct 29 06:45:33 uh, lots of them :) Oct 29 06:46:21 though eject is not in the list, it fails on the do_fetch task.. maybe we need to upload the archive somewhere? Oct 29 06:47:26 rebelThor: those are only from task-shr-feed which aren't included in shr-image already (shr-image is built ok) Oct 29 06:48:08 rebelThor: search irc logs, but IRC mrmoku put archive to sources.shr-project.org or something.. so it should be there Oct 29 06:49:13 JaMa: yep, it's ok http://build.shr-project.org/sources/eject-2.1.5.tar.gz, how come we can't modify the recipe to fetch it on it's own? Oct 29 06:49:25 s/ok/ok/ Oct 29 06:49:28 damn Oct 29 06:49:36 that was an "on" instead of ok Oct 29 06:51:57 rebelThor: recipe is always trying to download from specified mirrors (or maybe only when not found on original SRC_URI), maybe you have that file with wrong checksum in your local download dir? Oct 29 06:53:07 JaMa: don't know, already overwritten it with the new version, however, it alerted for 404s before failing, so I'm guessing it tried all the mirrors and couldn't locate any good ones Oct 29 06:53:44 looks like it only tried to fetch it from geocities then failed Oct 29 06:54:39 so download it manually, put to download dir with md5 sum and it should work for you Oct 29 06:56:27 JaMa: yep, it does, but I was wondering how to save others from the headache ;) Oct 29 08:09:50 hi guys Oct 29 08:09:58 any news on syncing unstable? Oct 29 08:42:29 mrmoku|a`: where is a` ? :). BTW, every time I "make update" it switches back to shr/import. Can we modify the Makefile already to use shr/merge? Oct 29 08:42:39 let's kill shr/import today... Oct 29 08:43:21 and I am too lazy to memorize the make target for only updating shr-unstable :-) Oct 29 09:35:26 actually, no a "make update" keeps my local Makefile mods Oct 29 09:48:21 freesmartphone.org: 03mickey 07cornucopia * r2451a3c97cb8 10/fsogsmd/src/ (3 files in 2 dirs): fsogsmd: show properties in sms w/ type DELIVER Oct 29 10:04:53 can anyone upload tzdata2009o.tar.gz somewhere? :) Oct 29 10:05:27 rebelThor: ask mrmoku to pull oe.dev Oct 29 10:05:38 rebelThor: tzdata2009p is in oe.dev already Oct 29 10:06:01 won't that break everything all over again? :P Oct 29 10:07:14 or cherry-pick for url in `cat checksum.log | grep -B 1 "This package has no entry in checksums.ini, please add one" | grep http:// | sed 's/NOTE: fetch //g'`; do echo | ./checksum.sh $url Oct 29 10:07:18 done Oct 29 10:07:19 sorry Oct 29 10:07:21 python ../dev-old/contrib/source-checker/oe-checksums-sorter.py ../dev-old/conf/checksums.ini > ../dev-old/conf/checksums.ini2; mv ../dev-old/conf/checksums.ini2 ../dev-old/conf/checksums.ini; Oct 29 10:07:43 or cherry-pick ad6f7be4480a96c57b0c3c3395a4857bad99d73e Oct 29 10:13:52 rebelThor: or you update Oct 29 10:14:00 spaetz: to what? Oct 29 10:14:09 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=shr/import&id=267b8f6a49b83ba8ab1748c23222f9534b0b228b Oct 29 10:14:17 shr/import is fixed Oct 29 10:14:37 JaMa: got a working shr/merge image? Oct 29 10:14:44 mind fixing shr/merge too? `coz that's what I'm building Oct 29 10:15:07 Heinervdm: it depends how you define working.. Oct 29 10:15:27 Heinervdm: still sqlite issue.. so frameworkd working only without pim Oct 29 10:16:17 spaetz: oe.dev fixed too http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=ad6f7be4480a96c57b0c3c3395a4857bad99d73e Oct 29 10:16:48 JaMa: i know, i cherry picked rom there Oct 29 10:17:15 JaMa: i'm building an image with glibc and will try if sqlite is working there Oct 29 10:17:17 just modified preferred-shr-versions.inc as well Oct 29 10:21:02 mrmoku|a`: would it be ok to remove tzdata from peferred-shr-versions to always automatically pick up the latest? Oct 29 10:23:56 Heinervdm: have you read whad pb_ said about our eglibc issue? Oct 29 10:24:22 Heinervdm: he found some asm code, optimized for >armv4t in eglibc build before.. Oct 29 10:24:50 Heinervdm: that workaround I commited disabled thumb internetworking, that's why our newer eglibc builds work.. Oct 29 10:25:03 Heinervdm: but maybe not the cause why sqlite doesn't Oct 29 10:25:32 JaMa: ah ok Oct 29 10:25:45 * JaMa doesn't want to rebuild as already built task-shr-feed :) Oct 29 10:26:02 i've commited a patch, so that we can switch between eglibc and glibc with just one vriable Oct 29 10:26:07 Heinervdm: you can check log of #oe - 2 days mickey and pb_ Oct 29 10:27:43 Heinervdm: I've seen it.. good work.. I haven't noticed that (e)glibc is also used in image recipe Oct 29 10:33:22 rebelThor: retry, I cherry-picked the newer tzdata Oct 29 10:33:29 spaetz: thx Oct 29 10:33:44 (although it might be necessary to adapt preferred-shr-versions.inc in addition) Oct 29 10:34:05 I think it might still try to download the old version. trying Oct 29 10:34:56 spaetz: it's downloading 2009p Oct 29 10:36:32 spaetz: I already removed preferred version for tzdata in http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=shr/merge&id=e601ac0b73c79ceda6fdbb1c634744a703e47105 Oct 29 10:36:57 ok, cool. Oct 29 10:37:54 JaMa: is that patch in dev.org.oe as well? Oct 29 10:38:43 seems like it, yes Oct 29 10:46:27 spaetz: patch for preferred-shr-versions? i guess there is still no preferred-shr-versions in oe.dev.. Oct 29 10:48:08 yes, there is: Oct 29 10:48:08 http://cgit.openembedded.net/cgit.cgi/openembedded/tree/conf/distro/include?id=e601ac0b73c79ceda6fdbb1c634744a703e47105 Oct 29 10:48:53 so we're finally really merging with OE? :D Oct 29 10:49:18 rebelThor: that is what shr/merge is all about. getting closer to dev.oe.org Oct 29 10:56:43 i'm booting now shr/merge with glibc Oct 29 10:57:05 JaMa: yay, for getting OE commit access Oct 29 10:57:10 I +1'd you Oct 29 11:06:53 frameworkd segfaults with glibc too... Oct 29 11:15:31 Heinervdm: still in sqlite? Oct 29 11:15:38 yes Oct 29 11:33:57 spaetz: thanks :) Oct 29 12:15:00 np, I don't even know whether I count as OE member. I have commit access, but never really did anything Oct 29 12:15:49 spaetz: as XorA said.. I already sent key to cbrake :) Oct 29 12:16:12 ahh, good :) Oct 29 12:56:30 eglibc-dbg_2.10-r7.2.3_armv4t.ipk has 211MB! I was wandering why it takes so long to install :) Oct 29 12:56:49 maybe because of disabled thumb? Oct 29 13:04:29 why the messing around with glibc? Oct 29 13:06:51 Weiss: sqlite is crashing. and Heinervdm was suspecting that glibc could have done it Oct 29 13:07:00 shooting in the dark, I think Oct 29 13:07:11 spaetz: same problem with glibc Oct 29 13:07:14 so, a newer version of glibc has been switched to? Oct 29 13:07:27 Heinervdm: :-( Oct 29 13:09:40 Weiss: yes.. we have eglibc_2.10 now Oct 29 13:27:13 btw where are packages downloaded before installing? Oct 29 13:27:21 something like /var/lib/opkg/archives? Oct 29 13:28:02 * JaMa hopes that its not tmpfs in memory.. 211MB is almost mem+swap on my neo :) Oct 29 13:31:27 ah /tmp/opkg* Oct 29 13:38:11 how big was the old glibc? Oct 29 13:39:11 Weiss: strange but 401Kb Oct 29 13:39:24 in shr/import Oct 29 13:39:39 I'll check what is included in that 211MB Oct 29 13:40:10 a lot of locale stuff possibly? Oct 29 13:40:31 unpacking now Oct 29 13:41:53 hmm 146M usr/lib/.debug/libc.a Oct 29 13:42:04 static libs are huge Oct 29 13:42:18 that's more to do with the debug data than the staticness Oct 29 13:42:35 the static libc.a isn't much different in size to the shared one, they have basically the same bits in. Oct 29 13:43:08 because (for fairly obvious reasons), libc.so doesn't depend on many other libraries :) Oct 29 13:43:14 right, exactly Oct 29 13:43:47 the libc.a size is increased a bit due to ar format inefficiencies; the .so size is increased a bit because PIC code is slightly bigger. I don't know offhand which effect dominates but I doubt there is more than a couple of percent difference either way. Oct 29 13:44:33 pb__: I mean that static libs werent in old glibc-dbg_2.6.1-r16_armv4t.ipk Oct 29 13:44:50 JaMa: I noticed that a lot of locales were being generated for me, although I only want the en UTF8 ones Oct 29 13:45:00 could that be related? Oct 29 13:45:07 * spaetz has no clue Oct 29 13:45:40 JaMa: oh, they weren't? that's odd, I thought they had always been in there. Oct 29 13:46:02 I could well be wrong about that though, I very seldom install the debug packages myself. Oct 29 13:46:38 pb__: in that ipk built here from shr/import weren't.. Oct 29 13:47:37 spaetz: there are no locales in -dbg package.. so probably not related.. Oct 29 13:49:25 k Oct 29 13:52:23 ah... it's just the -dbg package. is the runtime package a sensible size? Oct 29 13:52:32 Weiss: yes :) Oct 29 13:53:28 good :) Oct 29 13:54:00 1604 KiB /armv4t/libc6_2.10-r7.2.3_armv4t.ipk Oct 29 14:18:35 Hello all, been looking thought the source for libframeworkd-phonegui-efl2 and I've a question of a philosophical nature. Was looking at the SMS interface and wanted to replace the telephone numbers in the message list with the name of the person who was sent or sent the messages, if that name is in opimd of course. Anyhow I looked in contacts code to see how that is done and there seems to be a few levels of calls to opimd and a few callbacks bef Oct 29 14:18:35 ore you have the info you'd need. IF you have a message list of 1,000 messages this could take a while. Oct 29 14:19:47 Arigead: that's quite applied philosophy, it seems ;) Oct 29 14:19:53 Is there a possible argument for caching this info so that you can make a synchronous call to somewhere for the info. Oct 29 14:20:23 PaulFertser: Hi Paul yeh well I got lazy when I saw all those levels and started thinking instead Oct 29 14:21:06 The obvious argument the other way is that if you've an address book of 1,000 names only 10% of those might be in the message list Oct 29 14:21:15 Arigead: hey, laziness is what drives the progress so you're on the right way ;) Oct 29 14:22:18 PaulFertser: I like that idea, I think I could be good at lazy maybe no Olympic standard but I'd certainly compete nationally Oct 29 14:30:04 freesmartphone.org: 03mickey 07cornucopia * rb5934e7100b7 10/fsogsmd/src/lib/atcommand.vala: fsogsmd: secure against null names in sim phonebook Oct 29 15:11:20 Arigead: you probably won't display all members of a list of 1000 on one screen of FR ;-P Oct 29 15:11:51 so the way to go seems quite obvious Oct 29 15:18:30 hello all, can someone explain me or give me a link where i can understand what's happening on SHR (about the merge and all things)? Oct 29 15:27:45 JaMa: no more cookies from you :( :P Oct 29 15:29:19 mrmoku: I'm installing eglibc-dbg for last 2 hours :) Oct 29 15:29:37 JaMa: I was referring to the fact that you can commit yourself now :) Oct 29 15:29:56 mrmoku: opkg is having hard time ar x 211MB package :) Oct 29 15:30:03 hehe Oct 29 15:30:17 mrmoku: I can send shr specific cookies to you and angstrom/spitz directly :) Oct 29 15:30:41 JaMa: nah, just send shr stuff directly too Oct 29 15:31:20 JaMa: I would apply Heinervdm's cookies now and pull org.oe.dev then Oct 29 15:32:00 mrmoku: please apply this one too (to shr/merge) Oct 29 15:32:03 http://patchwork.dev.bearstech.com/patch/347/ Oct 29 15:32:58 mrmoku, built glamo? Oct 29 15:33:19 TAsn: you mean xf86-video-glamo? Oct 29 15:33:53 JaMa, yes. Oct 29 15:34:02 JaMa, Weiss fixed it. Oct 29 15:34:05 TAsn: then you need http://patchwork.dev.bearstech.com/patch/388/ Oct 29 15:34:49 JaMa, that's mrmoku's job, I can't build. :) Oct 29 15:34:59 TAsn: me neither Oct 29 15:35:03 and then probably opkg remove xf86-video-glamo-kms; opkg install xf86-video-glamo; Oct 29 15:35:20 can this ^^^ be automated somehow? Oct 29 15:36:08 JaMa: I'm in desperate need of groff-native Oct 29 15:36:16 otherwise I can't build any of the new x stuff Oct 29 15:36:54 i can remove groff from my buildhost to test yours groff-native.. please commit it and I'll try Oct 29 15:37:15 JaMa: well, it does not work :P Oct 29 15:37:24 mrmoku, I just manually edited makefiles :) Oct 29 15:37:35 TAsn: I read that, yes Oct 29 15:37:35 (I know it's not good enough for the buildhost.) Oct 29 15:37:42 yup :| Oct 29 15:38:30 mrmoku: ok I'll create mine then.. Oct 29 15:41:35 JaMa: trying one more thing now Oct 29 15:42:14 JaMa: http://shr.pastebin.com/mb326269 Oct 29 15:44:06 mrmoku, got a spare second? Oct 29 15:45:38 TAsn: yup Oct 29 15:46:01 mrmoku, is there a new unstable image (and usable :P) ? Oct 29 15:46:08 Sharwin_F: no :( Oct 29 15:46:52 mrmoku, mind editing the gitweb descriptions? Oct 29 15:47:17 TAsn: if I get clear instructions... no ;) Oct 29 15:47:31 I want to prefix ophonekitd's libframeworkd-phonegui-*'s descriptions with "*deprecated*" Oct 29 15:47:38 mrmoku: what's new with unstable? Oct 29 15:47:38 and adding sane description to the rest. Oct 29 15:47:56 mrmoku, as people might get confused (actually already got confused and mailed us about efl2 in ML) Oct 29 15:48:28 TAsn: ok, will add the deprecated which gives you time to paste the sane things for the rest :P Oct 29 15:49:51 TAsn: hmm... ohonekitd is the vala rewrite though Oct 29 15:50:20 mrmoku, well, that's also deprecated Oct 29 15:50:23 ... Oct 29 15:50:31 freesmartphone.org: 03mickey 07cornucopia * r10584363e872 10/libfsobasics/fsobasics/ (smartkeyfile.vala utilities.vala): Oct 29 15:50:31 freesmartphone.org: libfsobasics: smartkeyfile: add write Oct 29 15:50:31 freesmartphone.org: utilities: allow creating files during a call to write() Oct 29 15:52:07 mrmoku, phoneui-apps: The basic SHR phone apps. Oct 29 15:52:22 phoneuid: The SHR phone UI daemon. Oct 29 15:52:53 phonefsod: The SHR FSO phone client. Oct 29 15:53:15 libphone-ui-shr: The basic SHR libphone-ui backend. Oct 29 15:53:34 shr-wizard: The SHR fist time wizard. Oct 29 15:53:34 :) Oct 29 15:53:47 mrmoku: hmm I just removed groff from my buildhost and created a bit more simple groff-native and libx11 compiled fine.. testing libxaw now.. Oct 29 15:54:13 mrmoku: just newer groff groff-native_1.20.1.bb Oct 29 15:56:42 mrmoku: libxaw too Oct 29 15:56:52 mrmoku: so maybe i have cookie for you :) Oct 29 15:57:03 :) Oct 29 15:57:07 mrmoku, http://trac.shr-project.org/trac/ticket/691 Oct 29 15:57:10 is this true? Oct 29 15:57:30 hmm Oct 29 15:57:33 no idea Oct 29 15:57:47 sec, I'll give it a go. Oct 29 15:58:35 TAsn: what about libfso-phoneui.git Oct 29 15:58:41 I can remove that one, no? Oct 29 15:58:48 yes. Oct 29 15:58:50 ok Oct 29 15:58:53 erase the repo completely. Oct 29 15:59:42 bah, not in feed. Oct 29 15:59:46 building on my own.- Oct 29 16:07:53 mrmoku: please try this groff http://pastebin.ca/1647932 (and don't compile groff_1.20.1.. it will fail with hdtbl enabled) Oct 29 16:08:00 mrmoku: it works for me Oct 29 16:08:53 JaMa: 388 vanished? Oct 29 16:09:26 hmm seems so.. Oct 29 16:09:45 but it says its accepted :) Oct 29 16:11:34 hmm Oct 29 16:12:01 probably I added to the bundle with Heinervdm's patches Oct 29 16:12:09 yup Oct 29 16:12:12 ok :) Oct 29 16:12:27 you're so hungry for cookies... Oct 29 16:12:59 opkg just forked and its even worse now.. Oct 29 16:13:37 * mrmoku cookie greedy :P Oct 29 16:13:49 spaetz: I'm not used to pulling before pushing ;) Oct 29 16:14:12 Installing cpp (4.1.2-r14) to root... Oct 29 16:14:15 wth? Oct 29 16:14:23 TAsn: cpp is needed for edje_cc Oct 29 16:14:23 I just installed edje-utils Oct 29 16:14:26 yeah. Oct 29 16:14:27 why Oct 29 16:14:28 ? Oct 29 16:14:29 as preprocessor Oct 29 16:14:36 ffs. Oct 29 16:15:34 woohoo, I hope it also pulls in all the cpp libs Oct 29 16:16:09 it doesn'.t Oct 29 16:16:14 well, c++ libs Oct 29 16:16:14 but even without it it's annoying enough. ;) Oct 29 16:17:20 maybe it's really just preprocessor Oct 29 16:17:32 so that's kinda bearable Oct 29 16:18:15 anyhow, mrmoku, confirmed. Oct 29 16:18:16 we need that. Oct 29 16:18:18 :| Oct 29 16:18:24 I'm assigning this patch to you. Oct 29 16:18:29 mind adding it to shr-task-minimal? Oct 29 16:18:43 mrmoku: :P there are others with commit access Oct 29 16:18:43 hmm Oct 29 16:19:01 expect that to increase when JaMa has access too Oct 29 16:19:18 yup :P Oct 29 16:20:47 mrmoku, ^ Oct 29 16:21:28 mrmoku: please wait with groff-native testing :) Oct 29 16:22:20 yup, cpp is only preprocessor Oct 29 16:22:33 gcc and g++ are compilers Oct 29 16:23:05 gcc actually is gnu compiler *collectionn* ? Oct 29 16:23:27 DocScrutinizer-8, yeah. Oct 29 16:23:31 yup, but i meant binary named gcc ;) Oct 29 16:23:33 they renamed the project a while back. Oct 29 16:24:01 freesmartphone.org: 03mickey 07cornucopia * r10a19faa2598 10/fsogsmd/src/ (5 files in 2 dirs): fsogsmd: misc SMS work Oct 29 16:25:54 * DocScrutinizer-8 still wonders why edje_cc is considered part of minimal Oct 29 16:26:51 mrmoku, any comments? (691) Oct 29 16:27:32 s/part/member/ Oct 29 16:28:03 ~ping Oct 29 16:28:04 ~pong Oct 29 16:28:26 o.O ?? Oct 29 16:28:38 TAsn: I think it should be pulled in by illume then, no? Oct 29 16:28:44 s/O/@/ Oct 29 16:28:45 DocScrutinizer-8 meant: o.@ ?? Oct 29 16:28:47 mrmoku, probably. Oct 29 16:28:51 I'm dumb :) Oct 29 16:28:56 make it a dep Oct 29 16:29:02 not in shr-task. Oct 29 16:29:03 and I think it was... sometime in the past Oct 29 16:29:08 :) Oct 29 16:29:16 we probably have a ticket saying Oct 29 16:29:25 "remove the stupid edje-utils dep from illume" Oct 29 16:29:25 :) Oct 29 16:29:59 please help me out... What exactly was edjie_cc ? Oct 29 16:30:34 DosScrutinizer-8: Ping Oct 29 16:30:43 pong Oct 29 16:31:20 DocScrutinizer-8: edje_cc 'compiles' .edc (efl resource files) into .edj Oct 29 16:31:43 mrmoku: so we need this for a *minimal* system? Oct 29 16:31:58 a minimal system with illume, yes Oct 29 16:32:29 DocScrutinizer-8, illume uses edje_cc Oct 29 16:32:33 duh, always thought minimal ships with precompiled .edj Oct 29 16:32:37 in order to change resource file Oct 29 16:32:43 i.e change backgrounds Oct 29 16:32:46 edit themes Oct 29 16:32:48 shiiiiiit Oct 29 16:32:50 etc Oct 29 16:32:51 DocScrutinizer-8: it does... but apparently changing the background... Oct 29 16:32:53 DocScrutinizer-8, :) Oct 29 16:33:13 that's kinky Oct 29 16:33:31 at least that's consistent Oct 29 16:33:38 DosScrutinizer-8: Hello I missed your reply to my question earlier about retrieving names from phone numbers sorry got distracted. You said that the viewed list would not contain all 1,000 messages which is fair enough but as soon as you scroll you have to then start retrieving more names. When the message list is first populated the name should be inserted instead of number but that's going to take a long time if it's a few calls to opimd and cal Oct 29 16:33:38 lbacks? Oct 29 16:33:43 I know people who would have added a workaround to use resources outside of resource files Oct 29 16:33:48 just for changing backgrounds :) Oct 29 16:35:58 Arigead: the idea is to populate the invisible 990 entries immediately after displaying first 10 fully expanded list members, rather than start to populate it when user actually wants to scroll Oct 29 16:37:53 DosScrutinizer-8: Got to think upon that. It sounds good in theory anyhow. I'll look at it later I've to go now but thanks for the advice. Oct 29 16:38:09 yw Oct 29 16:39:33 Arigead: afaik opimd-messages (or contacts?) does a similar thing Oct 29 16:40:22 at least according to the scrollbar on right side that suggests a ever growing list each time you scroll down a little Oct 29 16:40:40 JaMa: have the same problem with your groff Oct 29 16:40:42 JaMa: http://shr.pastebin.com/d4423e41 Oct 29 16:41:22 JaMa: could you try if tmp/staging/x86_64/usr/bin/groff -v works for you? Oct 29 16:43:27 hmm something is wrong .. i have no groff in tmp/staging/x86_64/usr/bin/ and then libx11 and libxaw is probably ok, because they check if groff is in your system Oct 29 16:44:21 checking for groff... no Oct 29 16:44:25 and then its ok with that Oct 29 16:44:47 hmm Oct 29 16:46:16 DocScrutinizer-8: btw. how is alsa work proceding? can we implement a volume slider for the call screen in a sane way? Oct 29 16:46:44 probably yes Oct 29 16:47:39 any hint on how? Oct 29 16:47:46 for actual adjustment of the mixer setting (realtime) you need to interface alsalib anyway Oct 29 16:48:21 TAsn: ^^^ any thoughts on this? Oct 29 16:48:41 mrmoku, yes. Oct 29 16:48:46 phoneui_set_volume Oct 29 16:48:47 you should execute a call to a helper function prior to creating the slider. this function will return the name of the actual control to use Oct 29 16:48:51 phoneui_mute Oct 29 16:49:11 and such, i.e libphone-ui-shr will not care about those kind of things Oct 29 16:49:17 libphone-ui will do all the thinking Oct 29 16:49:21 starting from something hackish Oct 29 16:49:29 and soon, doing something smart. Oct 29 16:49:38 (iirc PaulFertser and DocScrutinizer-8 are working on a sound daemon) Oct 29 16:49:58 sound daemon? Oct 29 16:50:06 i think they'll disagree ;) Oct 29 16:50:06 after a reasonable timeout of idle on slider (user stopped fiddling) you need to call same helper function with a "save" parameter to make the setting persistent Oct 29 16:51:14 there is nowork on a sound daemon Oct 29 16:51:38 ok. Oct 29 16:51:45 for some reason I remembered something about that. Oct 29 16:52:25 hi shr people,what's the variable to prevent building of the 3d acceleration... Oct 29 16:52:33 ACI is assuming there'll be some sort of extended resource management in fso - similar to current resource handling - which can do the arbiting Oct 29 16:53:41 TAsn: they are working on audio handling logic, not implementing another useless sound daemon :P Oct 29 16:53:58 i c. Oct 29 16:54:42 mrmoku: so lets try to disable docs in libxaw and see what happen in libx11 :) Oct 29 16:54:48 mrmoku: cookie sent Oct 29 16:54:53 some guys are (finished) working on a way to rename controls, so we eventually could use that to get a reasonable name for arbitrary controls. Until then, the aforementioned call of a helper function (actually a script) is the only way to get names of the control to use Oct 29 16:56:43 basically we got two battlefields: pcm devices and (volume etc) controls and storage of their values Oct 29 16:56:46 JaMa: ok, thanks Oct 29 16:57:20 ok if no one respond I'll look myself Oct 29 16:57:57 ACI is about pcm devices automagically restoring the control settings needed (rather than the app doing this by explicit call to alsactl restore foo) Oct 29 16:58:41 ah seems hardcoded Oct 29 16:59:36 further ACI-MKII is about arbiting hw resources between mutually exclusive pcm devices and apps opening them Oct 29 16:59:52 for this we need FSO resource management Oct 29 17:00:14 for mark-I we can go ahead right now Oct 29 17:00:30 * mrmoku dinner Oct 29 17:11:57 heyho Oct 29 17:27:02 mickeyl, any comments on opimd_redesign? :) Oct 29 17:27:19 mickeyl, sorry, but I'm really anxious to get rid of this annoying uri design. Oct 29 17:29:36 mrmoku|away, btw, I want to write a something that'll manage sound, so we'll manage UI sound (rings, speaker/headset/bt/etc, volume and everything) in libphone-ui. what do you think? Oct 29 17:37:13 mrmoku|away, anyhow, I don't remember if you did it already or not, but we should start using phoneui in task-shr-minimal instead of the other crap (in the test images you guys are building as well) and change frameworkd-config-shr to use SQLite-Messages by default. Oct 29 17:37:25 TAsn: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=MixerAPIalsalib http://www.mail-archive.com/alsa-devel%40lists.sourceforge.net/msg07989.html watch date!! Oct 29 17:38:22 ouch. Oct 29 17:38:40 those if I get them correctly, their idea is the only reasonable way Oct 29 17:38:55 I mean, that's the only way to work in a generic way. Oct 29 17:40:51 hmpf Oct 29 17:40:57 also see alsamixer --help on FR, and http://archpub20.cs.ccu.edu.tw/cgi-bin/dwww?type=file&location=/usr/share/doc/alsa-utils/changelog.gz /abstract Oct 29 17:41:19 somebody here who are fit in decoding arm assembler? Oct 29 17:41:28 the -a option that is Oct 29 17:42:24 which still isn't even in the manpages :-( Oct 29 17:45:44 TAsn: would you like to tweak alsamixer to pass an option like "-C 2,5,13" to only show the controls 2, 3, and 13 here Oct 29 17:47:12 TAsn: maybe even -C 2:"MyNameX",5:"MyNameY" Oct 29 17:49:00 or a generic (python?)app doing the same, just not with ncurses but rather cool sliders in a xwindow Oct 29 17:55:01 hi guys Oct 29 17:58:59 TAsn: seems alsa-scenario-manager is trying to tackle the issue with aliases, creating virtual controls that interface to physical ones Oct 29 17:59:22 still it's far from reaching usable state it seems Oct 29 18:00:14 DocScrutinizer-8, aliases sounds like a feasible solution. Oct 29 18:00:32 as for alsamixer, I don't think it's that useful. Oct 29 18:00:44 but there already are python apps that do exactly that. Oct 29 18:00:52 yep, and I was desparately searching for a way to do exactly this with current alsa Oct 29 18:01:07 now I know better, there isn't any yet Oct 29 18:01:13 actually, I think my biggest problem lies in different platforms. Oct 29 18:01:28 I need a consistent way to control volume Oct 29 18:02:57 so how about following my suggested path to ask a helper function about which real control is used to do virtual "master phone volume", and simply use alsalib to open and control that particular control then? Oct 29 18:03:36 DocScrutinizer-8, it's more complicated than that, but that's exactly what I'll do. Oct 29 18:03:38 the helper function should be implemented next to alsa (scenario) foo, possibly as a script Oct 29 18:03:59 (more complicated) there are a couple of relevant amplifiers for each "sound path" Oct 29 18:04:40 DocScrutinizer-8, we should definitely ask mickeyl to add it to fso, as it's completely fso's job. Oct 29 18:04:41 I know, but you definitely do not want to expose all of them to user Oct 29 18:04:54 there's always *one* main control Oct 29 18:05:05 DocScrutinizer-8, of course. Oct 29 18:05:09 I was talking about internal design Oct 29 18:05:17 thats why a virtual control does not map to exactly one physical Oct 29 18:05:37 (maybe we want to up the volume up to max, which means, in several places) Oct 29 18:05:40 I really discourrage doing slider action over dbus, too much overhead Oct 29 18:05:53 larsc, this sounds like a cool thing. Oct 29 18:06:12 DocScrutinizer-8, I don't mind handling sound UI internally in libphone-ui Oct 29 18:06:17 as it is UI Oct 29 18:06:20 TAsn: (several places) exactly NOPE Oct 29 18:06:22 and I think that's the proper place. Oct 29 18:06:46 but fso should give me proper interface Oct 29 18:06:55 at least to get the correct alsa stuff. Oct 29 18:07:41 there's always ONE phy control to do user adjustments. Everything else is config data that never should change, once it's set correctly Oct 29 18:07:59 okie. you may be right. Oct 29 18:08:06 I'm no expert in this field. Oct 29 18:08:38 (fso should give) agree, that's duty of fso audio resource control in ACI-MK2 Oct 29 18:09:46 until then I suggest to simply execute an external executable (whatever script, ELF...) and read the stdout to get the control number of the control that does what you asked for Oct 29 18:10:15 like Oct 29 18:10:32 DocScrutinizer-8: user should control only one alsa control? Oct 29 18:10:47 $ help-me-alsa --getnumof gsm-earpiece Oct 29 18:10:54 > 7 Oct 29 18:11:08 lindi-: yes, absolutely Oct 29 18:12:09 TAsn: ^ then you open a slider for control #7 and name it Earpiece-Volume Oct 29 18:13:04 TAsn: after user fiddled with the slider, you do Oct 29 18:13:16 $ help-me-alsa --save gsm-earpiece Oct 29 18:13:50 to make the new setting persistent (if that's what you want to do) Oct 29 18:14:11 otherwise for next call volume will be restored to old value Oct 29 18:14:42 DocScrutinizer-8: hmm. on my desktop and laptop I need to change two alsa controls to get full audio scale from very silent to very loud Oct 29 18:14:51 DocScrutinizer-8, yeah, cool enough. Oct 29 18:15:04 DocScrutinizer-8: and it's always annoyed me that the volume keys in keyboard are bound to change only one Oct 29 18:15:46 lindi-: so why can't you get the whole range from 0 to 100% by using only one? Oct 29 18:15:59 DocScrutinizer-8: well 1% is too loud Oct 29 18:16:12 huh? Oct 29 18:16:22 DocScrutinizer-8: in some cases it's too loud :) Oct 29 18:16:33 DocScrutinizer-8: cause hw isn't build that way Oct 29 18:16:39 so your range isn't reaching down to 0? Oct 29 18:16:48 DocScrutinizer-8: the steps are too large Oct 29 18:17:24 DocScrutinizer-8: actually alsamixer only allows 0, 3, 6, .. on my desktop Oct 29 18:17:27