**** BEGIN LOGGING AT Fri Feb 04 02:59:57 2011 Feb 04 11:40:16 morning Feb 04 11:44:01 yo Feb 04 12:24:38 janimo: can't the qt bug be also forwarded upstream? Feb 04 12:24:49 as it seems now that is not a compiler regression Feb 04 12:25:12 rsalveti, sure, I can do that Feb 04 12:26:43 I am surprised though it happens with gcc4.4 as well, I wouldn't have thought it is a Qt regression - smaller chances for that between 4.7.0 and 4.7.1 than between two toolchains Feb 04 12:39:15 janimo, rsalveti, shouldnt we wait until NCommander's full rebild finished to make sure its not any of the linked in bits ? Feb 04 12:39:51 could be, was just thinking in a way to put more people looking at this Feb 04 12:40:02 and it won't hurt to send it upstream Feb 04 12:40:03 Better to give a good report to upstream. Feb 04 12:40:04 since janimo did only a partial build and NCommander was supposed to do a full one Feb 04 12:40:31 And if it's a compiler issue, better to send to the other upstream :) Feb 04 12:41:07 well, currently it doesnt look like compiler Feb 04 12:41:25 but i'd like a full proof before pushing any upstream Feb 04 12:41:32 I don't think it's known. Inlines behave exceedingly oddly with partial builds. Feb 04 12:41:50 so imho we should wait until we can prove it by trying out NCommander's complete build Feb 04 12:41:55 Indeed. Feb 04 12:42:22 given he started it last night (i hope) it should be done this evening at some point Feb 04 12:42:27 ogra, do you know what NCommander's current build tests for Feb 04 12:42:28 ? Feb 04 12:43:02 janimo, well, according to the call yesterday he was supposed to build the full source with gcc 4.4 Feb 04 12:43:25 same thing you did but with the full package Feb 04 12:43:37 ok Feb 04 12:43:46 althoug he seemed to say it was redundant Feb 04 12:43:47 so we can exclude any issues that might be caused by a partial rebuild Feb 04 12:43:50 right Feb 04 12:43:55 sigh Feb 04 12:43:58 did he ? Feb 04 12:44:14 he surely had some build going but not sure for what Feb 04 12:44:21 hmpf Feb 04 12:44:22 k Feb 04 12:44:29 lets see when he gets up Feb 04 12:44:38 and ask him then Feb 04 12:57:57 I need to write a udev rule for pulse audio. Anyone here knows how or an example of how to write a udev rule for the OMAP soc audio? Feb 04 12:58:13 a udev rule ? Feb 04 12:58:15 why ? Feb 04 12:58:45 Yeah. Take a look in /lib/udev/rules.d/80-pulseaudio.rules Feb 04 12:59:07 I need such a line for the soc in order to define a pulseaudio profile Feb 04 12:59:19 nope Feb 04 12:59:25 you need an alsa profile instead Feb 04 12:59:41 I don't even have that file Feb 04 12:59:55 (this was on maverick) Feb 04 13:00:27 i dont have that file on maverick Feb 04 13:00:37 My maverick has a 90-pulseaudio.rules, but it only has stuff for some fairly exotic USB devices. Feb 04 13:00:50 right Feb 04 13:01:05 Doing it in ALSA is the way to go. Feb 04 13:01:05 do you then know how? Because I don't have audio on my board and the pulseaudio people sais I need to write a PA profile such as the exotic ones in 90-pulseaudio.rules Feb 04 13:01:19 persia, so how do I do that then? Feb 04 13:01:30 Which board ("FOO" if you can't say)? Feb 04 13:02:10 FOO. It's our own custom board with custom audio devices. Feb 04 13:02:24 Ah. That will make this discussion a little trickier :) Feb 04 13:02:31 So I know I'm on my own, but regardless, I need audio to work ;) Feb 04 13:02:44 Does `aplay -l` give you any output? Feb 04 13:03:18 Yes, no problem. And I'm able to playback with alsa players and alsamixer Feb 04 13:03:37 Excellent! That's a good start. Feb 04 13:04:34 I also have pulseaudio if I load the modules manually. It's just the udev autodetection which doesn't. It refuses as it doesn't find a working profile. Feb 04 13:05:05 And thus the udev rule where I can tell PA about its profile (which I need to write regardless) Feb 04 13:05:24 Something like load-module module-alsa-sink ... (with lots of arguments)? Feb 04 13:05:31 But I'm listening about other methods if you know about it Feb 04 13:06:12 persia: Yes, *lots*. However you lose some capabilities that way (like HW volume control) due to limitations in the manual module load Feb 04 13:06:28 Indeed. Feb 04 13:07:24 Where can I find a ALSA profile? Feb 04 13:07:37 in /usr/share/alsa/init/ Feb 04 13:08:43 That only works if you get useful CARDINFO data though: you should be able to tell if you have acceptable data from the aplay output. Feb 04 13:09:09 right, you need a proper driver Feb 04 13:13:13 Well, I wouldn't be surprised if I found bug in the driver. But this is one in our team, so I'll yank his chain if its not working. In all cases I need to actually prove that its the ALSA driver which doesnt work Feb 04 13:13:23 Regardless, aplay reports: Feb 04 13:13:26 card 0: mcbline [mcbline], device 0: AIC23 tlv320aic3105-0 [] Feb 04 13:13:30 card 1: mcb1681 [mcb1681], device 0: PCM1681_STREAM PCM1681-0 [] Feb 04 13:13:39 So, that's a good starting point Feb 04 13:14:56 That ought be enough. Try creating an ALSA profile against those strings, and see if it loads. Feb 04 13:15:13 persia: How do I verify it? Feb 04 13:15:35 Your sound will work :) Feb 04 13:15:42 hahah lol Feb 04 13:17:30 whooh.. googling for alsa profile docs... Feb 04 13:27:07 hmm. What to put into my ALSA profile?... Feb 04 13:29:37 Take a look at some of the other files there: you probably want to identify your controls, at the least. Feb 04 13:30:03 Yes, I'm looking at the omap4 Feb 04 13:30:29 One thing though. In 00main it sais "CARDINFO{driver}=="OMAP4", INCLUDE="omap4", GOTO="init_end"" Feb 04 13:31:07 While it parses two CARDINFO's in omap4 Feb 04 13:31:31 Is there a way I can dump these ALSA variables (driver, name)? Feb 04 13:31:52 The aplay -l doesnt tell which is which Feb 04 13:33:23 cat /proc/asound/cards Feb 04 13:33:46 That doesn't tell which is which either Feb 04 13:35:59 Obviously wrong: Found hardware: "" "" "" "" "" Feb 04 13:37:29 I would have expected something similar to the aplay -l output: that's a driver issue. Feb 04 13:38:03 Yes. Reading from 00main it sais: Feb 04 13:38:10 ERROR="Found hardware: \"$cardinfo{driver}\" \"$cardinfo{mixername}\" \"$cardinfo{components}\" \"$attr{subsystem_vendor}\" \"$attr{subsystem_device}\"\n" Feb 04 13:38:25 Hence the cardinfo information is missing... Feb 04 13:38:51 Strange as aplay -l does report them Feb 04 13:39:15 Probably an incompletely filled structure: long names provided, but not short names (as they aren't exposed to the UI) Feb 04 13:44:21 persia, do you know of a omap soc kernel driver which works good? Feb 04 13:45:57 * persia looks around the kernel tree Feb 04 13:46:14 under sound/soc/omap Feb 04 13:47:10 If I recall correctly, sdp4430 got a lot of attention a few months ago, and probably represents the best-tested example of what is known to work throughout the stack Feb 04 13:47:54 thanks. If you run aplay -l on your device, how does the "card 0: ..." line look like? Feb 04 13:48:08 My target sais: card 0: mcbline [mcbline], device 0: AIC23 tlv320aic3105-0 [] Feb 04 13:48:19 While my host sais: card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog] Feb 04 13:48:35 Note the last [] missing the text Feb 04 13:49:00 I don't currently have a running target with a recent Ubuntu kernel. Feb 04 13:49:02 ogra_ Feb 04 13:49:05 ? Feb 04 13:49:13 * persia should upgrade something this weekend Feb 04 13:53:58 well, the panda operates on the stuff bhind the first colon in /proc/asound/cards Feb 04 13:54:29 ogra, Do you happen to have the string handy? Feb 04 13:55:20 Hmm. /proc/asound/cards: Feb 04 13:55:23 0 [mcbline ]: - mcbline Feb 04 13:55:25 mcbline Feb 04 13:55:31 While from host: Feb 04 13:55:34 0 [Intel ]: HDA-Intel - HDA Intel Feb 04 13:55:35 ogra@panda:~$ cat /proc/asound/cards Feb 04 13:55:35 0 [Panda ]: OMAP4 - Panda Feb 04 13:55:35 TI OMAP4 Board Feb 04 13:55:36 HDA Intel at 0xf6fdc000 irq 48 Feb 04 13:55:48 It's the bit before the '-' that seems to be the critical bit. Feb 04 13:55:56 Same emptiness in several views. Feb 04 13:55:58 your driver misses proper naming Feb 04 13:56:01 Aah. So the ]: OMAP4 <-- is the important stuff here Feb 04 13:56:03 ogra, Thanks Feb 04 13:58:35 * sveinse wish he had a running panda board to compare against. Would be easier to find the missing struct member... Feb 04 14:01:21 I seem to remember sound on the beagle getting fixed also, but without quite the same level of exhaustive detail of discussion. Feb 04 14:01:33 You might check that (unless someone says I'm completely wrong) Feb 04 14:01:49 (this assumes you have a beagle board to compare against) Feb 04 14:02:19 persia: Unforunately not Feb 04 14:03:39 You might try asking in #alsa-soc: they know heaps about the details of what needs to be present (although they do tend to work at a level of detail that may be confusing) Feb 04 14:04:54 thanks. I could take a look at the omap4 soc driver to find the "OMAP4" string. However the driver doesn't seem to be present in my kernel sources Feb 04 14:06:11 Grab the Ubuntu sources: the ti-omap4 branch from git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git Feb 04 14:06:44 Excellent! Feb 04 14:40:41 persia, I have been diffing our driver and the sdp4430.c from natty. I have a theory why it doesnt work: Our kernel people are running 2.6.38, and the members "driver_name" and "long_name" doesn't long exist in the struct snd_soc_card. Feb 04 14:41:09 Which could indicate that userspace alsa needs upgrade for everything to work :( Feb 04 14:49:31 sveinse, Which userspace alsa are you running? Feb 04 14:54:53 persia, well I'm running off maverick, so its 1.0.23+dfsg-1ubuntu4 for alsa-base Feb 04 14:55:34 That ought be fine. Feb 04 14:55:59 natty is 1.0.23+dfsg-2ubuntu1b1, which roughly translates to some packaging changes and a rebuild. Feb 04 14:56:32 I believe 1.0.24 is coming to natty soon, but I doubt aged userspace is the issue. Feb 04 14:56:59 Yet, the kernel driver has no driver_name and long_name which it seems is the missing fields from /proc/asound/cards Feb 04 14:57:28 And there is one for sdp4430? Feb 04 14:57:36 Yes Feb 04 14:58:11 Maybe look at a maverick sdp4430 (2.6.35-903.21 or so) Feb 04 14:58:28 My understanding is that it works in maverick. Feb 04 15:01:27 (if it's not in the ubuntu-natty.git tree, check ubuntu-maverick.git) Feb 04 15:01:56 I'm cloning the ubuntu-maverick git as we speak Feb 04 15:02:11 takes a while Feb 04 15:02:43 I'll wish you luck: I'll be away for the next 30+ hours. Feb 04 15:03:44 persia: Thanks Feb 04 16:06:35 hello Feb 04 16:07:34 I tested the netbook version with my Beagleboard xM rev2 (OMAP3 ) , and after "Uncompressing Linux ... done, booting the kernel" I got nothing : stalled Feb 04 16:07:59 I used: the image found here : https://wiki.ubuntu.com/ARM/OMAPMaverickInstall Feb 04 16:07:59 ericb2: that's normal, by default there are no output at the uart Feb 04 16:08:14 but you should see something at your dvi output Feb 04 16:08:30 rsalveti: does xdmi work ? Feb 04 16:08:53 rsalveti: I tested, and nothing so far, but maybe I did something wrong Feb 04 16:09:05 hdmi you mean? Feb 04 16:09:22 on xm just the connector is hdmi, but it's dvi-d Feb 04 16:09:30 you should see the resizing and then the installer Feb 04 16:09:44 rsalveti: sorry, you're right : xdmi Feb 04 16:10:03 rsalveti: I'll retry .. Feb 04 16:10:05 https://wiki.ubuntu.com/ARM/BeagleEditBootscr if you want to enable the console Feb 04 16:10:25 check "Notes about the process" at the page you posted the link Feb 04 16:10:33 there are some useful information about the process there Feb 04 16:10:59 rsalveti: thank you very much Feb 04 16:11:05 rsalveti: I'll read carefully Feb 04 16:11:12 rsalveti: btw, will you attend FOSDEM ? Feb 04 16:11:23 nops :-( Feb 04 16:11:23 rsalveti: I'll attend on sunday Feb 04 16:11:29 maybe ogra will Feb 04 16:11:35 too far for me Feb 04 16:11:46 rsalveti: ok. I'll probably take my beagleboard with me Feb 04 16:18:42 rsalveti: how to know things are ok ? The hdmi does seems to no longer work. Can this be a resolution issue ? I remember I had 1024x768@60 working or something close Feb 04 16:20:11 i wont make it to fosdem Feb 04 16:20:37 already on the road the last week of feb ... my GF would kill me if i also went to fosdem Feb 04 16:20:39 :) Feb 04 16:24:27 ericb2: rev 2 should just work Feb 04 16:24:36 could be Feb 04 16:24:42 depending on your monitor Feb 04 16:24:48 as our default resolution is higher than that Feb 04 16:24:54 try editing your bootsrc Feb 04 16:25:00 and putting a lower resolution Feb 04 16:25:59 rsalveti: that's what I'm currently doing. If if works I'll tell you Feb 04 16:26:05 ok Feb 04 16:26:36 what does "port's parent platform driver is not whitelisted" mean Feb 04 16:32:29 rsalveti: just curious: it is possible to use (mean simply copy) a working boot.scr ? Feb 04 16:33:08 s/boot.scr/bootsrc/ Feb 04 16:33:25 sure Feb 04 16:33:57 but it will be overwritten by whatever is in /boot/boot.script during installation Feb 04 16:34:11 so you should make sure they match Feb 04 16:35:01 yup, once flash-kernel (on a kernel update) is called /boot/boot.script will overwrite your boot.scr Feb 04 16:37:05 bug 517300 Feb 04 16:37:07 Launchpad bug 517300 in likewise-open "[armel] likewise-open needs porting to ARM" [High,Confirmed] https://launchpad.net/bugs/517300 Feb 04 17:51:49 I have no idea how to get this alsa profile thing going, nor can I find anything wrong with the alsa driver Feb 04 17:53:59 ogra, are you sure alsa profile is the way to do pulseaudio configuration? AFAICS its only PA which complains. Everything else done directly against alsa seems to like it should Feb 04 17:54:27 PA complains because it doesnt find the right thing to attach to Feb 04 17:54:48 fi you use a PA profile you cure the symptom but not the root cause Feb 04 17:55:30 I found this: http://www.omappedia.org/wiki/Ubuntu_PA Feb 04 17:56:43 thats super broken Feb 04 17:56:52 and we fixed it properly for the panda Feb 04 17:57:04 by fixing the driver and alsa-libs Feb 04 17:57:19 in natty audio works out of the box that way Feb 04 17:57:26 ogra, I agree. But when alasctl init doesn't get the correct descriptors and the kernel soc-audio interface has changed, I'm running out of ideas how to fix Feb 04 17:57:56 we will add PA profiles for special cases like automatically switching audio out to HDMI for example, but the basics work out of the box without PA tinkering Feb 04 17:58:13 and thats how it should be Feb 04 17:58:17 I've checked both natty and maverick omap4 kernels, and both of them has the extra text fields (if that is what's wrong then) Feb 04 17:58:32 But the latest 2.6.38 does have these fields Feb 04 17:58:33 right, make soure your driver has that too Feb 04 17:58:51 no, the struct have changed Feb 04 17:58:54 then you can reate an alsa init file Feb 04 17:59:10 sveinse: hi. sorry to interrupt ;-) what exactly are you trying to do/ Feb 04 17:59:15 that way will become the default soon with UCM Feb 04 17:59:32 ndec, getting a custom omap3 board to properly do sound Feb 04 17:59:53 ogra: argh.. .omap3 ;-) Feb 04 17:59:57 heh Feb 04 18:00:02 ndec, My custom maverick omap3 board doesn't detect my alsa drivers Feb 04 18:00:17 UCM should help OMAP3. someone will just need to write the correct config files Feb 04 18:00:48 sveinse: you mean the kernel or Pulse does not detect it? Feb 04 18:01:02 the kernel doesnt even name the card Feb 04 18:01:21 ndec, sorry a little too quick here: Yes, pulse doesn't detect it. alsamixer and aplay works Feb 04 18:02:07 cat /proc/asound/cards Feb 04 18:02:09 0 [mcbline ]: - mcbline Feb 04 18:02:10 mcbline Feb 04 18:02:12 1 [mcb1681 ]: - mcb1681 Feb 04 18:02:13 mcb1681 Feb 04 18:02:57 so the guys at pulseaudio suggest writing a udev rule to point to a profile Feb 04 18:03:15 yet, the nice people here suggest otherwise Feb 04 18:04:31 sveinse: which version of ubuntu are you targetting? Feb 04 18:05:01 ndec, currently maverick. But we'll switch to natty when its a little more stable Feb 04 18:05:14 sveinse: as ogra said, ALSA UCM is coming into natty, we are planning to get basic UCM integration in pulseaudio as well. Feb 04 18:05:32 alpha2 came out yesterday Feb 04 18:05:38 its pretty smooth Feb 04 18:05:46 sveinse: that is clearly the cleanest solution, but that might take a little while until UCM is available in pulse. Feb 04 18:06:02 is USM something which must be patched into the kernel? Feb 04 18:06:22 sveinse: no. it's alsa user space changes only. Feb 04 18:06:48 sveinse: it's new alsa API that makes it simpler to manage Use Case (hence the name) Feb 04 18:06:58 It's good to know. However, it doesn't fix my current problems though Feb 04 18:07:10 well, i think your ASoC driver needs to at least support detection Feb 04 18:07:21 even for UCM Feb 04 18:07:30 sveinse: you have config files where you define your cards profile (headset, headphonem hdmi, ...), and you select which profile to use with this new alsa API. Feb 04 18:07:42 Yes, agree. However theres so much I can do when the struct members change... Feb 04 18:07:57 sveinse: well you update the config files ;-) Feb 04 18:08:04 I've read the kernel sources and the "driver_name" and "long_name" fields have been removed from the kernel headers Feb 04 18:08:48 ndec, I have started on a alsactl script/profile Feb 04 18:09:13 However alsactl init sais 'Found hardware: "" "" "" "" ""' Feb 04 18:09:25 sveinse: ok, that's what we had initially for panda before it got fixed properly by ogra Feb 04 18:09:41 that reflects your /proc/asound/cards Feb 04 18:10:12 i only fixed the userspace Feb 04 18:10:31 well, actually i only included fixes from others in the right places :) Feb 04 18:10:51 these fixes still relied on the proper driver namings Feb 04 18:11:38 Yes, and I found this in sound/soc/omap/sdp4430.c Feb 04 18:11:40 static struct snd_soc_card snd_soc_sdp4430 = { Feb 04 18:11:41 .driver_name = "OMAP4", Feb 04 18:11:43 .long_name = "TI OMAP4 Board", Feb 04 18:12:21 But member .driver_name and .long_name is not present in struct snd_soc_card as of 2.6.38. I think that's my problem Feb 04 18:12:41 MIGHT BE Feb 04 18:12:55 OOPS Feb 04 18:12:59 sorry for caps Feb 04 18:13:22 that's ok (I hoped you weren't angry for repeating my questions :) Feb 04 18:14:24 Let me rephrase: you are now aware of any struct/interface changes to recent kernels which would mandate changes in alsa clients? Feb 04 18:14:42 s/now/not/ Feb 04 18:15:01 no, i havent looked at the kernel in natty yet Feb 04 18:15:28 lrg might be able to answer whats needed for UCM in your driver though Feb 04 18:15:40 I have cloned the ubuntu-natty kernel (for ti-omap4 branch) Feb 04 18:15:42 he is ASoC upstream (but not always around) Feb 04 18:16:42 ubuntu-natty has the missing members Feb 04 18:17:20 but that's 2.6.35-3 Feb 04 18:17:30 yeah, dont look at that one ;) Feb 04 18:20:27 it is good for maverick ... for natty there will be a new one Feb 04 18:20:48 In my search for a temporary solution: Do you know how a udev rule should be formatted for a soc alsa card? Feb 04 18:20:59 nope Feb 04 18:21:05 ask the guys that suggested that Feb 04 18:21:16 (which i suspect are fedora devs :P ) Feb 04 18:21:49 janimo: did you 4.4 build pass? Feb 04 18:22:00 NCommander, where is yours at Feb 04 18:22:10 * sveinse stuck between a hammer and a hard place :P Feb 04 18:22:14 his did Feb 04 18:22:26 we are looking for your comparison data from the full build Feb 04 18:22:27 ogra: FTBFS, but due to user error during the night. Feb 04 18:22:51 gah Feb 04 18:23:03 ogra: yeah Feb 04 18:23:06 stop sobbing on your panda while you sleep :P Feb 04 18:23:26 ogra: but it makes those fun blue flashes when I do! Feb 04 18:23:31 lol Feb 04 18:23:35 well, monday than Feb 04 18:23:37 More like drunken debauchery. Feb 04 18:23:38 *then Feb 04 18:23:51 GrueMaster, stop giving him beer ! Feb 04 18:23:59 especially the strong self brewed one Feb 04 18:24:08 Beer, pfft. We has Vodka! Feb 04 18:24:16 ogra: GrueBrew is the only flat beer I ever experienced :-( Feb 04 18:24:32 NCommander, i have other bad news for you to make your morning even prettier :) Feb 04 18:24:54 ogra: -_-;;; Feb 04 18:24:55 what? Feb 04 18:24:59 NCommander, zul asked for help with bug 517300 Feb 04 18:25:00 Launchpad bug 517300 in likewise-open "[armel] likewise-open needs porting to ARM" [High,Confirmed] https://launchpad.net/bugs/517300 Feb 04 18:25:15 he handles upstream and the package went back to -server now Feb 04 18:25:26 ogra: oh, thats straightforward (if a bit tedious) Feb 04 18:25:31 but he needs help so that the patch applies cleanly to new upstream Feb 04 18:26:04 i dont think its super urgent but having it sorted by release would be good Feb 04 18:26:17 please talk to zul about it Feb 04 18:26:22 ogra: will do Feb 04 18:26:27 thanks :) Feb 04 18:26:40 * NCommander tries another qt4-x11 test build Feb 04 18:27:02 NCommander, so janimo's build with 4.4 exposed the same issues Feb 04 18:27:16 ogra: I thought you said his 4.4 build worked Feb 04 18:27:21 thats why we need to have yours to verify its not something thats linked in from other files Feb 04 18:27:42 hrm Feb 04 18:27:46 * NCommander checks somehitng Feb 04 18:27:49 no, i meant it built and showed (from his perspective) that its not 4.4 Feb 04 18:27:59 or not 4.5 Feb 04 18:28:05 however you want to put it Feb 04 18:28:17 hrm Feb 04 18:28:25 so a full package build to prove that is needed Feb 04 18:28:32 then we can hassle upstream QT Feb 04 18:28:35 * NCommander has a theory ... Feb 04 18:29:02 janimo: can you do a partial rebuild, but drop the kubuntu_22_thumb patch while I do a full rebuild, and try that? Feb 04 18:29:25 can we first follow the plan we worked out before we drop other patches ? Feb 04 18:30:04 i mean jani is done with his part he can surely move forward there but we need your package too Feb 04 18:30:09 ogra: I am Feb 04 18:30:16 ogra: but I just want to test that theory Feb 04 18:30:31 yep, understood Feb 04 18:30:41 It's not going to build without the22_thumb patch I don't think. Feb 04 18:30:52 ogra: since I broke the qt4-x11 build on maverick (gcc-4.4) with that patch Feb 04 18:30:57 it might be causing a false-negative Feb 04 18:31:17 NCommander, well,, we first need proof for janis results Feb 04 18:31:30 one step at a time Feb 04 18:31:41 NCommander, isn't that patch the IT one? Feb 04 18:32:48 It is Feb 04 18:32:55 ogra, I still have things to check. This bug bothers me so much I cannot let it rest Feb 04 18:33:20 janimo, i didnt say you should let it rest ;) Feb 04 18:33:23 janimo: yeah, since when it was applied it caused explosions on Maverick Feb 04 18:33:33 janimo, but we need comparison data Feb 04 18:34:15 NCommander, when was it applied ? i run unity-2d just fine on maverick with the QT from -updates Feb 04 18:34:50 That patch content doesn't exist in maverick Feb 04 18:35:06 Maverick didn't need it due to implicit IT. Feb 04 18:35:06 how did it cause explosions then ? Feb 04 18:35:17 * ogra doesnt get it Feb 04 18:35:19 Not sure. Feb 04 18:35:37 IIRC there's a patch of the same name in Maverick, but with different content. Feb 04 18:35:40 * ScottK checks Feb 04 18:35:42 ogra: I applied it ot a maverick build of qt-4.7.0 and it caused a segfault similar to the one we were seeing Feb 04 18:35:58 ah Feb 04 18:36:52 ogra, where can I find a recent omap4 kernel for natty? Feb 04 18:37:03 sveinse, nowehere yet Feb 04 18:37:12 whats in natty is the most recent we have Feb 04 18:37:37 sveinse: In natty, we are currently still on 2.6.35 Feb 04 18:37:42 there is a linaro build from upstream but that wont work much and afaik doesnt have any sound stuff yet Feb 04 18:38:08 the .38 port is in the works but will still take a while Feb 04 18:40:34 go figure Feb 04 18:50:46 There is a .38 kernel for omap3 though. Feb 04 19:03:10 GrueMaster: How does a omap3 .38 system look like in respect of /proc/asound/cards Feb 04 19:03:17 Anyone running .38 here? Feb 04 19:04:51 I curious to learn if there indeed are changes to the overall soc alsa system, or if the problems are related to our system only Feb 04 19:06:44 sveinse: http://paste.ubuntu.com/562698 Feb 04 19:07:34 same thing as I'm seeing. That's somewhat comforting Feb 04 19:07:51 you have pulseaudio running on this system? Feb 04 19:08:05 not if you know that audio is currently not working on omap3 in natty ;) Feb 04 19:08:18 Yes, although pulse currently can't control the volume. Had to do that manually in alsamixer. Feb 04 19:08:22 it also waits for UCM Feb 04 19:08:22 playback is ok. Feb 04 19:08:51 GrueMaster, that's *exactly* my problems as well Feb 04 19:09:22 please dont jusdge by the half done audio in omap3 in natty yet Feb 04 19:09:35 thats being worked out Feb 04 19:09:50 (by lrg) Feb 04 19:09:51 no, but the symptoms are equal Feb 04 19:10:07 yes, but that doesnt help you in any way Feb 04 19:10:15 GrueMaster, what happens if you run alsactl init on your system? Feb 04 19:10:22 UCM isnt ready yet and the driver needs adjustment Feb 04 19:10:36 * ogra sighs Feb 04 19:10:37 sveinse: If you can get audio to at least work with alsamixer & aplay, pulse playback should work. Feb 04 19:10:50 If not, there are sink issues. Feb 04 19:11:02 ogra, true. And I'm considering the pulseaudio profile "fix" (to call it that) as a temporary workaround until UCM arrives Feb 04 19:11:38 might be your way to go if you cant fix the driver the same way we did in maverick Feb 04 19:11:47 GrueMaster: Yes, but we need HW volume control. With SW volume control you lose resolution Feb 04 19:12:42 sveinse: I understand. Just saying that sometimes you need to take it one step at a time. If you have pulse playback, that's half the battle. Feb 04 19:13:21 GrueMaster: Agree, but not my boss. He needs full fledge audio with volume control Feb 04 19:13:25 ogra, because we're on .38, it isn't that easy as the required driver fields are removed. Which GrueMater now confirms Feb 04 19:13:48 if you want to use natty, wait for UCM and possible additional fixes to ASoC, if you want to use maverick either fix the driver like we did for omap4 or go with your workaround Feb 04 19:14:17 i would expect these fields to return in some way or the other Feb 04 19:14:32 release is still a year away, so we will have the opportunity to jump to natty and UCM Feb 04 19:14:32 or UCM to handle it without name Feb 04 19:15:35 sveinse: You could get a jump on UCM by pulling the 1.0.24 tarballs from alsa-project.org. Or waiting for them to show up here in a week or so. Feb 04 19:15:58 ogra, I do too. It wouldn't surprise me to see that the alsa user tools need change for .38 Feb 04 19:16:10 they did already Feb 04 19:16:19 they are just not in the archive yet Feb 04 19:16:20 in a week or so... for natty then? Feb 04 19:16:38 That's the plan as I understand it. Feb 04 19:16:52 We had a soft freeze for Alpha 2 release. Feb 04 19:17:15 And alsa 1.0.24 was just released late last week. Feb 04 19:17:28 How natty doing? I'm eager to switch, however I can't break everyone's system. That would be expensive Feb 04 19:18:09 Alpha 2 is very stable on beagle/xm, and panda. But we will be switching the UI as soon as we can fix the QT issues. Feb 04 19:18:15 * ogra is afk now Feb 04 19:19:19 Talking of Qt issues: what are those? We are running qt on our system (but against qws though) and have had issues. perhaps I can contribute with something? Feb 04 19:20:01 what kind of issues are you having? Feb 04 19:20:28 We are currently seeing a segfault in the core libraries on natty. Works fine on Maverick. Problem is the 25 hour build times. Feb 04 19:20:47 Hard to narrow down the bug with long build times. Feb 04 19:20:53 sveinse: I believe yours could be more related with qws Feb 04 19:20:59 don't know if it's well tested and etc Feb 04 19:21:00 ah, you build natively, right Feb 04 19:21:19 yup :-) Feb 04 19:21:50 sveinse: Here's the bug we are tracking if you are interested. Bug 705689 Feb 04 19:21:50 Launchpad bug 705689 in qt4-x11 "unity-2d-launcher crashes with segfault error on armel (natty only)" [High,Confirmed] https://launchpad.net/bugs/705689 Feb 04 19:22:46 And I should change the description to "QT Apps crash..." as we can reproduce it with other programs. Feb 04 19:23:06 well, atm qt-qws is working ok (not perfect) for us. We still have opengl integration issues (thank you Imagem) Feb 04 19:23:42 I just *love* the binary driver thingy Feb 04 19:26:20 Some of the guys in our project told me they had problems compiling Qt properly with the ubuntu/linaro gcc, while the CSL works perfectly. It smells similar when reading the 705689 bug Feb 04 19:27:39 sorry for not have more elaborate details, and I don't have any repeatable procedures to back up my claims **** ENDING LOGGING AT Sat Feb 05 02:59:57 2011