[00:06] <rsalveti> GrueMaster: can you also try to update to the latest kernel?
[00:06] <rsalveti> the rc4 based one should be available already
[00:07] <GrueMaster> I didn't see it in the pool yet, but I'll check launchpad.
[00:08] <rsalveti> https://launchpad.net/ubuntu/+source/linux/2.6.38-3.30/+buildjob/2252836
[00:10] <GrueMaster> Yea, finished 16 minutes ago.  That's why.
[00:10] <GrueMaster> Heh.
[00:10] <rsalveti> hehe
[00:11] <persia> Hrm?  Says finished 7 hours ago for me.
[00:11] <GrueMaster> https://launchpad.net/ubuntu/+source/linux-meta/2.6.38.3.17/+buildjob/2255077
[00:12] <GrueMaster> That's what is currently published (or in the que).
[00:12] <persia> Ah.  That's probably still stuck in the publisher.
[00:12] <persia> But it finished enough before the hour that it ought be in this run, rather than waiting until the next run.
[00:13] <GrueMaster> Right, but last I was told, the publishing run starts at ~:05 and finishes at :40.
[00:13]  * npitre sees a pending interrupt for himself here
[00:13] <GrueMaster> So I only have to wait another 30 minutes.
[00:14] <persia> npitre, I've been trying to package an imx51 kernel tree with sascha's tree + patches from rtp + ubuntu sauce.  lool advised me you were the gatekeeper for linux-linaro-imx51, and I should send you patches and use your package.
[00:15] <persia> npitre, Since the last upload is 2.6.37, I'll try to sort out what patches I have that are relevant to the efika boards, and prepare a tree for your review.
[00:15] <npitre> persia: no problem
[00:16] <persia> npitre, For reference, rtp's work is a quilt patchset at git://git.rtp-net.org/efika.git
[00:16] <npitre> persia: what is rtp?
[00:17] <persia> npitre, Arnaud Patard
[00:17] <npitre> persia: fyi, the linaro tree should move to 2.6.38-rc5 once released
[00:18] <persia> npitre, Excellent.  If your 2.6.37 boots on the hardware, I'll postpone sending you patches until after the move.  If not, I may send you a few in advance.
[00:19] <npitre> persia: OK, as lool hinted I'm not that good at tracking irc so feel free to send me an email if you have something you want included in the linaro kernel
[00:20] <persia> npitre, Absolutely :)  I'm not that good at tracking email: thanks for having the initial discussion with me here.
[00:21] <npitre> persia: you may try to ping me on irc, but sometimes this might take hours before I notice
[00:22] <persia> npitre, I'll send you email once I have something substantive.  For now, I'm waiting on a test report for the Efika MX with your kernel.
[00:22] <npitre> persia: OK
[01:08] <rsalveti> cooloney: hey, are you back already?
[01:11] <cooloney> rsalveti: yeah, man
[01:11] <cooloney> rsalveti: how's going?
[01:11] <rsalveti> cooloney: good, and you?
[01:11] <rsalveti> refreshed?
[01:12] <cooloney> rsalveti: heh, actually a little bit tired
[01:12] <cooloney> rsalveti: any news?
[01:12] <rsalveti> cooloney: well, weekend ahead :-)
[01:12] <rsalveti> cooloney: well, some :-)
[01:12] <rsalveti> we got a ti-omap4-dev branch
[01:12] <rsalveti> as you probably know already
[01:13] <rsalveti> cooloney: one thing I'd like to ask you is if you can test and merge the DVI patches for panda
[01:13] <rsalveti> for 2.6.38
[01:13] <rsalveti> so we can have a working display with this kernel
[01:13] <rsalveti> as my panda has a broken dvi, can't test atm
[01:13] <rsalveti> look at l-o for [PATCH] OMAP4: PandaBoard: Adding DVI support
[01:14] <cooloney> rsalveti: sure, i will do it today
[01:14] <cooloney> i got that HDMI-DVI cable
[01:15] <rsalveti> cooloney: cool
[01:15] <cooloney> rsalveti: is this one?
[01:15] <rsalveti> but even the hdmi cable should work
[01:15] <cooloney> [PATCH] OMAP4: PandaBoard: Adding DVI support
[01:15] <rsalveti> cooloney: yup
[01:15] <rsalveti> rcn-ee said it worked fine for him
[01:15] <rsalveti> so it should just work
[01:15] <rsalveti> if it's the case, try sending it to this branch
[01:15] <cooloney> it's from Raghuveer Murthy <raghuveer.murthy@ti.com>
[01:15] <rsalveti> ti-omap4-dev
[01:15] <rsalveti> cooloney: yup, that's the one
[01:16] <cooloney> OK, i got it
[01:16] <cooloney> so will we get .38 patches soon?
[01:17] <rsalveti> cooloney: not directly from serbjan, probably from linaro
[01:18] <rsalveti> or something like that
[01:18] <cooloney> rsalveti: right, i know Andy Green is working with sebjan on that
[01:18] <rsalveti> yeah
[01:19] <cooloney> rsalveti: thx a lot for this info.
[01:19] <cooloney> i will test that DVI patch and try to push to ti-omap4-dev
[01:21]  * cooloney just update his machine, needs reboot, brb
[02:18] <cooloney> rsalveti: does our ti-omap-dev branch kernel supports graphic, since i wanna test that DVI patch.
[02:18] <persia> It should.
[02:18] <rsalveti> cooloney: probably
[02:19] <rsalveti> cooloney: you just need to check if you have all the dependencies, like described at the patch
[02:19] <cooloney> rsalveti: i think it is based on 2.6.38-rc kernel which miss some graphic support.
[02:19] <rsalveti> but as we're basically using the same one as master (rc4), and rcn-ee said it worked fine for him, I expect this patch to be enough to get the display working
[02:20] <cooloney> rsalveti: OK, I will try it soon
[04:17] <rcn-ee> rsalveti, did you get the display working on the panda with 2.6.38-rc4?
[04:18] <persia> rcn-ee, backscroll reports that rsalveti is having issues with the DVI port : cooloney had volunteered to look at the relevant patch.
[04:20] <rcn-ee> ah, interesting..  Could be something with the  monitors i have here..
[04:21] <persia> No, it's something with rsalveti's hardware
[04:22] <persia> quoting "as my panda has a broken dvi, can't test atm"
[04:22] <persia> Unless you had a HW hack to fix that?
[04:22] <cooloney> rcn-ee: yeah, i am working on that
[04:22] <rcn-ee> ah i see, (working my back in the scroll log.. )
[04:22] <cooloney> rcn-ee: so mainline 2.6.38-rc4 kernel does support graphic things on Panda?
[04:23] <rcn-ee> mainline + plus the patches posted on wednesday..
[04:24] <rcn-ee> cooloney, these work on my panda a1.. http://dev.omapzoom.org/?p=anand/linux-omap-usb.git;a=shortlog;h=refs/heads/display-patches-for-v2.6.38-rc4  and they don't seem to break my c4 beagle board with the same uImage
[04:24] <cooloney> rcn-ee: right, i pull the branch from Anand's display-patches-for-v2.6.38-rc4
[04:24] <cooloney> rcn-ee: yeah, exactly
[04:24] <cooloney> rcn-ee: what's kind of root fs you are testing for this?
[04:25] <rcn-ee> the one thing i haven't tested is the edid stuff, so i did a "1024x768" value on the bootargs...  on that boot test, maverick...
[04:31] <lilstevie> is anyone here good at fbdev :p
[04:36] <persia> lilstevie, Try asking the question you'd ask if someone said "yes".  Someone might not consider themselves good, but may know the answer to your specific question.
[04:36] <lilstevie> heh well I have no idea what is wrong
[04:36] <lilstevie> the screen blinks the backlight on and off
[04:38] <persia> What board?  Which image?
[04:41] <lilstevie> rootstock made image
[04:41] <lilstevie> and not a usual board :p
[04:41] <lilstevie> galaxy tab
[04:43] <persia> Heh, that makes it tricky :)
[04:44] <persia> I'm not even sure what question would be useful to ask next (I know I don't know the solution to your problem, but I can usually get a bit further in the script :) )
[04:46] <lilstevie> heh
[04:46] <lilstevie> I do have logs
[04:46] <lilstevie> and interactivity over ssh
[04:50] <cooloney> rcn-ee: sorry, i was dropped
[04:52] <rcn-ee> np cooloney, i believe i tested it on maverick, (defined the video x/y in the bootargs, didn't do edid).. but it might have been lucid/squeeze, i was testing other userspace things at the time..
[04:53] <cooloney> rcn-ee: great, i am testing it with our natty userspace and wanna apply those patches to our ubuntu 2.6.38 based kernel
[04:53] <rcn-ee> is this for the ppa one mentioned on the ubuntu-kernel list earlyier this week?
[04:54] <cooloney> rcn-ee: from Anand Gadiyar's branch, i found 35+ patches on top of 2.6.38-rc4
[04:55] <cooloney> rcn-ee: yeah, it is our ti-omap4-dev branch which is 2.6.38 based branch
[04:55] <cooloney> i think for ti-omap4 stuff, it is almost the same as mainline
[04:56] <rcn-ee> that's pretty strange, shouldn't have been that much..
[04:56] <rcn-ee> i know there's 4-5 omap specfic ones that were merged in the rc3-rc4 so that wouldn't add up either..
[04:57] <rcn-ee> (crap wrong patchset... it's 35..)
[04:57] <cooloney> rcn-ee: from Raghuveer Murthy's description in DVI patch, it is only depends on 6 patches
[04:58] <cooloney> rcn-ee: but i think pure 2.6.38-rc4 does not include DSS patches which is required for graphic on OMAP4 like panda
[05:00] <rcn-ee> yeah, 2.6.38-rc4 only has the omap4 ehci/musb bits, nothing really else.. those 35 on top of that were enough for my dvi port to correctly work on the panda...
[05:04] <cooloney> rcn-ee: so how did you test that DVI patch? apply those 6+1 patches on 2.6.38-rc4 kernel?
[05:05] <rcn-ee> i applied the 35 on top of my current 2.6.38-rc4 tree.. https://github.com/RobertCNelson/2.6.38-devel/blob/master/patch.sh#L160
[05:11] <cooloney> rcn-ee: ok, cool, man
[05:12] <rcn-ee> yeah, rereading it on the linux-omap archive, Murthy does mention the other 6 patches, but it looks like Anand Gadiyar merged those 6 depencies into the group of 35..
[08:05] <sebjan> rsalveti, cooloney: I already have a branch with the DVI patches working
[08:06] <cooloney> sebjan: thanks a lot
[08:06] <cooloney> sebjan: i'm just trying the DVI branch from Raghuveer Murthy
[08:07] <cooloney> wanna apply those 35 patches in Anand Gadiyar's branch, but it failed on our ti-omap4-dev branch
[08:07] <cooloney> some conflict
[08:10] <sebjan> cooloney: I did not try yet to apply them on the ti-omap4-dev branch, I currently work on mainline (.38-rc4)
[08:11] <cooloney> sebjan: yeah, i know some conflicts there, will try to solve them
[08:11] <cooloney> and prepare a branch to test
[08:11] <cooloney> sebjan: but i am not sure about those patches from Anand Gadiyar's branch, will they be merged into mainline?
[08:12] <cooloney> it's about 35 patches
[08:13] <sebjan> cooloney: they are reviewed on LO, but not sure about their status
[08:13] <cooloney> sebjan: ok, so how about your patches?
[08:13] <cooloney> DVI patches?
[08:14] <sebjan> cooloney: let me clean and retest my branch and I send it to you (but tis shall be very similar to Anand's one)
[08:14] <cooloney> sebjan: great, I will try Anand's soon after i solve those conflicts
[08:17] <sebjan> cooloney: here is my git / tag: git://github.com/sebjan/linux-2.6.git topic-wlan-iv1-2.6.38-rc4 (https://github.com/sebjan/linux-2.6/tree/topic-wlan-iv1-2.6.38-rc4)
[08:18] <sebjan> I have DVI working (from DVI connector P1)
[08:19] <sebjan> and can choose the screen definition with these bootargs for ex: omapfb.mode=dvi:1024x768MR-24@60 omapdss.def_disp=dvi
[10:30] <NishanthMenon> slnr, hi
[10:30] <slnr> hi
[10:30] <NishanthMenon> slnr, can you share the issue with gst-launch with mp3 decoder and filesink with ndec
[10:30] <NishanthMenon> ndec, ping
[10:31] <slnr> gst-launch filesrc location=test.mp3 ! mad ! filesink location=test.pcm
[10:31] <slnr> this is working fine
[10:31] <slnr> gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
[10:31] <slnr> this is not working
[10:31] <NishanthMenon> slnr, this is for OMAP4 rt?
[10:31] <slnr> yes
[10:32] <NishanthMenon> slnr, one more place to ping is #gst_ti
[10:32] <slnr> thanks
[10:32] <NishanthMenon> slnr, np
[10:32] <slnr> we will try to join that channel
[10:32] <NishanthMenon> ndec, know anything about this pipe failing with ubuntu?
[10:32] <persia> slnr, You have the omx packages installed, right?  (just for confirmation)
[10:33] <NishanthMenon> persia, good Q -> slnr try gst-inspect | grep omx_mp3dec
[10:33] <slnr> it is there
[10:33] <NishanthMenon> slnr, does fakesink work?
[10:33] <slnr> yes
[10:34]  * NishanthMenon out of cookies :( defers to ubuntu experts
[10:34] <slnr> yes
[10:34] <slnr> we will try this and let you know
[10:35] <NishanthMenon> slnr, ?? did you mean, you are now going to try gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink ?
[10:35] <slnr> yes we tried
[10:35] <slnr> with fakesink
[10:35] <cooloney> sebjan: do you have the kernel config file for dvi patches testing?
[10:35] <slnr> it works properly
[10:36] <NishanthMenon> slnr, k.. /me out of ideas here..
[10:36] <slnr> one sec
[10:36] <slnr> we will cross check this pipeline once
[10:36] <NishanthMenon> and alsasink works?
[10:36] <sebjan> cooloney: yes, I have 2: one is minimal, and the other is an Ubuntu-like one. They are located into arch/arm/configs/omap4_panda_* (the 'full' one is an Ubuntu like)
[10:37] <slnr> with alsasink it is working
[10:37] <slnr> we just checked fakesink
[10:37] <slnr> it fails
[10:37] <persia> fakesink fails and alsasink works?
[10:37] <sebjan> cooloney: the minimal one also boots with an Ubuntu FS (issue was: not devtmps + .38 issue with omap2plus and ARMv7 SMP)
[10:37] <cooloney> sebjan: is it in the github?
[10:37] <slnr> yes
[10:38] <slnr> persia: yes
[10:38] <sebjan> cooloney: yes shall be. let me cross-check
[10:38] <persia> slnr, That's unexpected.  If fakesink fails, nothing ought to work, or something is very odd.
[10:38] <slnr> ok
[10:39] <NishanthMenon> slnr, can you post the log on pastebin.mozilla.org and provide us a link of what you see with gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink
[10:39] <slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec !  fakesink/filesink fails
[10:39] <sebjan> cooloney: confirmed, they are in my branch on github
[10:39] <persia> Or paste.ubuntu.com :)  Lots of choices.
[10:39] <slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works
[10:40] <persia> Then it's beyond what I know about gstreamer.  I've always believed that fakesink was a no-op.
[10:40] <NishanthMenon> slnr, might help us to see the log. dont post the log straight here, instead post it to the paste.ubuntu.com and provide us the link
[10:40] <slnr> NM: ok
[10:40] <slnr> sure
[10:41] <NishanthMenon> persia, i agree, I'd think of it as cat file>/dev/null fails and /dev/dsp works! hmm.. mebbe some weird handshaking requirements?
[10:42] <persia> Heh, yeah, that's my thought.  But there are plenty of people more knowledgeable about gstreamer than I (although at this time of day, it may be a long wait until they are awake)
[10:42] <slnr> NM: we are capturing the log and we will provide the link on pastbin in few mins
[10:42] <NishanthMenon> slnr, thx.. mebbe you should check with #gstreamer as well in addition to #gst_ti.. u'd get a bunch of gstreamer experts there
[10:43] <slnr> NM: ok
[10:43]  * NishanthMenon suspects it might have something to do with ti gstreamer omx implementation
[10:43] <NishanthMenon> some caps negotiation or something "implicitly expected by ducati"..
[10:44] <NishanthMenon> sebjan, know who can help?
[10:44]  * NishanthMenon hopes france folks not away on lunch yet ;)
[10:44] <sebjan> NishanthMenon: not yet :)
[10:45] <NishanthMenon> sebjan, :D gstreamer issue pretty much needing someone knowing gstreamer and omx_ti :( know anyone lurking arnd?
[10:45] <cooloney> sebjan: i think we need enable the graphic driver for the DVI testing
[10:45] <cooloney> sebjan: but it is disabled in your config
[10:47] <ndec> NishanthMenon: hi
[10:47] <slnr> NM: http://pastebin.mozilla.org/1047108
[10:47] <NishanthMenon> ndec, good afternoon :)
[10:47] <ndec> NishanthMenon: sorry was in meeting.. what's the problem?
[10:47] <ndec> NishanthMenon: well, technically it's not noon yet ;-)
[10:47] <ndec> NishanthMenon: where are u?
[10:47] <NishanthMenon> ndec, slnr has this problem with gstreamer
[10:47] <slnr> NM: you can see the logs
[10:47] <NishanthMenon> ndec, blore atm
[10:48] <NishanthMenon> slnr, yep
[10:48] <NishanthMenon> ndec, can you glance at the log from slnr? looks like swapping the sink to fakesink instead of alsasink fails
[10:48] <ndec> NishanthMenon: slnr: for audio MP3 we do not support OMX anymore. that was only on OMAP3
[10:49] <NishanthMenon> ndec, how come alsasink works then?
[10:50] <slnr> NM: we have run a video pipeline and
[10:50] <ndec> NishanthMenon: ok.. too much backlog. can you summarize which pipeline fail?
[10:50] <NishanthMenon> and looking at the log, it seems to go to GstOmxH264Dec:omxh264dec0!
[10:50] <slnr> we have pasted the logs
[10:50] <NishanthMenon> slnr, do u have any mp3 logs?
[10:50] <NishanthMenon> not mp4 logs
[10:50] <ndec> slnr: for gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
[10:51] <slnr> ndec: we will test mp3 too and paste
[10:51] <NishanthMenon> slnr, the log you pasted is for video h264_dec!
[10:51] <ndec> slnr: this is not expected to work. in fact we should removed the omx_mp3dec element for OMAP4 since it's not supported. on OMAP4 audio is thourhg ffmpeg, mad, libaac only
[10:51] <slnr> ndec: ok
[10:51] <NishanthMenon> slnr, have you really tested it?
[10:52] <ndec> for the video pipeline using omx_h264dec element and fakesink, I think it's failing because the sink is expected to be 'tiler aware' which fakesink isn't
[10:52] <slnr> ndec: can you analyse the video log
[10:52] <ndec> slnr: does the video pipeline work with v4l2sink?
[10:52] <slnr> NM: the log we capture fir video is now
[10:52] <slnr> yes
[10:52] <NishanthMenon> ndec, so no go for filesink or fakesink? sad..
[10:52] <slnr> ndec: yes
[10:52] <sebjan> cooloney: right, I just see Idid not upgrade the 'full' config with the display... The minimal one is up to date. Check the last commit for the relevant changes (otherwise, the minimal config can boot on a Ubuntu FS)
[10:52] <NishanthMenon> slnr, yeah.. wondering how you claimed mp3 worked before
[10:53] <NishanthMenon> quote "<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works"
[10:53] <slnr> NM: that was one ex
[10:53] <slnr> NM: our colleague quoted as saying
[10:53] <NishanthMenon> k, looks like it is wrong info
[10:53] <slnr> NM: we were looking to video mainly
[10:53] <NishanthMenon> ndec, any chance of looping video output to a file?
[10:54] <NishanthMenon> some tileraware component that can route data to file/fakesink?
[10:55] <slnr> i am unable to route video output to fakesink/filesink
[10:55] <NishanthMenon> slnr, if you notice what ndec said, your sink should be tile aware. obviously file/fakesink is not and hence it fails
[10:55] <NishanthMenon> v4l2sink is probably aware and should work
[10:56]  * NishanthMenon wonders if there is something to route the video data to a file, helps for debugging usually - e.g. ssim comparison etc.
[10:57] <slnr> NM: yes v4l2sink works, how to make filesink tile aware?
[10:57] <cooloney> sebjan: https://github.com/sebjan/linux-2.6/blob/topic-wlan-iv1-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig also disabled DSS drivers
[10:57] <ndec> NishanthMenon: to do this you need to copy the tiler buffer in a regular buffer, robclark would know more about this, he did it in gst-ducati. so with gst-ducati you can have a filesink. the plugin will check for the capabilities of the sink, and will do the necessaru
[10:57] <ndec> /necessaru/necessary/
[10:57] <NishanthMenon> ndec, ok.. looks like a few more hrs before robclark appears
[10:58] <ndec> NishanthMenon: so for ex, with gst-ducati you can do video transcoding which you can't do with OMX ;-)
[10:58] <NishanthMenon> ndec, thx for the tip ;) I get the message - "more limitations of OMX" yet again :P
[10:58] <NishanthMenon> ndec, do you package gst-ducati with ubuntu?
[10:59] <slnr> NM: can this be downloaded from the net??
[10:59] <sebjan> cooloney: please look at my iv2 tag: https://github.com/sebjan/linux-2.6/tree/topic-dvi-iv2-2.6.38-rc4
[11:00] <sebjan> cooloney: DSS and DPI are activated here: https://github.com/sebjan/linux-2.6/blob/topic-dvi-iv2-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig
[11:00] <NishanthMenon> ndec, dunno.. u need to catch robclark when he comes online
[11:00] <NishanthMenon> s/ndec/slnr
[11:02] <slnr> NM: so my pipeline will look like omx_h264dec ! gst-ducati ! filesink location=test.yuv
[11:02] <slnr> NM: is this assumption correct??
[11:02] <cooloney> sebjan: thanks a lot, i looked at iv1 tag
[11:03] <sebjan> cooloney: np
[11:03] <cooloney> sebjan: so generally, it needs to enable DPI and Generic panel, right?
[11:03] <NishanthMenon> slnr, i dont think it will be gst-ducati.. it probably will have different component name - ask robclark
[11:03] <sebjan> cooloney: yes
[11:04] <persia> janimo, So, the nature of omap4 only specifies booting from MMC: it doesn't specify whether that is SD or eMMC or what.  As a result, depending on the final retail design, it's perfectly conceivable that you'd end up writing internal flash when writing to MMC on some device.
[11:04] <slnr> NM:  Thanks for the information
[11:05] <janimo> persia, well I am not sure what else can be done to make this safer, short of not implementing the spec, but I am open to suggestions :)
[11:05] <persia> janimo, But if you're special-casing only development boards, and won't be doing anything for retail devices, it's probably safe (and most developers like to be able to use newer bootloaders anyway)
[11:05] <janimo> persia, I don't know anytihng about retails devices. You mean future tables and ARM based OEM sutff?
[11:06] <janimo> If so they are tweaked by OEM anyway to prevent all kinds of snafu I hope
[11:06] <persia> janimo, Doesn't have to be future, if you consider OMAP3
[11:06] <persia> And if you presume that some OSV will tweak the OS, you are presuming nobody will want to run Ubuntu regularly, which I think is an unfortunate presumption.
[11:07] <janimo> persia, rsalveti and ogra know more about the rationale and potential drawbacks than I do
[11:07] <janimo> persia, I am not presuming but this is what I understood from the stories regarding OEM customization of Ubuntu
[11:07] <janimo> that almost all are not quite vanilla images
[11:07] <persia> janimo, I'm not suggesting you don't implement: just asking for care to make sure it only affects the development boards.  Retail shoppers don't tend to be as adept at recovering from bricked devices.
[11:08] <janimo> persia, sure
[11:09] <janimo> that is why probabaly the spec stated it should not be automatic
[11:09] <persia> Most likely :)
[11:12] <alf__> Hi! Any idea if Ubuntu can be run on Archos 101 tablets? It can supposedly run Angstrom, so I guess in the worst case someone can use the kernel from that.
[11:14] <persia> alf__, Which processor do they use?
[11:15] <alf__> persia: They only say "ARM Cortex A8 at 1 GHz with DSP"
[11:15] <persia> alf__, Should work fine.  Needs investigation to ensure you can get a working kernel, but userspace ought have no issues.
[11:16] <janimo> persia, in the meantime if you have suggestions about how to best solve the notification part of this BP I'd appreciate it. So far I was told about update-motd, jockey and debconf notes
[11:17] <persia> What's the BP URL?
[11:17] <janimo> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
[11:17] <alf__> persia: aha, some more investigation reveals it is OMAP 3630, so it should be fine
[11:17] <persia> And here I was hoping that was about porting coreboot :(
[11:18] <janimo> persia, do you think that woudl make sense for these boards?
[11:18] <persia> janimo, Reading the spec makes me feel a lot more comfortable in general.
[11:18] <persia> Looks like we use the normal package update mechanism to update files, but never actually change the boot process.
[11:18] <janimo> right
[11:19] <persia> And then there is a tool that allows the user to install new boot files, if they like.
[11:19] <janimo> although the installation of packages was questioned by ogra recently
[11:19] <janimo> but then I am not sure if getting them is not much more hassle
[11:19] <janimo> I'd rather apt&co would take care of that part
[11:19] <persia> I like packages.  We know how to deal with packages.  That we don't actually deploy the delivered code is not so important.
[11:20] <janimo> persia, I agree
[11:20] <persia> I'd suggest using the update-notifier mechanism to suggest to the user that they run the update tool.
[11:20] <persia> And maybe jockey to select the correct bootloader package to track, which would trigger the tool
[11:21] <persia> (if the bootloaders all stuff things in /usr/share/bootloaders/... and the package in question has a trigger on the directory, and that trigger enables update-notifier, etc.
[11:22] <persia> Because for a beagle A2, it would be nice to update the bootloader, but for the Archos 101 above, it's probably risky, at best, while we otherwise probably support the hardware reasonably.
[11:22] <cooloney> sebjan: that's great, i saw our Natty Unity graphic via DVI port now
[11:22] <cooloney> sebjan: i applied the patches on top of our ti-omap4-dev branch
[11:22] <janimo> persia, do the above work just as well in headless mode?
[11:23] <persia> triggers do.  I don't know about update-notifier.  You might want to have the trigger leverage both update-notifier and update-motd to handle both cases.
[11:24] <persia> Nothing is going to handle remote X terminals well, but that's significantly less common than ssh sessions, console logins, or GUI environments.
[11:35] <ogra> persia, the prob is that we cant seed it ... i'm not against packages
[11:35] <persia> I'd be against seeding as well :)  Thanks for the clarification.
[11:36] <ogra> i dont care how we get the binaries as long as we do get them in the right place with a single command
[11:36] <ogra> if there are packages involved or if someone just dpkg -x'es them to /tmp, i totally dont care
[11:36] <janimo> ogra, what about sort-of seeding via livecd-rootfs?
[11:37] <ogra> fine with me as well
[11:37] <janimo> ogra, as wgetting and figuring out version and generally doing apt's job is not too useful
[11:37] <janimo> great
[11:37] <ogra> apt-get -d <packagename>
[11:37] <ogra> ;)
[11:37] <persia> I'd prefer jockey to livecd-rootfs
[11:37] <ogra> no wget needed
[11:38] <persia> Just because, if things go as I hope, we'll see a wider variety of devices capable of using a common image.
[11:38] <ogra> jockey doesnt really fell like it would fit the task
[11:38] <ogra> *feel
[11:38] <janimo> persia,  have no idea how jockey can be used here, do you have some pointers?
[11:38] <janimo> does it not already know about packages being available?
[11:39] <ogra> jockeys backend probably has checks and stuff
[11:39] <ogra> but i wouldnt use the frontend here
[11:40] <persia> jockey has a means to determine what hardware is present, and then encourage the installation of specific packages that help.
[11:40] <ogra> iirc it talks about third party drivers and enabling additional HW in its UI
[11:40] <persia> But, as ogra points out, it's probably only good to use the backend to get the data packages: the front-end is too inviting for the easily confused, and too annoying for the bare-metal types.
[11:40] <ogra> we do neither here
[11:43] <kish> hi.. i have a minimal maverick filesystem that works with arm.. it does not have dpkg.. and i want to install additional debian packages..
[11:44] <persia> Install dpkg :)
[11:44] <kish> only if i know how i can install it..
[11:44]  * ogra wonders how you can have an ubuntu rootfs without dpkg in the first place
[11:44] <persia> Hrm.  That gets tricky.  Do you know that your userspace is entirely compatible with Ubuntu?  If so, which release?
[11:45] <persia> ogra, Careful manual hacking of the rootfs post-construction.
[11:45] <ogra> heh, but very careful with much effort
[11:46] <persia> kish, Do you have ar and tar available?  Alternately, do you have filesystem access to the rootfs from another device.
[11:46] <persia> ogra, Yes: the sort performed by the most annoying class of OSV
[11:46] <kish> yes.. i have tar ball available.. i access the rootfs from OMAP3430 using nfs..
[11:47] <persia> NOTE: the following is disrecommended, dangerous, and incomplete
[11:48] <kish> yeah.. fine..
[11:48] <persia> I'd probably unpack the armel dpkg .deb (make sure you have the Pre-Depends working first), and install the files manually.
[11:48] <persia> The run the preinst and postinst manually.
[11:49] <persia> Note that dpkg may not work as expected when this is complete, as /var/lib/dpkg is likely not properly populated.
[11:49] <persia> Mind you, the above is risky, and not in any way sure to achieve your goal.
[11:50] <persia> In most cases, if you have the ability to replace the rootfs, you'd do better creating a new one from scratch.
[11:51] <kish> i got that rootfs from someone else.. well then I'd probably try to create a new rootfs..
[11:51] <persia> Easiest is probably to use the release image.  If that doesn't work, some people are happy with rootstock.
[12:03] <lilstevie> how the hell do you get an ubuntu, or any debian variant for that manner without dpkg 0.o
[12:06] <premkiran> Hi
[12:06] <premkiran> Did anyone try arecord on ubuntu on OMAP4 blaze board
[12:06] <persia> !ohmy | lilstevie
[12:06] <ubot2> lilstevie: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[12:07] <premkiran> We observe that the arecord on ubuntu is not working for blaze
[12:07] <persia> lilstevie, Consider that someone could create a rootfs, and then delete individual files.
[12:11] <premkiran> NM: we see arecord has a problem with ubuntu on blaze
[12:58] <slnr> hi NM
[13:03] <slnr> NishanthMEnon: we were discussing about the issue of http://pastebin.mozilla.org/1047108
[13:25] <RBT> rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! filesink location=test.yuv
[13:25] <RBT> this pipeline fails
[13:25] <RBT> rob: unable to dump in yuv file
[13:26] <persia> RBT, Is this different than the issue with not supporting untiling buffers identified before?
[13:27] <RBT> persia/rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! v4l2sink
[13:27] <slnr> persia: me and RBT are together
[13:27] <RBT> this pipeline works fine on blaze
[13:28] <persia> I thought ndec said this was expected behaviour.  If it's a bug, then it's worth reporting a bug, but if it's expected, then use gst-ducati
[13:28] <slnr> persia: we installed gst-ducati
[13:29] <slnr> persia: we do not have pointers of how to fix the pipeline with gst-ducati
[13:29] <persia> Doesn't that have a different gstreamer bit than omx_h264dec ?
[13:30] <persia> I'd think you'd want ducatih264dec
[13:30] <persia> But i'm just guessing, really.
[13:30] <persia> (based on http://bloggingthemonkey.blogspot.com/2010/11/announcing-libdce-and-gst-ducati.html )
[13:30] <slnr> persia: did not get
[13:31] <persia> If you want to use a different decoder, you need to change the gstreamer pipeline.  Just installing a different package gives you the capability to use a different decoder, but doesn't actually use it.
[13:32] <slnr> persia: yes we understand
[13:32] <slnr> persia: so you say we can replace the omx_h264dec with ducati plugin and check ??
[13:32] <RBT> persia: we are looking for both playback and capture. for eg gst-launch omx_camera mode=1 exposure=1 awb=1 nsf=1 device=secondary output-buffers=2 name=cam cam.src ! "video/x-raw-yuv-strided, format=(fourcc)NV12, width=864, height=480, framerate=15/1" ! ffmpegcolorspace ! omx_h264enc input-buffers=3 output-buffers=2 bitrate=4000000 profile=1 level=2048 ! qtmux ! filesink location=/home/blaze/test_
[13:32] <RBT> 1.mov
[13:33] <persia> That's what I'd do if I was having that problem, but I'm just guessing.  I have no deep knowledge about the issue.
[13:33] <ndec> RBT: capture? our public ducati firmware does not support capture and encode.
[13:33] <slnr> # looking into capabilities of ducati plugin
[13:33] <persia> RBT, From the backscroll, I have the impression that if you're working on an OMAP4 platform, you want to use the ducati* plugins, rather than the omx_* plugins.  Change your pipeline.
[13:34] <persia> Ah, if no capture, then no capture :)
[14:17] <kish> hi.. i use a minimal maverick filesystem on OMAP3. whenever i execute any command I get an illegal instruction error..
[14:21] <persia> kish, Are you sure you're using an armel filesystem with armel packages?
[14:21] <kish> yes.. the same file system works well in omap4..
[14:22] <persia> Very odd.
[14:32] <vstehle> kish: does your kernel support thumb2 ?
[14:39] <kish> i see "# CONFIG_THUMB2_KERNEL is not set" and CONFIG_AEABI=y" in my .config
[14:40] <vstehle> kish, not sure if 'CONFIG_THUMB2_KERNEL' means "kernel supports thumb2 user space" or "kernel compiled in thumb2 (experimental)"
[14:40] <kish> ok i'll give a try..
[14:40] <lool> vstehle: I don't think there's a tunable to disable Thumb 2; I think this is to build your kenrel as a Thumb 2 binary
[14:41] <vstehle> lool: I think you can disable support for thumb2
[14:42] <vstehle> Lxr says thumb2_kernel means kernel compiled in thumb2. kish, this is not this one
[14:42] <vstehle> http://lxr.linux.no/#linux+v2.6.35/arch/arm/Kconfig#L1194
[14:42] <kish> err.. crashed when i set CONFIG_THUMB2_KERNEL
[14:42] <lool> CONFIG_THUMB2_KERNEL is definitely to have a kernel using thumb itself
[14:42] <apw> ogra, is ubuntu-mobile@lists still valid ?
[14:43]  * apw notes that is where he is sending natty upload notificaions to ...
[14:43] <ogra> apw, nope
[14:43] <lool> vstehle: I don't see the option to disable thumb in arch/arm/Kconfig
[14:43] <apw> do you get those?  i am not getting an error
[14:43] <vstehle> lool, yeah me neither. I should have mistaken with NEON, sorry.
[14:44] <ogra> apw, not sure, they might get /dev/null'ed
[14:44] <apw> ogra, now that has to be the silliest idea ever
[14:44] <ogra> i dont get any mails from that list anymore
[14:45] <ogra> to be honest i have no idea whats IS policy of shutting down a list
[14:51] <sebjan> lool, vstehle, kish: are you looking for CONFIG_ARM_THUMBEE?
[14:52] <vstehle> nope. Thumb2
[14:52] <vstehle> (thumbee is more "java")
[15:14] <dmart> vstehle: did you solve your problem?
[15:15] <vstehle> dmart, you mean kish's problem ? :)
[15:15]  * dmart scrolls back
[15:15] <dmart> vstehle: ummm, yeah
[15:16] <dmart> looks like he's gone anyhow
[15:38] <rsalveti> janimo: how did your x-loader/u-boot update testing go?
[15:38] <rsalveti> janimo: did it work fine? or did it break?
[15:38] <janimo> rsalveti, well it seesm copying works, but not all the time. It may not be the copy itslef but rather the version of the firmware?
[15:39] <janimo> should versions of x-loader and u-boot be independent?
[15:39] <janimo> tried xloader 1.41 and would not start (Xloader hung)
[15:39] <ogra> they are not aligned atm
[15:39] <rsalveti> janimo: but what version did you use?
[15:39] <janimo> but I am testing
[15:39] <rsalveti> not aligned
[15:39] <janimo> defaults from natty and those from an angrstrom page
[15:39] <rsalveti> because if you get it quite frequently, then it'll be good to change the tool to recreate the first partition
[15:40] <janimo> ok not aligned but can they be incompatible? like uboot require a minimum version of xloader?
[15:40] <janimo> rsalveti, indeed, let's see how testing goes
[15:40] <rsalveti> janimo: well, it should be fine if you test the maverick's x-loader/u-boot with natty's one
[15:40] <janimo> ok
[15:41] <rsalveti> janimo: and also, you set the create the wiki page to done, but it's still a work in progress
[15:41] <janimo> well it is created
[15:41] <rsalveti> :-)
[15:41] <janimo> it reflects the current status :)
[15:41] <rsalveti> yeah, not the best word used there
[15:42] <janimo> the rest is bugfixing/polish.
[15:42] <janimo> I just need to figure out which of the many proposed notification solutions is the simplest and most effective
[15:43] <janimo> without having to explicitly differnetiate between gui and headless if at all possible
[15:43] <rsalveti> yeah, true
[16:31] <alf__> rsalveti: (sorry to repeat this, I am not sure if it got through because of the netsplit)
[16:31] <alf__> rsalveti: Any luck with clutter and the shaders?
[16:33] <rsalveti> alf__: http://bazaar.launchpad.net/~rsalveti/clutter/gles/view/head:/debian/patches/defining-correct-shader-precision-gles.patch
[16:33] <rsalveti> then it worked fine
[16:34] <alf__> rsalveti: so the precision is needed in the vertex shader, too... interesting
[16:35] <rsalveti> yup, otherwise it still break
[16:35] <alf__> rsalveti: the question is whose fault this is? Is sgx not following the standard?
[16:35] <rsalveti> yeah, I'd say yes, but still need more debugging
[16:36] <rsalveti> will also try with latest sgx drop as soon I get it working with natty
[16:36] <rsalveti> this version I'm using is not supported anymore
[16:37] <alf__> rsalveti: From the standard: The vertex language has the following predeclared globally scoped default precision statements:
[16:37] <alf__> precision highp float;
[16:38] <alf__> ...
[16:38] <alf__> The fragment language doesn't have that
[16:39] <alf__> The fragment language has no default precision qualifier for floating point types
[16:39] <rsalveti> alf__: well, this is clearly not the case for sgx
[16:39] <rsalveti> at least the patch is not going to break others
[16:39] <rsalveti> but should be fixed inside sgx
[16:40] <rsalveti> alf__: as soon I can test the new pvr driver I'll report that to imagination
[16:41] <alf__> rsalveti: what puzzles me is that glmark2 should fail, too, (because it doesn't declare float precision in vertex shaders)
[16:41] <rsalveti> alf__: probably
[16:41] <rsalveti> did you test that with omap 4?
[16:42] <alf__> rsalveti: but last time I tried it it worked (on the SDP)
[16:42] <rsalveti> hm
[21:00] <lool> persia: I wrote u-boot-linaro-efikamx and an uImage created with mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n Linux from linux-linaro-mx51, and could boot up to a kernel panic looking for rootfs
[21:01] <lool> persia: seems to work fine on efikamx; I see USB EHCI, consoles, MMC... and obviously serial
[22:42] <persia> lool, Thanks for checking that.  I'm filled with new confidence.  After the 2.6.38-rc5 release, I'll identify specific patches to add to improve things.
[22:47] <Lopi> Does anyone have any recommendations for virtual keyboards?
[22:47] <Lopi> I made a custom keyboard layout for matchbox-keyboard and it works decent