**** BEGIN LOGGING AT Tue Oct 12 02:59:57 2010 Oct 12 05:19:23 ogra, around/awake yet ? :) Oct 12 05:20:51 He's typically a couple more hours. Oct 12 05:20:59 persia, ahh ok, thanks :) Oct 12 05:23:04 Find yourself at a loss during the pause-between-cycles? Oct 12 05:23:33 persia, not at all :) plenty todo wrt unity-efl Oct 12 05:23:48 persia, but, I do need to discuss something with him Oct 12 05:23:56 Ah, I can't help with that then. Oct 12 05:24:01 hehe yea Oct 12 05:48:11 ogra, when you get online, please drop me a PM. Need to discuss a few things with ya, thanks :) Oct 12 06:51:31 sebjan: Do you know who Misael Lopez Cruz is? Oct 12 07:09:19 lag: he is a TIer working on audio (don't know if he still works on audio, but at least he used to) Oct 12 07:10:11 sebjan: Does he still work for TI? Oct 12 07:10:22 sebjan: I'm wondering if it's worth asking him to the session Oct 12 07:13:12 lag: I don't know... best to ask Liam or Margarita Oct 12 07:13:32 Sure, thanks Oct 12 07:35:57 ehlo # Oct 12 08:10:35 ogra: hi... fyi: just sent you an email... Oct 12 08:49:53 vstehle: http://gitorious.org/croco Oct 12 09:13:57 vstehle what do you want to know about it? Oct 12 09:48:52 hi Oct 12 09:49:33 does anyone has some experience of encoding video to h264 on arm processor. with ffmpeg or any other solution (which may use dps as well if necessary, etc) ? Oct 12 09:50:43 kornel`, What question would you ask if someone replied "Yes" to that? Oct 12 09:51:47 is it possible to encode a live stream with an arm (with neon) processor realtime? and if so, what quality? Oct 12 09:52:35 depends on cpu, method used Oct 12 09:53:03 i would use arm cortex a8 Oct 12 09:53:20 how much does dsp matters? Oct 12 09:53:23 I'm not sure our encoders are NEON-enabled Oct 12 09:53:38 kornel`: there is no such cpu as "arm cortex a8" Oct 12 09:53:40 kornel`, DSP only matters if there are kernel drivers or encoder-specific drivers for that DSP. Oct 12 10:03:33 ndec, and i answered it :) Oct 12 10:04:18 ok thanks for answers Oct 12 10:05:04 kornel`, Just as summary, it's known possible for some chips, at some resolutions. It's unlikely we have a wide-enough body of experience to tell you whether any specific combination works. Oct 12 10:05:34 persia: right i will buy some and triing :) thanks! Oct 12 10:06:35 kornel`, Good luck. My recommendation is to get one from a vendor that has open encoders that are known to meet your application requirements. The SoC vendors usually are happy to explain just how cool each chip is. Oct 12 10:40:35 persia: yeah, like nvidia saying they don't need neon because their soc is awesome :P Oct 12 10:41:16 armin76, might be though: doesn't it support CUDA or something? Oct 12 10:41:54 cuda on arm? weird Oct 12 10:42:51 lool: Thanks! suihkulokki: I want to try croco on top of qemu/pbuilder, to speedup armel builds on PC. I would like to use the cross-compiler on the PC transparently instead of the qemu/armel gcc. This is to build Ubuntu packages. I have had no luck so far with xdeb. Google did not return much about croco, that's why I asked. Oct 12 10:46:31 vstehle: distcc will do work Oct 12 10:47:19 hrw: I thought about that; less setup on PC, but more intrusive on package (need to override the compiler command, I guess). Oct 12 10:51:04 or add one dir to PATH Oct 12 10:52:06 armin76, Why? the code runs on the GPU anyway: CPU architecture ought be irrelevant. Oct 12 10:59:37 * hrw -> food Oct 12 11:02:36 amitk, I had a chance to play with your kernel sources this weekend, but unpacking the 2.6.28 /proc/config.gz and `make oldconfig` still asked me *lots* of questions, including some about which boards to support. Do you have any recommendations for the config for a Netwalker? Oct 12 11:03:05 vstehle: You can use the hardening-wrapper trick to workaround this limitation Oct 12 11:03:26 persia: start with mx51_defconfig and add compile-in support for the efikamx Oct 12 11:03:50 amitk, So I don't care about any of the options that were set on the Netwalker for the old kernel/ Oct 12 11:04:03 s:/:?: Oct 12 11:04:58 persia: since all the HW doesn't yet work, no we don't care about the netwalker options ATM. Oct 12 11:06:11 Heh, fair. I'll try it with the mx51_defconfig, and see what works or doesn't. if I have screen, keyboard, WiFi, MTD, and SD, I'm sufficiently happy. Oct 12 11:10:12 persia: you'll get serial and ethernet now. The linaro kernel might get the mmc/sd patches too. Wifi is WIP. Oct 12 11:10:32 Oh. Since my hardware has no serial or ethernet, that's not very useful. Oct 12 11:13:02 persia: what wifi does it have? Oct 12 11:17:05 armin76, I'm not sure precisely: something that uses "ks7010_sdio" Oct 12 11:18:17 yuck Oct 12 11:18:31 Why? Oct 12 11:19:01 just curious Oct 12 11:19:12 No, why "yuck"? Oct 12 11:19:13 ah, its a renesas chipset Oct 12 11:19:20 And this is bad because ... ? Oct 12 11:19:22 oh, because it didn't ring a bell at all Oct 12 11:20:02 * persia doesn't usually see "yuck" used to mean "never heard of it" and wanders off, no longer concerned Oct 12 11:20:04 didn't know that renesas did wifi chips :) Oct 12 11:20:15 persia: ks7010_sdio is kernel module? Oct 12 11:20:56 hrw, No, kernel module is ks79xx_sdio Oct 12 11:21:22 amitk, Actually, before I give up, are there any tests that I could perform using your kernel that you'd find useful, given no ethernet and no serial? Oct 12 11:22:34 persia: probably not, just wait some more to get the rest of the patches in place.. Oct 12 11:23:14 amitk, OK. Please let me know if I can help with testing, as I'll be able to make time for it fairly freely between now and the beginning of April. Oct 12 11:55:20 ogra: does the ac100 have a temperature sensor? Oct 12 13:58:07 Hmm Oct 12 13:58:20 I've been looking whether extras.ubuntu.com is disabled on ARM or not Oct 12 13:58:21 it seems not Oct 12 13:58:36 does someone confirm that extras.ubuntu.com shows up in sources.list after an Ubuntu install on ARM? Oct 12 13:59:08 It isn't in the preinstalled images sources.list, just the live images. Oct 12 13:59:23 And yes, I see it on dove. Oct 12 14:01:08 GrueMaster: Does it work when you apt-get update? Oct 12 14:01:13 GrueMaster: I'd expect some APT errors Oct 12 14:01:23 Yes, I get errors. Oct 12 14:01:34 GrueMaster: ah, is this reported somewhere already? Oct 12 14:01:53 Apparently, it isn't limited to armel. It was discussed a few days ago on #u-release. Oct 12 14:02:04 I checked this morning, and saw that the keyring was built on armel, seeded on armel, and that the apt-setup/extras setting was off unless preseeded to true, which is the case in all desktop images Oct 12 14:02:13 GrueMaster: Ok thanks Oct 12 14:02:50 o/ Oct 12 14:03:03 lag, isnt it in 1h ? Oct 12 14:03:19 UTC != GMT Oct 12 14:03:20 (unless date -u lies to me) Oct 12 14:03:34 oh, you sheduled it for GMT ? Oct 12 14:03:43 * ogra thought he read UTC Oct 12 14:04:00 Same thing Oct 12 14:04:03 It will be hosted in #ubuntu-arm on freenode @ 15:00 UTC. Oct 12 14:04:12 I forget we're in GMT+1 Oct 12 14:04:20 ogra@osiris:/var/build/images$ date -u Oct 12 14:04:20 Di 12. Okt 14:01:59 UTC 2010 Oct 12 14:04:23 right Oct 12 14:04:46 Bloodly British and their stupid saving hrs Oct 12 14:05:17 heh Oct 12 14:54:43 lag, do you have a build with the changes from liam ? Oct 12 14:55:16 ogra, you get my email ? Oct 12 14:55:21 ogra: Nope Oct 12 14:55:32 Bit late to ask now Oct 12 15:01:03 devilhorns, yes, need to talk with davidm Oct 12 15:01:12 ogra, ok, no problem :) Oct 12 15:03:08 Let's try this again ... Oct 12 15:03:10 o/ Oct 12 15:03:18 o/ Oct 12 15:03:30 o/ Oct 12 15:03:35 o/ Oct 12 15:03:40 o/ Oct 12 15:03:52 \o Oct 12 15:04:02 We have an intruder Oct 12 15:04:05 ;) Oct 12 15:04:10 ;) Oct 12 15:04:11 lrg: ? Oct 12 15:04:24 * ogra is here Oct 12 15:04:36 lag: here Oct 12 15:05:00 Then we shall begin Oct 12 15:05:13 Firstly we need to get everyone up to speed Oct 12 15:05:31 I'm guessing lrg knows the most about this Oct 12 15:05:56 Care to give us a rundown? Oct 12 15:06:06 do we have rama here ? Oct 12 15:06:13 Not seen Oct 12 15:06:13 Here Oct 12 15:06:20 rsrimushnam: Welcome Oct 12 15:06:49 perfect :) Oct 12 15:06:49 ... Oct 12 15:07:00 ogra: Care to start us off? Oct 12 15:08:19 well, we dont really know ehere the issues lie yet, it is clear that sound currently doesnt work at all on the panda (or other omap4 platforms) Oct 12 15:08:51 I thought we had sound via ALSA? Oct 12 15:08:54 there are a) the backend routes not properly set by default Oct 12 15:09:04 b) alsa seems to have issues Oct 12 15:09:25 (i discussed with crimsun last night and he pointed me to a bug i noted into our bug) Oct 12 15:09:34 b might be solved by the SRU crimsun plans Oct 12 15:09:57 lag, we do but thats just through a slightly better hack Oct 12 15:10:14 I know there as been a tussle with userspace and kernel with regard to who's problem it is - has this been answered yet? Oct 12 15:10:19 ogra: care to expand on (b) Oct 12 15:10:24 though as i understand it, my hack will turn into the default in future alsa (using the init subdir) Oct 12 15:10:39 (b) is a libalsa issue is it not Oct 12 15:10:46 Do you have the bug number to hand? Oct 12 15:10:48 lrg, i cant expand much more than whats written on the bug, he just told me it would very likely improve things Oct 12 15:11:12 bug 652035 Oct 12 15:11:13 Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035 Oct 12 15:11:32 seems some of the parsing isnt done right Oct 12 15:11:39 there is an upstream fix and an additional fix crimsun added Oct 12 15:12:01 i wish he could be here now, since he does most of the ubuntu alsa maintenance Oct 12 15:12:05 It sounds like there are more issues than meets the eye Oct 12 15:12:09 but it sadly collides with his work hours Oct 12 15:12:18 Why do these work on other systems and not OMAP4? Oct 12 15:12:34 lag, well, the bug only explains why i have to call alsactl init manually Oct 12 15:12:54 which is anyway not the target we want to achieve Oct 12 15:13:03 Is alsa-utils script call at all? It seems this script resets alsa values and has some cases based on platforms Oct 12 15:13:26 berco, yes, it is called properly Oct 12 15:13:42 and as i said above, the future of alsa seems to be to use these init scripts Oct 12 15:13:54 but I don't know if it is called before SDP4430.conf is read... Oct 12 15:14:12 it could overwrite SDP4430, right? Oct 12 15:14:15 berco, i didnt use SDP4430.conf at all Oct 12 15:14:32 after boot i have the right mixer settings using my way Oct 12 15:14:34 looking at crimsun's patch for 652035 (which I believe I saw upstream as well), it's about not quitting early when finding gaps/holes in the list of subdevices Oct 12 15:14:40 but no sound until i call aslactl init Oct 12 15:15:05 diwic, so that could be the reason why the extra alsactl init is needed then Oct 12 15:15:21 i.e. my scrip should work fine with that fix Oct 12 15:15:30 but thats only half the solution Oct 12 15:15:37 ok. so do we want to fix your way first ogra? or is the purpose of the brainstorm to move away from this method and use SDP4430.conf file? Oct 12 15:15:44 ogra, Which init script is your script? Oct 12 15:15:55 persia, the one attached to our bug Oct 12 15:16:12 https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/24 Oct 12 15:16:13 and Oct 12 15:16:15 Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] Oct 12 15:16:16 https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/comments/25 Oct 12 15:16:35 berco, well, my script has two probs Oct 12 15:17:06 a) these scripts want more info which the driver doesnt expose atm so we cant really differ between different omap4 boards Oct 12 15:17:21 which is indeed bad unless the blaze uses exactly the same setup Oct 12 15:17:22 Ah, OK. I thought it was something different :) Oct 12 15:17:41 and b) more seriously HDMI doesnt get initialized and exposed to pulse Oct 12 15:17:55 imho b) is only solvable through SDP4430.conf Oct 12 15:18:13 but that could be a massively simpler one if it goes hand in hand with my init script Oct 12 15:18:27 since we dont need to set volumes from the .conf Oct 12 15:18:57 for a) we would need to extend the driver to expose more than just the card name Oct 12 15:19:50 if you look at /usr/share/alsa/init/hda you can see how you can set different mixers based on the board Oct 12 15:20:17 but we would need a mixername Oct 12 15:20:45 note that i also havent tried the fix from bug 652035 yet, all this is based on assumptions Oct 12 15:20:46 ogra: I could also add the machine name etc SDP4430/Panda/Blaze into the card name for (a) Oct 12 15:20:46 Launchpad bug 652035 in alsa-lib (Ubuntu) "libasound2 not finding usb sound card (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/652035 Oct 12 15:20:54 Is b) only soluable through SDP4430.conf? Can't we hint it by providing more inputs to pulse's module-udev-detect? Oct 12 15:21:00 lrg, yeah, that would be good Oct 12 15:21:18 I have HDMI working from PA Oct 12 15:21:21 persia, its about outputs :) Oct 12 15:21:30 so for exposing HDMI to pulse, first - do we want one output at a time or is the hardware capable of multiple independent streams? Oct 12 15:21:49 it's justa a matter of creating a PA profile (which I'm working on at this moment) Oct 12 15:21:51 ogra, Right, so we expose more data in /sys/ that udev and pulse use to set the outputs. Oct 12 15:22:03 abduenas, We're looking at autodetection solutions only. Oct 12 15:22:07 we want either a selectable output in the audio prefs (with a default to analog) or a mirrored output Oct 12 15:22:11 i'd say Oct 12 15:22:26 I think the regular pulse output UI is fine. Let's not fuss with that. Oct 12 15:22:27 abduenas, we cant touch pulse config Oct 12 15:22:48 persia, yes, its fine and i saw hdmi exposed in it Oct 12 15:22:52 persia, there are already mixer profiles for other cards in the default config Oct 12 15:22:57 PA profile has nothing to do with touching pulse default.pa config Oct 12 15:22:58 thats what i mean by selectable output Oct 12 15:23:02 ogra: we need to be able to support discrete streams on different outputs -- not just mirrored Oct 12 15:23:14 * jayabharath wonders if davidm is back in town... need to send a platform to hrw... Oct 12 15:23:26 rsrimushnam, right, so selectable with default to analog it is Oct 12 15:23:54 rsrimushnam, We can do that, but we don't tend to expose the UI for that by default. Interested folks are usually directed to install pavucontrol Oct 12 15:23:58 persia, upstream ships with files for e g native-instruments-audio8dj.conf and a few others Oct 12 15:24:06 diwic, Yep. Oct 12 15:24:14 Hate to bother you people but were would I go to get some help installing ubuntu on the BeagleBoard. I have tried http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage but it won't boot. Oct 12 15:24:27 tw_, Are you able to wait ~45 minutes? Oct 12 15:24:30 tw_: #beagleboard Oct 12 15:24:38 tw_: #beagle Oct 12 15:24:41 Even Oct 12 15:24:42 Yes Oct 12 15:24:52 Why? Oct 12 15:24:55 tw_, If the folks in #beagle can't help, ask us again then, and we'll help. Oct 12 15:25:09 thats bad Oct 12 15:25:15 dont point him to #beagle Oct 12 15:25:22 they dont use ubuntu usually Oct 12 15:25:33 * persia will help tw elsewhere: please continue the sound meeting Oct 12 15:25:45 tw_ I'll talk to you via other means - bear with me Oct 12 15:25:48 btw: I am using one of the new BB_xm boards. Oct 12 15:26:11 anyway, it all comes down to, either we adjust the mixer names (in the driver) so pulseaudio can autodetect the profile, or we take abduenas PA profile when it's ready Oct 12 15:26:33 where would that pa pfrofile go ? Oct 12 15:26:50 /usr/share/pulseaudio/alsa-mixer/profile-sets Oct 12 15:26:57 and an udev rule to go with it Oct 12 15:27:05 Let's do the former. There's a high likelihood that we'll see lots more boards use this SoC, and we need per-board stuff in the driver anyway. Oct 12 15:27:11 hmm Oct 12 15:27:15 diwic: PA autodetection is wrong, we must be more explicit Oct 12 15:27:27 diwic, how do you make sure that doesnt collide with the already existing udev rule ? Oct 12 15:27:27 Did anyone ever get module-udev-detect working? Last I saw, folks were still hardcoding the modules for pulse. Oct 12 15:27:40 lrg, can you elaborate? Oct 12 15:27:53 persia, yes, my init script works without any extras Oct 12 15:28:04 but with the above limitations Oct 12 15:28:10 With regular default.pa? Oct 12 15:28:13 yes Oct 12 15:28:18 Oh, cool. Oct 12 15:28:19 no changes to pulse at all Oct 12 15:28:32 just the one line change to 00main and the script in place Oct 12 15:28:38 diwic: auto detection depends on PA making guesses about the underlying audio hardware. Oct 12 15:28:42 and the nasty extra alsactl init call Oct 12 15:28:43 Ah, so comment 13 wasn't wrong after all. Oct 12 15:29:13 ogra: it's one line in 00main + one omap4 file, right? Oct 12 15:29:20 persia, yes, thats what made me develop that script Oct 12 15:29:31 berco, xactly Oct 12 15:29:39 no further changes Oct 12 15:29:55 berco and I had thought that was wrong after some experimentation, leading to the SDP4430.conf route Oct 12 15:30:04 lrg, so then we must trace down where PA guesses wrong and evaluate what to do in each particular case Oct 12 15:30:06 if you then call aslactl init at some point after boot sound works fine through analog Oct 12 15:30:07 wondering if we don't want to use udev as much as possible to avoid multiple conf files to maintain Oct 12 15:30:22 udev does its job already Oct 12 15:30:49 diwic: the answer is UCM when it's ready, this way PA does not need to do nasty probing on each PCM that it does now. Oct 12 15:30:52 with the init scrip the mixers are all set properly right after boot (and without asound.state file in place) Oct 12 15:31:01 diwic, We'd do that in /usr/share/pulseaudio/alsa-mixer/paths/*, right? Oct 12 15:31:18 lrg, Do we expect UCM by February? Oct 12 15:31:19 well, as i understood crimsun UCM is whgat these init scripts are Oct 12 15:31:41 or at lest the start of UCM Oct 12 15:31:54 persia: yes, we are pshing Jaroslav to move it to his master branch ins alsa-lib.git Oct 12 15:32:04 persia, those provide input for the probing as well as being a poor man's UCM, yes Oct 12 15:32:33 Let's design a UCM-based solution then, and use that for Natty then. Oct 12 15:32:58 persia: please everyone feel free to mail Jaroslav on UCM progress on alsa-dev. this may speed up progress Oct 12 15:32:58 persia, we need a solution this week Oct 12 15:33:04 lrg, but UCM or not, having uniform control names is still a good thing Oct 12 15:33:06 And provide a pulse profile for maverick users. Oct 12 15:33:12 persia, i dont care about natty Oct 12 15:33:21 the SRU needs to be in before friday Oct 12 15:33:22 ogra, But you will, so I'll care for you today :) Oct 12 15:33:35 natty is well ... natty Oct 12 15:33:56 diwic: uniform control names can apply to some audio hardware but unfortunately not all :( Oct 12 15:34:18 * persia owns some hardware that would have difficulty with uniform control names Oct 12 15:35:08 lrg, so if this particular hardware can't have standard control names, we write a pa profile to compensate? Oct 12 15:35:43 lrg, assuming UCM is not available Oct 12 15:35:50 diwic: yes, agreed Oct 12 15:36:19 So, pulseaudio-profile for maverick and UCM for natty? Oct 12 15:36:25 hrm Oct 12 15:36:57 We'll still have 652035 though. Oct 12 15:37:14 Has anyone tried the proposed SRU on an omap4 board with the alsa init script? Oct 12 15:37:30 not yet Oct 12 15:37:58 will the pulse profile help to initialize the right backend routing ? Oct 12 15:38:11 nop Oct 12 15:38:11 * ogra doesnt belive it scratches more than the surface Oct 12 15:38:14 right Oct 12 15:38:17 The pulse profile will tell pulse the control names to use. Oct 12 15:38:27 so that doesnt help at all Oct 12 15:38:36 Are you saying the HDMI out isn't even initialised with the init script? Oct 12 15:38:55 oh, you mean only for adding HDMI ? Oct 12 15:39:08 i understood as a general solution for the problem Oct 12 15:39:17 I think there is some confusion about the "backend routing", what is that really about? Oct 12 15:39:23 Right. Complete maverick solution is 652035 fix + alsa init script + pulse profile Oct 12 15:39:48 diwic, adding the right codec to the control Oct 12 15:39:57 Natty solution would be UCM-based and may or may not need a pulse profile depending on whether we can categorise the hardware sensibly in shipping products. Oct 12 15:40:00 persia, ah, now i understand Oct 12 15:41:16 kgilmer: hi here Oct 12 15:41:22 diwic, currently alsa device 0,0 points to a null sink Oct 12 15:41:34 by default Oct 12 15:42:10 ogra, can all subdevices be used in parallel? Oct 12 15:42:21 i dont know Oct 12 15:42:33 or does the hw just support one stream at a time? Oct 12 15:42:36 i'm really no audio guy, only worked into that during last week :) Oct 12 15:42:45 i think it shoudl support more Oct 12 15:42:47 lrg, ^ Oct 12 15:42:50 HW supports multiple streams Oct 12 15:42:55 Hi i just recentñy buy a DevKit8000 and i want to run Ubuntu on it, i have already read the wiki. But when i boot from the SD the boot hang out Oct 12 15:42:56 rsrimushnam, Can you confirm that? Oct 12 15:43:00 but one of lrg or rsrimushnam should be able to answer Oct 12 15:43:05 It can support more than one stream. But not necessarily all simultaneously. Oct 12 15:43:25 rsrimushnam, Do we need to worry about how many it can support at once? Oct 12 15:43:29 at kjourlald Oct 12 15:43:41 ogra: UCM will export this multiple stream info to PA too Oct 12 15:44:11 PA profile can also tell PA about the other hw devices Oct 12 15:44:25 worry from what respect? Oct 12 15:44:32 abduenas, that was my thought as well Oct 12 15:44:53 rsrimushnam, Limit the number of simultaneous streams in the UI or something. Oct 12 15:45:23 hi hrw :) Oct 12 15:45:45 I guess the way we had visualized this, PA would route audio to the different available sinks on the driver and handle mixing streams to a single sink there. So from the UI POV, this should be transparent, I would think, Oct 12 15:46:09 hrw, i'm curious how rootstock differs from oe? does rootstock run entire build on arm via qemu? Oct 12 15:46:15 rsrimushnam, That's easlier then. Thanks. Oct 12 15:46:31 kgilmer_: it just uses packages from feeds + some mangling Oct 12 15:46:46 so does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver? Oct 12 15:47:26 The subdevices appear to be constructed by the alsa init script Oct 12 15:48:11 Going back to "Complete maverick solution is 652035 fix + alsa init script + pulse profile". rsrimushnam: are you going to provide us the PA profile? Oct 12 15:48:29 Yes. Oct 12 15:49:03 so are we sure "652035 fix + alsa init script + pulse profile" will be enough? no need for a sdp4430.conf file or else? Oct 12 15:49:08 abduenas is working on it now. Oct 12 15:49:12 actually the PA guys are willing to include that on PA package, as native-instruments-audio8dj.conf Oct 12 15:49:14 persia, the init script as posted in comment #25 does not add any subdevices? Oct 12 15:50:04 hrw, packages = binary packages? Oct 12 15:50:10 berco, I think ogra said that he didn't need SDP4430.conf with the init script. Oct 12 15:50:13 persia, could you point me to that init script? Oct 12 15:50:14 abduenas: ok, I see. That's fair Oct 12 15:50:18 diwic, Then I'm mistaken. Oct 12 15:50:19 persia, right Oct 12 15:50:24 kgilmer_: yes Oct 12 15:50:27 diwic, the scripts simply connect backends to frontends. Oct 12 15:50:35 diwic, its attached to the bug Oct 12 15:50:44 persia: I agree. Just wanted to make sure we discard this approach of SDP4430.conf Oct 12 15:50:45 where do the binary packages get generated hrw? Oct 12 15:50:53 ogra, so it is the #25 comment attachment? Oct 12 15:51:05 diwic, right together with the change to 00main Oct 12 15:51:10 (from 24) Oct 12 15:51:23 kgilmer_: ah that your gentoo roots... Oct 12 15:51:28 so then I'll reask my question: does the driver "probe" the codec and construct devices appropriately? Or are the subdevices hard-coded in the driver? Oct 12 15:51:48 they are apparently not since oyu need that script Oct 12 15:51:52 nothing is hardcoded in the driver. Oct 12 15:51:55 kgilmer_: in debian (and derived) binary packages are built by builddeamons Oct 12 15:52:09 they FE and bE are initialised and left for userspace to connect. Oct 12 15:52:26 mpoirier, who decides that 0,0 is a null sink and 0,7 (?) is HDMI? Oct 12 15:52:43 e g Oct 12 15:52:45 hrw, ah ic. those biuld daemons are running on target architecture or they are cross compiling? Oct 12 15:52:51 ogra: so for the init script, will it be a udev rule? Oct 12 15:53:00 kgilmer_: target - only native builds are done Oct 12 15:53:05 berco, there is a udev rule already Oct 12 15:53:16 diwic:the null sink is simply the first on the list. I beleive moving it down would put another sync as the default Oct 12 15:53:19 interesting hrw Oct 12 15:53:23 diwic: the pcm mappings are done in the machine driver Oct 12 15:53:31 have a look at sdp4430.c Oct 12 15:53:45 berco, you only need to dump the script into /usr/share/alsa/init/ Oct 12 15:53:47 ogra: oops, sorry. Thought alsactl init was still missing Oct 12 15:53:49 * kgilmer_ sees a chicken and egg problem. Oct 12 15:53:54 berco, right Oct 12 15:54:01 kgilmer_: you mean "bootstrap" problem? Oct 12 15:54:16 berco, but thats only to actually init, the mixers are all set right already and properly routed Oct 12 15:54:20 yeah hrw Oct 12 15:54:30 berco, the hope is that the aösa-lib fix solves the needed init Oct 12 15:55:11 ogra: missed that one :). Now I understand the #652035 need :) Oct 12 15:55:17 :) Oct 12 15:56:00 so just waiting for rsrimushnam profile and we can test :) Oct 12 15:56:20 rsrimushnam: when do you think you can provide us a profile-set to test? Oct 12 15:56:43 sorry, most likely to be abduenas Oct 12 15:56:52 we have something started already but we are still having issues with it. abduenas can elaborate Oct 12 15:56:52 who provides this file Oct 12 15:57:13 kgilmer_: both distros did bootstrap long time ago Oct 12 15:57:49 fyi: I need to drop off in 5 minutes... Oct 12 15:57:52 rsrimushnam: abduenas: I think we just need to get a rough idea of the timeframe Oct 12 15:57:56 i'm just missing the udev rule in /lib/udev/rules.d/90-pulseaudio.rules to be able to read omap3.conf Oct 12 15:58:14 but i'm udev nubee Oct 12 15:58:44 abduenas, ugh, a udev rule for pulse ? Oct 12 15:58:45 So the problem is then: that PA should switch subdevice on the fly (i e when user switches from "Headset" to "HDMI") in a way it currently can't do? Oct 12 15:58:51 sorry meant to say omap4.conf (or wahtever) Oct 12 15:58:52 abduenas: don't hesitate to come to this channel and ask for help. If we can we will help Oct 12 15:59:08 diwic, Why does it need to be different than what we do for headset/HDMI for anything else? Oct 12 15:59:13 lag: are you taking a note of any actions here btw ? Oct 12 15:59:33 I wasn't no Oct 12 15:59:36 (irclogs.ubuntu.com can help if it's not being done in realtime) Oct 12 15:59:40 abduenas, are you sure that is used at all when pulse runs on a per user base ? Oct 12 15:59:50 ogra: this udev rule already exists. Oct 12 15:59:52 persia: I'm forgetful ;) Oct 12 15:59:52 (which is the default in ubuntu) Oct 12 15:59:56 I don't think we have a meeting bot in here Oct 12 16:00:07 persia, current PA structure is either switch between different cards, or switch "connector" (which it does by setting volume controls, not by switching subdevice) Oct 12 16:00:11 berco, right, but i think only if pulse runs as a system daemon it is used Oct 12 16:00:23 ogra: I see. Oct 12 16:00:24 lag, We don't. I don't want to have enough meetings here to add one, but I'm willing to be convinced. Oct 12 16:00:34 berco, i'm not sure though Oct 12 16:00:48 berco, abduenas, that should be heavily tested Oct 12 16:00:57 diwic, Aha. OK. I guess I've not actually used PA with my harder-to-define cards. Oct 12 16:00:59 i'm able to use it on per-user basis Oct 12 16:01:03 persia: No, it's okay :) Oct 12 16:01:21 abduenas, thanks that helps :) Oct 12 16:01:24 I we'll have to have a wash-up when the meeting has finished Oct 12 16:01:33 Who's doing what etc Oct 12 16:01:59 so who is fixing the driver side ? Oct 12 16:02:12 lag, It's also worth separating into two discussions moving forward: maverick hacks and natty solution. Oct 12 16:02:20 ogra: what part of the driver ? Oct 12 16:02:22 to expose the board name Oct 12 16:02:24 the name ? Oct 12 16:02:30 ah, ok - me :) Oct 12 16:02:33 :) Oct 12 16:02:38 cool :) Oct 12 16:02:39 like in the hda init file Oct 12 16:02:53 i'm happy to add my init file to alsa-libs in an SRU Oct 12 16:03:03 and the one line change to 00main Oct 12 16:03:08 persia, the question is if that can be worked around in the pa profile, and it might be if the subdevices are stable Oct 12 16:03:13 i'm working on the PA profile for SDP4430/OMAP4 Oct 12 16:03:31 abduenas, will you test on all available omap4 hw ? Oct 12 16:03:39 (panda, blaze tablet) Oct 12 16:03:53 diwic, For the small number of devices to be fixed for maverick, I think we can find a way to fake that. We'll need a richer interface for natty. Oct 12 16:04:02 i have a blaze but no panda... although i can borrow one ... i think Oct 12 16:04:03 hey guys what's the procedure for cross compiling a package Oct 12 16:04:16 Neko, We try to avoid it at all costs. Oct 12 16:04:18 (though i guess we can be a bit ignorant about tablet since it uses a different kernel anyway) Oct 12 16:04:28 haha Oct 12 16:04:29 Neko, That said, there's a cross-toolchain package in the archives Oct 12 16:04:30 yes but consider I have a nice fast box here to cross compile xserver or so.... Oct 12 16:04:33 I have the toolchain Oct 12 16:04:36 abduenas: if you have something to be ready for test, let me know. I can run the test on my panda to help Oct 12 16:04:42 but if I dpkg-build it's gonna use native right? Oct 12 16:04:46 Right. Oct 12 16:04:56 berco: roger that Oct 12 16:04:58 lag, so was that enough as a summary for your notes ? Oct 12 16:05:03 And lots of packages are packaged in a way that means they can't be cross-compiled. Oct 12 16:05:04 abduenas: also good to be able to reproduce Oct 12 16:05:08 (who -> what) Oct 12 16:05:27 I guess the answer is, then, don't bother.. Oct 12 16:06:10 That's what we devided, yeah. Oct 12 16:06:11 Neko, so i found the issue to your gdm vs oem-config bug Oct 12 16:06:22 Neko: "xdeb -a armel --apt-source packagename" Oct 12 16:06:26 ogra: Sure Oct 12 16:06:32 great :) Oct 12 16:06:39 Neko, hrw is the local cross-compilation expert if you really want to dig: just be warned it's not as trivial as just expecting dpkg-cross to actually work. Oct 12 16:06:40 Unless there's anything else anyone wants to add? Oct 12 16:06:56 * ogra is fine as long as sound works on friday :) Oct 12 16:06:56 Neko: it may fail (probably will). next step is adding "--only-explicit" to xdeb call. this also may fail Oct 12 16:06:58 ogra, amazing what is the problem? Oct 12 16:07:01 I didn't get a bug update Oct 12 16:07:21 hrw, thx maybe I will look into it.. for now though, native, since this seems like it may fail Oct 12 16:07:24 Neko, because the bug is invalid ... its the way rootstock rolls the tarball Oct 12 16:07:24 Neko: last step is "dpkg-buildpackage -b -aarmel" as xdeb steps should give you build deps Oct 12 16:07:27 abduenas, you're also welcome to contact me if you need someone to discuss PA profiles with Oct 12 16:07:32 ogra, argh? Oct 12 16:07:40 diwic: thnx! Oct 12 16:07:47 * berco thinks it "sounds" better than an hour ago :) Oct 12 16:07:53 Neko: debian and derived are not cross compilation ready Oct 12 16:07:54 so maybe update the bug as invalid with a comment that rootstock rolls the tarball badly? :) Oct 12 16:08:02 hrw, I know, nothing is.. :( Oct 12 16:08:07 Neko, if you just use tar, uid's and gid's will be taken from /etc/passwd and group of the host system Oct 12 16:08:25 Neko, Just build faster boxes :) Oct 12 16:08:31 Neko, rootstock needs to use --numeric-owner to make sure owners of the files dont change Oct 12 16:08:44 hmm has this been patched already? Oct 12 16:08:59 Neko, thast something you will only hit of you build newer releases on older boxes Oct 12 16:09:12 not yet, i need to discuss with rsalveti once he is back Oct 12 16:09:14 yeah I was building maverick on lucid... Oct 12 16:09:22 but also building lucid on lucid broke like that Oct 12 16:09:23 (public holiday at his place today) Oct 12 16:09:24 In case there is any doubt Oct 12 16:09:28 [END MEETING] Oct 12 16:09:32 Thank you everyone Oct 12 16:09:35 I'll be in touch Oct 12 16:09:37 thanks, bye Oct 12 16:09:40 basically because on x86 and armel the user ids not necessarily the same... Oct 12 16:09:43 Neko, well, as long as there is a diff between host and VM Oct 12 16:09:50 right Oct 12 16:10:04 not even between two x86 boxes thats guaranteed Oct 12 16:10:11 Neko: OpenEmbedded allows to cross compile big amount of stuff in automated way Oct 12 16:10:15 the system users are created by the packages Oct 12 16:10:24 sguiriec: were you able to bet me docs for the complete audio path we talked about ? Oct 12 16:10:28 so it only depends on the order Oct 12 16:10:49 (in which the packages are installed) Oct 12 16:10:50 hrw yes and opensuse build service manages too.. the big trick is use qemu Oct 12 16:11:00 but installing a full system then qemu then build is overkill Oct 12 16:11:15 opensuse does some very nasty things though Oct 12 16:11:19 yep I know Oct 12 16:11:30 injecting x86 libs and binaries Oct 12 16:11:31 mpoirier:I have prepare a picture. Need to make minor correction Oct 12 16:11:32 I got my "I contribute" t-shirt for reporting tons of bugs :] Oct 12 16:11:43 sguiriec: cool. Oct 12 16:11:47 okay.. so... Oct 12 16:12:04 ogra, if I hack my rootstock to have this --numeric-owner stuff it will magically start to work better? Oct 12 16:12:05 sbuild can run over qemu as well: the results were not as exciting as initially thought... Oct 12 16:12:24 mpoirier: sorry a little bit busy on other stuff. Will try to push it today Oct 12 16:12:27 Neko: OE does cross only - qemu is used only for generation of glibc l10n packages (and can be disabled) Oct 12 16:12:43 Neko: but thats #ubuntu not #oe Oct 12 16:12:46 sguiriec: that's ok, I've been elsewhere too. Oct 12 16:12:48 Neko, it should, i haent tested it yet but hit the exact same issue as you with a tarred up rootfs that i repacked on different boxes Oct 12 16:13:09 Neko, so finding all tar calls in rootstock and adding --numeric-owner should solve it Oct 12 16:13:16 hrw, I have some experience with OE, but I quit using it about 18 months ago Oct 12 16:13:36 Neko, Did you never have success with livecd-rootfs and debian-cd? Oct 12 16:14:33 mporier: I will give you the link as soon as I have done the update. Oct 12 16:15:05 persia, I never got to try it Oct 12 16:15:13 I am stuck doing kernel stuff Oct 12 16:15:19 but since mav got released.... Oct 12 16:15:26 I am building rootstocks Oct 12 16:15:40 * ogra would also recommend livecd-rootfs over rootstock if you want to release images Oct 12 16:15:55 I need a rootstock first before I can do that though Oct 12 16:15:55 rootstock is great for home use Oct 12 16:15:57 chicken-egg really Oct 12 16:16:01 Ah, OK. I'll hope you have a chance to switch before natty, as rootstock isn't tested well, and mostly meant for hacking about rather than working systems. Oct 12 16:16:07 but nothing for doing official releases Oct 12 16:16:08 these rootstocks right now are for *me* only Oct 12 16:16:39 we have released on a board already but.. it was a hateful solution Oct 12 16:16:44 For now, stick with what you have. When you have a few hours, come back, and we'll help you switch. Oct 12 16:16:48 have a nice rest of day Oct 12 16:16:55 maybe in 6 weeks? :D Oct 12 16:17:21 Neko, will you be at UDS ? Oct 12 16:17:30 Neko, 6 weeks sounds about perfect, sure. Oct 12 16:17:33 no but Konstantinos will be Oct 12 16:17:38 (markos, armhf debian) Oct 12 16:17:39 we could sit down one evening and fix :) Oct 12 16:18:03 unfortunately UDS happens during the school year so it's impossible for me to take time out to do it Oct 12 16:56:59 ogra: do we also need to add the user to audio&pulse groups? Oct 12 17:02:27 yay, ogra, made a little fix for rootstock, worked :D Oct 12 17:02:54 so that numeric-owner thing is exactly it Oct 12 17:03:20 (oem-config still nukes on exit though, I gotta work out how to fix that, but we have a new uboot series coming out.. which will make flash-kernel work better...) Oct 12 17:03:25 btw is the flash-kernel package owner in here Oct 12 17:09:51 ogra, where can i get more info on livecd-rootfs? Oct 12 17:10:13 the default google search isn't very enlightening. Oct 12 18:17:27 Hey guys, I can't find the SmartQ v7 in https://wiki.ubuntu.com/ARM/DeviceSupport but I remember reading somewhere (sorry, lost the link) that it does in fact work. Is this true? So, is there support? If so, in the form of a repository hosted somewhere? or do I have to compile everything on my own? Thanks. Oct 12 18:45:25 berco, no Oct 12 18:46:19 berco, console-kit cares for that since lucid Oct 12 19:58:09 what are the minimum disk requirements for an arm ubuntu with a tiny window manager (matchbox, unity) ? Oct 12 20:08:47 for the whole unity desktop? Oct 12 20:09:25 i have to recreate my lvm partitions and maybe i can get enough space for an ubuntu Oct 12 20:09:37 but not high priority Oct 12 20:53:43 is ogra's build-arm-rootfs still usable for maverick? Oct 12 20:55:49 playya_, better use qemu-debootstrap --arch armel Oct 12 20:56:03 ok Oct 12 20:56:10 oh, wait, build-arm-rootfs ? Oct 12 20:56:18 yes Oct 12 20:56:20 no, use rootstock Oct 12 20:56:54 i think the resulting image might be to big and the pre's kernel is quite old (2.6.24) Oct 12 20:57:20 maybe i should wait for the pre plus Oct 12 21:44:01 doko, new ac100 image up if you want Oct 12 21:44:16 (with the battery spam patched out of the kernel now) Oct 12 21:47:47 battery spam? :) Oct 13 02:08:10 ogra, does anyone know why mono doesn't install on armel (especially in qemu?) Oct 13 02:20:42 It's a qemu bug. Oct 13 02:20:54 directhex got Mono working cleanly on the EfikaMX for maverick. Oct 13 02:21:03 (even moonlight) Oct 13 02:21:36 If you're using rootstock, don't install Mono until you've booted on the real hardware. Oct 13 02:23:23 (unless someone made rootstock work unemulated for native builds, in which case it ought be no issue) Oct 13 02:23:38 kmargar, Hey. Oct 13 02:25:17 persia, I just saw there were tons of bugs in Mono for mx51 (but not dove!) for some reason, and ogra was involved Oct 13 02:25:21 testing at least Oct 13 02:25:31 directhex is one of the guys we sent boards to? Oct 13 02:25:34 the mono guy? Oct 13 02:25:46 did he have to fix anything or was it just working out of the box at release? Oct 13 02:25:51 Indeed. mono on the i.MX51x was exceedingly painful for a while, but is now sorted. Oct 13 02:25:56 okay great Oct 13 02:25:59 so what's the qemu bug :D Oct 13 02:26:03 He had to fix something. There was a blog post. Oct 13 02:26:04 it would be great if that was fixed Oct 13 02:26:35 Well, qemu doesn't support some huge chunk of stuff (you'll see lots of unsupported syscall and unsupported ioctls pass in stdout). Oct 13 02:26:39 once I finish this next rootstock I am done with it and will start messing with livecd-rootfs Oct 13 02:26:46 And something in that unsupported stuff is enough to wedge Mono. Oct 13 02:27:27 The impression I have is that nobody wants to fix it, instead switching from qemu-versatile to qemu-omap to collect a separate set of issues, but one that can easily be compared against hardware. Oct 13 02:27:51 Whether using qemu-omap is enough to install Mono is not clear to me: there may be more involved. Oct 13 02:28:00 I saw his post about moonlight and firefox ABIs today Oct 13 02:28:09 nothing about Mono proper though Oct 13 02:28:52 He got Mono working back in Jaunty, but only for some things. It's a steady progress to test all the corner cases. Oct 13 02:29:06 I'm impressed that Moonlight is working.. Oct 13 02:29:07 Moonlight is rather demanding on the CLI, and exercises it fairly well. Oct 13 02:29:21 I don't understand about this codec pack though Oct 13 02:31:18 anyway brb Patch Tuesday Oct 13 02:33:59 For those lurking, the above is another demonstration why it's handy to run Ubuntu :) **** ENDING LOGGING AT Wed Oct 13 02:59:57 2010