**** BEGIN LOGGING AT Mon Jul 25 02:59:57 2011
Jul 25 05:47:01 <mrmoku> DocScrutinizer: what I ment was more about having two modes... Phone and Media publically visible
Jul 25 06:02:25 <DocScrutinizer> mrmoku: I don't see how this differs from a path for a device that exclusively allocates a mixer element so another path can't succeed
Jul 25 06:03:21 <DocScrutinizer> mrmoku: I don't see any special handling needed for this
Jul 25 06:07:25 <mrmoku> DocScrutinizer: yup, agree
Jul 25 06:07:49 <DocScrutinizer> of course the amixer binary (sth I always suggested to keep as a separate entity called via system() ) would look a bit different than on a "normal" system - it probably would have to be a script that does >># echo  "foobarbooo" >/sys/prephonecontrol
Jul 25 06:07:59 <mrmoku> DocScrutinizer: would something like a virtual userspace alsa card feeding those scripts to the kernel be feasable?
Jul 25 06:08:10 <mrmoku> ah
Jul 25 06:08:25 <mrmoku> yup
Jul 25 06:15:28 <DocScrutinizer> if however you want to include the amixer functionality into fsoaudiod and call mixer control changes via alsalib directly, the your API interface moved closer to hardware and you'd probably really need a virtual alsa soundcard to convert alsa control meddling to >># echo  "foobarbooo" >/sys/prephonecontrol
Jul 25 06:16:19 <DocScrutinizer> or you spoil the beauty of a clearly structured design and have #ifdef in fsoaudiod
Jul 25 06:17:19 <DocScrutinizer> if you go that way, then prepare to have a LOT of #ifdefs in there, possibly a new set for each new platform
Jul 25 06:17:37 <mrmoku> definitely not
Jul 25 06:18:00 * mrmoku distastes #ifdefs being used too much
Jul 25 06:18:10 <DocScrutinizer> yeah, there are no #ifdefs in vala eh?
Jul 25 06:18:25 <DocScrutinizer> ;-D
Jul 25 06:25:18 <mrmoku> :P
Jul 25 06:31:53 <larsc> i guess what you want is alsa ucm
Jul 25 06:32:17 <mrmoku> hmm... use case manager
Jul 25 06:33:13 <mrmoku> larsc: interesting
Jul 25 06:33:17 <DocScrutinizer> looked into it cursory, didn't buy me on first second
Jul 25 06:36:36 <mrmoku> larsc: did it manage to hit mainline?
Jul 25 06:39:12 <larsc> yes
Jul 25 06:39:27 <larsc> it is part of libalsa
Jul 25 06:39:28 <larsc> iirc
Jul 25 06:43:43 <mrmoku> ok
Jul 25 06:44:11 <mrmoku> DocScrutinizer: looks like it is trying to solve the same problems though
Jul 25 06:44:14 <JaMa> mrmoku: hi, did you update your shr-chroot?
Jul 25 06:44:47 <mrmoku> JaMa: yup
Jul 25 06:45:07 <mrmoku> JaMa: failed to build file-nativ iirc
Jul 25 06:45:22 <mrmoku> even after clening thr tc
Jul 25 06:45:35 <JaMa> mrmoku: can you try: scp shr@shr.bearstech.com:~/shr-chroot/conftest.c .
Jul 25 06:45:42 <JaMa>  gcc -O2 conftest.c
Jul 25 06:45:54 <mrmoku> ok in some min
Jul 25 06:45:59 <JaMa> thanks
Jul 25 06:48:43 * JaMa trying to scp tar.gz to compare git checkouts
Jul 25 06:50:00 <DocScrutinizer51> mrmoku: larsc: do you have sth better than mere lkml patch mails? maybe some manpages or even a design paper?
Jul 25 06:56:38 <larsc> not really, documentation on it seems sparse
Jul 25 06:58:27 <DocScrutinizer51> yeah, one of my concerns. Too fresh, not mature yet. AIUI they are planning for this since 2003 and several times started and binned sth
Jul 25 07:01:21 <mrmoku> DocScrutinizer51: maybe thisone http://www.slimlogic.co.uk/2009/02/alsa-use-case-manager/
Jul 25 07:02:39 <mrmoku> JaMa: with the chroot host gcc?
Jul 25 07:02:52 <mrmoku> gcc version 4.6.1 (Gentoo 4.6.1 p1.0, pie-0.4.5) 
Jul 25 07:03:44 <JaMa> yup with this gcc
Jul 25 07:03:46 <mrmoku> OE @ ~ $ gcc -O2 conftest.c 
Jul 25 07:03:46 <mrmoku> /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crt1.o: In function `_start':
Jul 25 07:03:49 <mrmoku> (.text+0x12): relocation truncated to fit: R_X86_64_32S against symbol `__libc_csu_fini' defined in .text section in /usr/lib64/libc_nonshared.a(elf-init.oS)
Jul 25 07:03:52 <mrmoku> and some more
Jul 25 07:03:56 <JaMa> ok so the same as buildhost
Jul 25 07:05:04 <JaMa> I've compared all 3 files from error message and they are the same.. now I'm sending whole .tar.gz of chroot to compare all
Jul 25 07:08:59 <DocScrutinizer51> mrmoku: yes this is a nice page, it gave me the impression in 40 lines that UCM is also not dealing with additive concurrent pathes. What they call usecases seems just another word for scenario
Jul 25 07:27:46 <Ainulindale> mrmoku: camping site near Paris?
Jul 25 07:27:48 <Ainulindale> mrmoku: Hmpf
Jul 25 07:28:05 <Ainulindale> I don't do that kind of stuff but I'd look on the web if I were you :-)
Jul 25 07:41:05 <Ainulindale> mrmoku: ping if you need help
Jul 25 07:41:12 <Ainulindale> mrmoku: and ping if you want to eat at home you'll be welcome
Jul 25 07:54:28 <mrmoku> Ainulindale: ok... already found some :-)
Jul 25 07:54:44 <mrmoku> Ainulindale: all fine otherwise?
Jul 25 07:55:20 <mrmoku> TAsn: hmpf... e segfaulted already three times :/
Jul 25 07:56:30 <Ainulindale> mrmoku: all fine, as ever
Jul 25 07:56:40 <Ainulindale> mrmoku: just looking for another job yet again
Jul 25 07:57:05 <mrmoku> heh, changing jobs like your underware :-P
Jul 25 07:57:57 <Ainulindale> nah
Jul 25 07:58:04 <Ainulindale> I've been there almost 2 years and getting bored
Jul 25 07:58:45 <mrmoku> ok
Jul 25 07:58:50 <mrmoku> time passes....
Jul 25 07:58:53 <mrmoku> fast
Jul 25 07:58:54 <Ainulindale> Yep
Jul 25 07:59:11 <Ainulindale> These days I'm interested in editors
Jul 25 07:59:34 <Ainulindale> Maybe it's a bad thing, we'll see
Jul 25 07:59:40 <mrmoku> editors like vim... or like editing a book?
Jul 25 08:00:20 <Ainulindale> heh
Jul 25 08:00:30 <Ainulindale> editors such as IBM, Oracle, ...
Jul 25 08:02:40 <PaulFertser> Ainulindale: hey hey hey :)
Jul 25 08:02:46 <PaulFertser> Ainulindale: what do they edit? ;)
Jul 25 08:03:26 <mrmoku> PaulFertser: patent applications ;-)
Jul 25 08:03:37 <PaulFertser> Oh my
Jul 25 08:03:53 * PaulFertser seeks a place to hide
Jul 25 08:05:30 <PaulFertser> For those who missed this description of one of the influential patent-related cases: http://jonahprobell.com/lexra.html (how it happened MIPS is where it is now).
Jul 25 08:05:36 <Ainulindale> PaulFertser: hey :-)
Jul 25 08:05:52 <Ainulindale> mrmoku: Meh, anyways, in my field there's no open source alternative
Jul 25 11:46:44 <CIA-82> SHR: 03Martin.Jansa 07shr-chroot * r9a998912ba2f 10/ (415 files in 22 dirs): rebuild toolchain with more generic flags
Jul 25 12:20:24 <JaMa> mrmoku: shr-chroot fixed by last commit
Jul 25 12:57:24 <mrmoku> JaMa: great
Jul 25 12:57:29 * mrmoku updates
Jul 25 13:41:11 <angelox|laptop> Hi everyone
Jul 25 13:43:27 <pespin> hi :)
Jul 25 13:52:03 <mrmoku> hi pespin 
Jul 25 13:52:10 <mrmoku> pespin: and you won :-P
Jul 25 13:53:16 <pespin> mrmoku, what did I win? lots of money? :D
Jul 25 13:53:55 <mrmoku> pespin: no... probably another free gadget next year ;)
Jul 25 13:54:18 <pespin> mrmoku, wow how's that? hahaha
Jul 25 13:54:49 <pespin> I was out this week with the choir so I didn't get last news :P
Jul 25 13:55:35 <mrmoku> pespin: mwc will stay at barcelona for at least another year
Jul 25 13:55:51 <pespin> oh nice! :D
Jul 25 13:58:54 <pespin> is there some news from shr? JaMa is back as I can see :)
Jul 25 14:01:17 <mrmoku> pespin: not much
Jul 25 14:01:24 <mrmoku> actually nothing (at least from my side)
Jul 25 14:01:54 <pespin> np, it's holidays time :P
Jul 25 14:03:08 <mrmoku> holidays still ahead :)
Jul 25 14:03:15 <mrmoku> it's daywork time :/
Jul 25 14:08:43 <pespin> I hope you have good weather there now anyway :)
Jul 25 14:19:35 <mrmoku> pespin: so so ... raining a lot these days
Jul 25 14:20:04 <mrmoku> pespin: did you tesch the kids some nice things too?
Jul 25 14:20:20 <mrmoku> like... foss rules? :)
Jul 25 14:22:29 <pespin> I had enough with surviving better than teaching things to them hehe
Jul 25 14:23:13 <pespin> btw, I sang Lobgesang from Mendelssohn this week, it was quite fun to sing all of it in german :P
Jul 25 14:25:31 <pespin> does someone know if gnutoo had success at implementing bluetoothd process start when requesting Bluetooth resource?
Jul 25 14:28:50 <mrmoku> pespin: I don't remember the details, but I think yes
Jul 25 14:29:04 <pespin> uh great to hear
Jul 25 18:03:04 <angelox|laptop> -0 
Jul 25 18:03:27 <angelox|laptop> wopps,sorry
Jul 25 19:34:44 <DocScrutinizer> mrmoku: I rechecked ALSA UCM
Jul 25 19:34:48 <DocScrutinizer> mrmoku: :-S
Jul 25 19:35:14 <DocScrutinizer> mrmoku: just another abstraction layer over alsactl
Jul 25 19:35:44 <DocScrutinizer> they are more or less exactly duplicating our former scenario concept
Jul 25 19:36:56 <DocScrutinizer> you could in fact consider alsaucm a competing implementation of a scenario based fsoaudiod
Jul 25 19:38:48 <DocScrutinizer> I'm all but excited about the whole thing, and spotting >>author Liam Girdwood; Stefan Schmidt; Jaroslav Kysela; Justin Xu<< in the file headers makes me wonder how they could fail so epically
Jul 25 19:40:50 <DocScrutinizer> and yes, it's indeed the N-th take on exactly same idea of an additional abstraction layer that lingers around since dunno 2003?
Jul 25 19:49:42 <mrmoku> DocScrutinizer: ok :P
Jul 25 19:51:43 <DocScrutinizer> there's exactly one nice thing in the whole contraption: renaming of controls aiui, which also yields the option to query alsaucm about which control is your current master control
Jul 25 19:52:26 <DocScrutinizer> I tried to tackle this topic (together with larsc IIRC) some 1 year ago
Jul 25 19:52:44 <DocScrutinizer> as our hw controls are completely ill-named
Jul 25 19:53:18 <mrmoku> yeah, though every control renaming breaks userspace...
Jul 25 19:53:29 <DocScrutinizer> anyway fsoaudiod might well learn to answer a dbus inquiry about "what's master named like?"
Jul 25 19:53:49 <DocScrutinizer> mrmoku: that's actually not completely true
Jul 25 19:54:00 <DocScrutinizer> (userspace breakage)
Jul 25 19:54:11 <mrmoku> I remember scenarios not working anymore
Jul 25 19:54:20 <mrmoku> that would be the same for amix ones, right?
Jul 25 19:54:21 <DocScrutinizer> you can have aliases, you can still have same numbering aka numeric ID
Jul 25 19:54:50 <DocScrutinizer> plus there's simple and complex names which already differ
Jul 25 19:55:16 <DocScrutinizer> amixer controls vs amixer scontrols
Jul 25 19:56:35 <DocScrutinizer> anyway if kernel devels were equally reluctant and cautious about renames of /sysfs as they obviously love to be about ill-named mixer controls, our life would be somewhat easier
Jul 25 19:56:38 <DocScrutinizer> ;-P
Jul 25 19:57:38 <DocScrutinizer> in the end all boild down to: an app that uses hardcoded alsa names is broken by design no excuse whasoever
Jul 25 19:57:54 <DocScrutinizer> boils*
Jul 25 20:00:00 <DocScrutinizer> your dialer app CAN NOT know about all possible future headsets and acme-USB-soundcards and the device and control names they introduce. So hardcoding is a fail from start
Jul 25 20:00:59 <DocScrutinizer> any app breaking and needing a patch and recompile due to a ALSA control name change - well, it deserved it ;-P
Jul 25 20:01:55 <mrmoku> DocScrutinizer: in our case it was not hardcoded in apps, but in alsactl scenarios... and yes... sysfs renaming was even more painfull for sure :/
Jul 25 20:04:51 <DocScrutinizer> the app has exactly two valid ways to go - for all I can see now: either A) offer a config option, possibly even in GUI, to select which real control is offering the functionality wanted and so gets used for that "master volume headset". Or B) ask fsoaudiod what is the real name/complex_name/numeric_ID of the control offering the abstract function "Master headset volume control"
Jul 25 20:05:40 <DocScrutinizer> mrmoku: for alsactl scenarios: DUH those are *config* files, so what's the fuss about "breaking userland"??
Jul 25 20:06:46 <DocScrutinizer> the scenarios need to be and always were carefully crafted to match the particular hw and OS version and system components
Jul 25 20:06:56 <mrmoku> DocScrutinizer: it broke configuration of the userspace then
Jul 25 20:07:08 <DocScrutinizer> :shrug:
Jul 25 20:07:13 <DocScrutinizer> couldn't care less
Jul 25 20:07:15 <mrmoku> DocScrutinizer: not different to the sysfs problems... 
Jul 25 20:07:59 <mrmoku> at least IIRC after the _first_ sysfs fiddling those things have been made configurable very fast by mickeyl :-P
Jul 25 20:09:32 <DocScrutinizer> whining about "please keep the name 'sidetone playback volume' as otherwise we'd need to run sed 's/sidetone playback volume/GSM mic sensitivity' over all our scenario config files" - honestly makes me giggle
Jul 25 20:13:33 <DocScrutinizer> it feels to me like tagging the switch in your garage "VW wiper motor forward / reverse" rather than "door open/close" - rationale: the electric door opener DIY kit I bought was based on a VW wiper motor
Jul 25 20:13:34 <mrmoku> DocScrutinizer: have fun giggling then ;) The problem is not doing that change... but knowing the change... Those changes have been badly communicated by the kernel devs
Jul 25 20:14:30 <mrmoku> DocScrutinizer: and silently breaking is bad :/
Jul 25 20:14:37 <DocScrutinizer> AIUI ther were no changes as suggested by me - ever
Jul 25 20:15:13 <mrmoku> not talking about your changes :)
Jul 25 20:15:42 <DocScrutinizer> but honestly I quit this discussion, it's all up to you. I documented the *right* names in wiki, for GTA02
Jul 25 20:29:32 <CIA-82> freesmartphone.org: 03angelo 07angelox/testing * reec003f92b17 10aurora/aurora-applications/ (5 files in 4 dirs): aurora-applications: adjust Makefile for news pages into settings app
Jul 25 20:29:32 <CIA-82> freesmartphone.org: 03angelo 07angelox/testing * rba9de137b104 10aurora/aurora-applications/app-settings/Makefile.am: Merge branch 'angelox/testing' of git.freesmartphone.org:aurora into angelox/testing
Jul 25 22:17:37 <GNUtoo|laptop> where's [RUI] ?
Jul 25 22:34:38 <pespin> GNUtoo|laptop, hi :)
Jul 25 22:35:02 <GNUtoo|laptop> pespin, hi
Jul 25 22:37:16 <pespin> GNUtoo|laptop, did your bluetoothd work finish in upstream fso? :)
Jul 25 22:38:31 <GNUtoo|laptop> some of it finished upstream(launching bluetoothd)
Jul 25 22:38:35 <GNUtoo|laptop> some of it finished here:
Jul 25 22:38:57 <GNUtoo|laptop> http://wiki.freesmartphone.org/index.php/Implementations/fsoaudiod/RoutingUsecases
Jul 26 01:06:45 <tmzt> any possiblity of a qwerty board/case for gta04
Jul 26 02:51:41 <DocScrutinizer> who was asking about the uSD not working coreectly at 32GB?
Jul 26 02:52:32 <DocScrutinizer> I just heard for maemo kernel there's a kernel patch to make 32GB Kingston behave, other brands work OOTB. So maybe the problem on GTA02 was same root cause?
**** ENDING LOGGING AT Tue Jul 26 02:59:56 2011