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