• [00:00:06] <RogerMonk|linux> will the same beagle image work?
  • [00:00:17] <koen> I think so
  • [00:00:28] <RogerMonk|linux> *sweet!*
  • [00:00:32] <RogerMonk|linux> I'll start it offf!
  • [00:00:33] <RogerMonk|linux> thanks
  • [00:00:34] <koen> ask sakoman_ :)
  • [00:00:46] <koen> ah wait, davinci evm
  • [00:00:55] <koen> I think it will still work, but don't ask sakoman :)
  • [00:01:53] <koen> (if you build it for davinci, that is, arm926 cores don't like armv7a insns)
  • [00:01:54] <RogerMonk|linux> ... what will happen to tmp/rootfs? - won't that get overwritten?
  • [00:01:59] <koen> RogerMonk|linux: for dsplink: http://rafb.net/p/TVmIBc64.txt
  • [00:03:52] <RogerMonk|linux> thanks - I'll give it a try
  • [00:03:59] <RogerMonk|linux> - what about my rootfs?
  • [00:04:01] <koen> tmp/rootfs will get overwritten everytime you make an image
  • [00:04:14] <RogerMonk|linux> yep, so how do I keep my beagle one? - save it away?
  • [00:04:17] <koen> your rootfs is in deploy/glibc/images/<machine>/
  • [00:04:27] <RogerMonk|linux> ah, not tmp/rootfs?
  • [00:04:31] <koen> no
  • [00:04:48] <koen> that's just a temporary place to store the bits before tarring them up
  • [00:04:54] <koen> (or making a jffs2 file)
  • [00:05:31] <RogerMonk|linux> got-it - all becoming much clearer now.
  • [00:05:44] <RogerMonk|linux> and deploy/glibc/images/beagleboard is what you guys post when u send us a release
  • [00:09:48] <RogerMonk|linux> building for davinci now... wish me luck :)
  • [00:10:04] <RogerMonk|linux> time for bed - catch ya tomorrow - thanks!
  • [00:30:59] * jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
  • [00:36:42] * jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) has joined #beagle
  • [00:53:06] * dante (n=rdante@static-71-248-116-186.bltmmd.east.verizon.net) Quit (Read error: 110 (Connection timed out))
  • [00:53:34] * dante (n=rdante@static-71-248-116-186.bltmmd.east.verizon.net) has joined #beagle
  • [01:02:16] <mru> video overlay is almost working
  • [01:09:23] <mru> scaling is behaving a bit oddly
  • [01:12:12] * khasim (n=a0393720@192.163.20.231) has joined #beagle
  • [01:12:49] * jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) Quit (Remote closed the connection)
  • [02:18:56] * khasim (n=a0393720@192.163.20.231) Quit (Remote closed the connection)
  • [02:45:30] * Olipro (n=Olipro@unaffiliated/olipro) has joined #beagle
  • [03:20:40] * RogerMonk|linux (n=rmonkloc@host86-132-218-155.range86-132.btcentralplus.com) Quit (Read error: 110 (Connection timed out))
  • [03:20:45] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit ("Aloha")
  • [05:33:21] * Olipro (n=Olipro@unaffiliated/olipro) Quit (Read error: 104 (Connection reset by peer))
  • [05:41:12] * Olipro (n=Olipro@unaffiliated/olipro) has joined #beagle
  • [05:58:37] * Olipro (n=Olipro@unaffiliated/olipro) Quit (Read error: 104 (Connection reset by peer))
  • [06:13:12] * Beagle9 (n=Beagle9@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [06:17:16] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [07:23:43] * Olipro (n=Olipro@unaffiliated/olipro) has joined #beagle
  • [08:24:15] <koen> good morning all
  • [08:36:09] <keesj> hi
  • [08:47:52] <koen> mru: with my kernel and your rootfs I also get 100fps
  • [09:09:17] * Olipro_ (n=Olipro@unaffiliated/olipro) has joined #beagle
  • [09:14:19] * Olipro (n=Olipro@unaffiliated/olipro) Quit (Read error: 110 (Connection timed out))
  • [09:32:08] <koen> mru: another data point: booting with init=/bin/busybox sh also gives me 100fps
  • [09:32:21] <koen> time to track down what process bogs it down
  • [09:40:28] <koen> hmmm
  • [09:40:43] <koen> killing everything except init and bash doesn't help either
  • [09:48:03] <mru> morning
  • [09:48:13] <mru> try oprofile again
  • [09:48:48] <mru> opcontrol --image all
  • [09:50:57] <koen> and with a vmlinux ?
  • [09:51:12] <mru> if you suspect the kernel
  • [09:51:29] <mru> otherwise it just adds clutter to the report
  • [10:02:49] * RogerMonk|linux (n=rmonkloc@host86-132-218-155.range86-132.btcentralplus.com) has joined #beagle
  • [10:04:40] <RogerMonk|linux> morning
  • [10:05:07] * likewise (n=chatzill@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [10:05:33] <likewise> hi all
  • [10:05:44] <mru> morning
  • [10:05:59] <RogerMonk|linux> howdi
  • [10:06:24] <RogerMonk|linux> mru - any joy with clocks over night?
  • [10:06:41] <mru> I've got a nice picture now
  • [10:06:47] <RogerMonk|linux> Sweet!
  • [10:06:59] <mru> so I'm playing with yuv overlays
  • [10:07:00] <RogerMonk|linux> into the video window? - no format conversion?
  • [10:07:15] <mru> it's a shame the chip only supports yuv422 format
  • [10:07:27] <mru> practically all codecs produce planar 420
  • [10:07:38] <RogerMonk|linux> yep..
  • [10:07:50] <mru> and converting it takes almost as long as decoding
  • [10:08:07] <RogerMonk|linux> what 420->422?
  • [10:08:42] <mru> the conversion is conceptually simple
  • [10:09:07] <mru> but it's requires moving an entire frame's worth of data
  • [10:10:32] <mru> when it comes to video, anything resembling memcpy is your enemy
  • [10:11:16] <RogerMonk|linux> is there an easy way in ffmpeg to write 422 out instead of 420 when u gen the frame?
  • [10:11:21] <mru> no
  • [10:11:31] <mru> it would still have to do the conversion
  • [10:11:48] <mru> and the planar data is needed as reference for predicted frames
  • [10:12:02] <RogerMonk|linux> right
  • [10:12:24] <mru> I wrote a quick neon routine to do the conversion
  • [10:12:31] <RogerMonk|linux> how does that look?
  • [10:12:44] <RogerMonk|linux> is there much advantage from neon? - isn't it mainly mem bandwidth issue?
  • [10:12:54] <mru> it's memory bound for sure
  • [10:13:01] <mru> but vzip is pretty handy
  • [10:13:14] <RogerMonk|linux> what's that (scuse ignorance?)
  • [10:13:20] <mru> interleave vectors
  • [10:13:30] <RogerMonk|linux> neon instruction
  • [10:13:35] <mru> and vrhadd is nice too
  • [10:15:15] <RogerMonk|linux> in general, have you been able to do anything parallel with cortex and neon instructions, or do they basically run linearly?
  • [10:15:22] <RogerMonk|linux> (but faster)
  • [10:16:06] <mru> no, nothing I've done so far has been of that kind
  • [10:16:20] * Olipro_ (n=Olipro@unaffiliated/olipro) Quit (Read error: 104 (Connection reset by peer))
  • [10:16:34] <mru> especially since transferring data from neon to arm is very costly
  • [10:16:47] <RogerMonk|linux> do you see any way to do it? ie. interleave somehow
  • [10:17:16] <RogerMonk|linux> what's/where's the penalty?
  • [10:17:45] <mru> transferring a 32-bit value from neon to an arm register takes something like 20 cycles
  • [10:18:14] <mru> the arm and neon pipelines are not tightly coupled
  • [10:18:15] <RogerMonk|linux> wow! - I'd thought (foolishly....) that neon shared same register set
  • [10:18:35] <mru> no, neon has it's own set of 16 128-bit registers
  • [10:18:44] <mru> or 32 64-bit registers
  • [10:18:58] <RogerMonk|linux> hmm ok
  • [10:19:19] <mru> and a load/store unit of its own
  • [10:19:50] <mru> it's great when you can load some data, do something with it, and store it back
  • [10:19:53] <suihkulokki> neon shares the registers with VFP, right? is register transfer from vfp to arm as expensive then too?
  • [10:20:04] <mru> vfp on cortex should be avoided
  • [10:20:11] <mru> but yes, it's the same register file
  • [10:20:27] <mru> cortex has a stripped down, non-pipelined vfp unit
  • [10:20:39] <RogerMonk|linux> is there a load/store between register sets, or do you need to go via memory?
  • [10:20:40] <koen> mru: found it!
  • [10:20:54] <koen> mru: I still had a script that enabled alighment fixups....
  • [10:20:56] <RogerMonk|linux> morning koen
  • [10:20:59] <koen> hey RogerMonk|linux
  • [10:21:20] <suihkulokki> yes, it seem handling floats (and especially doubles) is painfull on cortex..
  • [10:21:41] <mru> RogerMonk|linux: transferring an arm register value to neon is easy
  • [10:21:51] <mru> it's the other way that's evil
  • [10:21:57] <RogerMonk|linux> ah ok
  • [10:22:16] <mru> it uses an mrc instruction
  • [10:23:24] <mru> after such an instruction is executed, neon instruction can continue to run
  • [10:23:40] <mru> the first instruction to touch the arm register file stalls until the data arrives
  • [10:23:48] <mru> koen: hmm
  • [10:24:03] <mru> so what was happening?
  • [10:24:21] <mru> there shouldn't be any unaligned accesses
  • [10:24:46] <koen> mru: it seems that telling the kernel to 'fixup' makes it go to software mode
  • [10:25:00] <mru> software mode for what?
  • [10:25:45] <koen> alignment fixups
  • [10:25:45] <mru> there are quite a few legal unaligned neon loads
  • [10:25:53] <mru> but they should never cause a trap
  • [10:26:05] <mru> so the kernel shouldn't have a chance to slow anything down
  • [10:26:06] <koen> http://rafb.net/p/FrmW7V47.txt
  • [10:27:32] <mru> hmm
  • [10:27:43] <RogerMonk|linux> koen - how did you print those stats?
  • [10:31:49] <koen> RogerMonk|linux: with oprofile
  • [10:32:50] * Olipro (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [10:33:00] <koen> that reminds me
  • [10:33:11] <koen> I still need to fix oprofile to install the armv7 files
  • [10:39:48] * KeyserSoze (n=Miles@67.107.206.170.ptr.us.xo.net) Quit (Read error: 110 (Connection timed out))
  • [11:23:41] * DJWillis (i=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) Quit (Read error: 110 (Connection timed out))
  • [11:45:00] * KeyserSoze (n=Miles@67.107.206.170.ptr.us.xo.net) has joined #beagle
  • [12:08:34] <mru> what is the theoretical memory bandwidth on the beagle?
  • [12:13:00] <mru> my yuv converter currently manages about 170MBps
  • [12:24:28] * Mnemonic^ (n=mnemonic@cpe.atm2-0-90150.0x535bc942.virnxx13.customer.tele.dk) has joined #beagle
  • [12:24:42] * Mnemonic^ (n=mnemonic@cpe.atm2-0-90150.0x535bc942.virnxx13.customer.tele.dk) has left #beagle
  • [12:46:44] <koen> isn't that in the trm somewhere?
  • [12:47:23] <mru> wouldn't it depend on the attached memory?
  • [12:47:36] <koen> I guess it would
  • [12:47:44] <koen> iirc it's 166MHz mobile ddr
  • [12:47:58] <mru> that's what the beagle manual says
  • [12:48:05] <mru> but I don't know how it's clocked
  • [12:48:16] <mru> or what burst lengths are used etc
  • [12:48:36] <koen> does uboot or xload have that info?
  • [12:48:51] <mru> something has to configure it
  • [12:48:59] <mru> or maybe not...
  • [12:55:24] <sakoman_> mru: IIRC, xload does this in a routine called something like gpmc_init
  • [12:56:09] <sakoman_> and then u-boot finishes the job for possible second dram bank
  • [12:58:23] <mru> I only asked so I'd know how badly my code performs
  • [12:59:19] <RogerMonk|linux> koen - davinci build fails on glibc_2.6.1....
  • [12:59:45] <koen> RogerMonk|linux: see http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commit;h=da82c9e68cad9f7c3c50d7c39141ecdb925ccc29 :)
  • [12:59:54] <mru> glibc is a beast
  • [13:00:12] <koen> glibc is drepperware
  • [13:00:43] <mru> looking at the code, it's amazing how anyone can make it do anything at all
  • [13:00:59] <koen> it needs >64MB to generate s freaking locale
  • [13:01:00] <mru> does really have to be *that* cryptic?
  • [13:01:07] <koen> 64MB ram, that is
  • [13:01:07] <mru> koen: that can be disabled
  • [13:01:17] <mru> gentoo does that
  • [13:01:37] <koen> I know
  • [13:02:06] <koen> in OE we either you can disable it, let qemu do it or leave for the target machine
  • [13:08:31] <mru> ha, turning on overlay optimisation helps a lot
  • [13:08:48] <mru> yuv conversion up from 60 to 97 fps
  • [13:09:03] <mru> 1280x720
  • [13:09:42] <RogerMonk|linux> koen - I'm being a dumb-ass... how can I rebuild glibc-initial - i'm trying 'bitbake glibc-initial-2.6.1.bb' ?
  • [13:10:24] <koen> 'bitbake glibc-initial'
  • [13:10:55] <RogerMonk|linux> doh..
  • [13:14:49] <RogerMonk|linux> glibc-initial built ok - glibc seems to be failing in do_package http://pastebin.com/m6dd0a792
  • [13:15:18] <sakoman_> koen, mru: I took a first crack at allowing frame buffer resolution to be selected via kernel config options: http://www.sakoman.net/cgi-bin/gitweb.cgi?p=org.openembedded.dev-omap3.git;a=commit;h=eb29efa6fd6e0c9a4a31149072dd0037f40d81ac
  • [13:15:51] <sakoman_> koen: I hi-jacked you 16bpp patch since it doesn't make sense anymore ofter this
  • [13:17:20] <mru> there's a lot of unrelated noise in your defconfig changes
  • [13:18:30] <koen> neat
  • [13:18:33] <sakoman_> mru: that's a result of using make menuconfig
  • [13:18:46] <mru> you don't have to check in the changes
  • [13:19:02] <mru> hold on, menuconfig doesn't alter defconfig
  • [13:19:34] <sakoman_> I think koen had previously hand edited defconfig]
  • [13:19:59] <sakoman_> hence some entries with "=n"
  • [13:20:08] <koen> right
  • [13:20:24] <sakoman_> and every once in a while Kconfig changes re-order things
  • [13:20:51] <sakoman_> so it is good to "freshen up" the defconfig with make menuconfig occassionalu
  • [13:20:55] <mru> it still adds noise to the diff
  • [13:21:09] <mru> you should use git gui and pick just the hunks you want
  • [13:22:20] <sakoman_> for review purposes I agree, but I also think the OE defconfig should be cleaned up occasionally to reflect current defconfig format
  • [13:23:14] <mru> yes, but imho that should be done separately from functional changes
  • [13:23:21] <mru> we're quite strict about those things in ffmpeg
  • [13:23:43] <sakoman_> but other than defconfig noise do you see any issues?
  • [13:24:12] <sakoman_> mru: this is my private test branch!
  • [13:24:22] <mru> yes, I realise that
  • [13:25:33] <koen> I also think sakoman_ should merge oe.dev more often :)
  • [13:25:33] <mru> the patch looks reasonable to me
  • [13:26:16] <sakoman_> koen: I don't merge on holidays or when I am working on a patch
  • [13:26:35] <sakoman_> It makes me very cranky when .dev breaks when I am in the middle of something ;-)
  • [13:26:53] <koen> mru: mplayer trunk with you libavcodec can play big buck bunny in X with some cpu left
  • [13:27:14] <koen> mru: something does seem broken wrt motion compensation
  • [13:27:28] <sakoman_> mru: you are OK with using the reduced blanking timings?
  • [13:27:41] <mru> I'll have to try them to know
  • [13:27:48] <mru> else I'll add some of my own
  • [13:28:00] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [13:28:12] <mru> I'm using CEA861B timings now
  • [13:28:18] <mru> my tv likes those
  • [13:28:29] <sakoman_> They seem to work on my monitors (except for 1280 x 720)
  • [13:28:36] <koen> mru: anything that moves comes out green and blocky
  • [13:28:40] <sakoman_> that only works on half of them
  • [13:28:48] <mru> hmm, I'll have to investigate that
  • [13:29:04] <mru> probably a bug somewhere
  • [13:29:30] <sakoman_> mru: I used the CVTd6r1 spreadsheet to compute the timing values
  • [13:29:41] <koen> sakoman_: using fast-forward in mplayer also kills ASoC
  • [13:30:00] <koen> or rather, i2c
  • [13:30:03] * jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) has joined #beagle
  • [13:30:57] <sakoman_> koen: I know I need to get back to ASOC. You are the one who distracted me with this dvi stuff!
  • [13:31:07] <koen> :)
  • [13:31:19] <koen> I'm not trying to push, just provide datapoints
  • [13:31:41] <koen> that alignment thing got me side tracked for too long
  • [13:31:56] <RogerMonk|linux> koen - is there a verbose or debug mode I can use to try to debug my do_package issue? - any thoughts?
  • [13:32:02] <koen> -D
  • [13:32:03] <sakoman_> and then there is the beagle-image in nand issue :-(
  • [13:32:45] <sakoman_> koen: it's funny, that alignment init was on my todo list to fix
  • [13:33:37] <RogerMonk|linux> hmmm - thanks - no new info though - just says failed and if I run the reported command separately --> segfault.. .nice
  • [13:34:12] <koen> RogerMonk|linux: glibc do_package for davinci?
  • [13:34:19] <RogerMonk|linux> yep
  • [13:34:28] <koen> your fedora kernel is broken
  • [13:34:44] <RogerMonk|linux> any ideas why?
  • [13:34:49] <mru> koen: which bunny version were you playing?
  • [13:34:54] <koen> yes, redhat botched a patch
  • [13:35:05] <koen> mru: 480p mpeg4 (the one with the surround fix)
  • [13:35:07] <koen> RogerMonk|linux: http://pfalcon-oe.blogspot.com/2007/06/running-user-qemu-emulation-on-fedora.html
  • [13:37:07] <RogerMonk|linux> I thought Crofton was using FC9 successfully?
  • [13:37:33] <RogerMonk|linux> (and why didn't the beagle build fail in the same way?)
  • [13:37:50] <koen> try 'echo 0 > /proc/sys/vm/vdso_enabled '
  • [13:38:04] <koen> Crofton|work turns of localegen because fedora is so broken
  • [13:38:53] <keesj> I guess it must be know already but I only get the kernel bootlog if I first do "coninfo"
  • [13:39:01] <koen> FC7 and newer have that proc file to turn the brokenness of
  • [13:39:08] <RogerMonk|linux> so should I turn it off too? how? and any downside?
  • [13:39:14] <koen> 15:37 < koen> try 'echo 0 > /proc/sys/vm/vdso_enabled '
  • [13:39:44] <RogerMonk|linux> yep, already trying it - so that's enough - no OE config changes?
  • [13:39:59] <koen> that should be enough
  • [13:40:59] <RogerMonk|linux> no segfault now... but do_package still fails.... argh! back after lunch...
  • [13:41:04] <keesj> but Angstrom is runnig.
  • [13:41:21] <RogerMonk|linux> sorry.... eventually it does still segfault...
  • [13:42:09] <koen> if it keeps segfaulting you could add ENABLE_BINARY_LOCALE_GENERATION = "0"
  • [13:42:15] <koen> to your local.conf
  • [13:44:27] <Crofton|work> koen, also because I speak the LCD only :)
  • [14:06:40] * likewise (n=chatzill@82-171-51-231.ip.telfort.nl) Quit ("ChatZilla 0.9.83 [Firefox 3.0/2008061015]")
  • [14:14:44] <RogerMonk|linux> Koen, thanks - glibc built now with change to local.conf! - continuing with rest of davinci build...
  • [14:15:09] <RogerMonk|linux> what's the downside of switching this off?
  • [14:15:35] <koen> broken locales
  • [14:15:49] <RogerMonk|linux> which in practice means?
  • [14:16:07] <koen> no translations and stuff like decimal seperators
  • [14:16:25] <koen> people from the US or UK wouldn't notice :)
  • [14:16:40] <RogerMonk|linux> ok, so not serious at the moment for me.
  • [14:17:42] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) has joined #beagle
  • [14:17:44] <RogerMonk|linux> still not clear why beagle build didnt fail the same way..
  • [14:18:23] <RogerMonk|linux> will the change to local.conf cause everything to be rebuilt?
  • [14:19:38] * NishanthM (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Read error: 110 (Connection timed out))
  • [14:21:12] <koen> RogerMonk|linux: the qemu that's in OE doesn't support armv7, so it doesn't get used
  • [14:21:26] <koen> RogerMonk|linux: no, it won't cause everything to get rebuilt :)
  • [14:27:35] <koen> mru: do you think it would be feasible to play the 720p big buck bunny at LRL?
  • [14:29:24] * jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) Quit (Remote closed the connection)
  • [14:30:54] <mru> koen: that's my plan
  • [14:32:22] <koen> iirc there's an x extension that tells x to stay away from a framebuffer region
  • [14:32:28] <koen> xsp or something
  • [14:32:38] <koen> the maemo-mplayer used that
  • [14:35:16] <koen> if the dsp worked we could even display some h264 movie on the s-video port
  • [14:35:40] <koen> simultanious with 720p on another screen
  • [14:35:59] <mru> there could be memory bandwidth issues with that
  • [14:36:47] <koen> yeah, it would just be too nice if things worked that way
  • [14:41:53] <mru> I have the bunny in 720p on my tv
  • [14:42:16] <mru> not sure what framerate it's achieving
  • [14:43:57] <koen> does anyone have specs for the screens we have at LRL?
  • [14:46:46] <mru> who's providing them?
  • [14:47:40] <koen> iirc TI and/or Neuros
  • [14:50:51] * jconnolly_ (n=jconnoll@pool-71-125-246-229.nycmny.east.verizon.net) has joined #beagle
  • [14:53:05] <mru> koen: have you picked a hotel yet?
  • [14:57:55] <mru> I'm getting on average 24 fps playing big buck bunny 720p
  • [14:58:04] <mru> so we still need a little more speed...
  • [15:08:33] <koen> mru: not yet
  • [15:11:44] <sakoman_> Has anyone been successful in running with beagleboard-demo-image in nand?
  • [15:12:01] <sakoman_> just curious if the problem is universal, or just me ;-)
  • [15:12:04] <koen> mru: I'm doubting between the britannia and quality inn
  • [15:53:44] * NishanthMenon (n=Nishanth@cpe-24-27-74-89.tx.res.rr.com) Quit (Remote closed the connection)
  • [16:03:23] <RogerMonk|linux> mru - screens for LRL are 23" DELL panels - DVI input
  • [16:03:41] <RogerMonk|linux> I'll try to get you datasheet
  • [16:11:29] <mru> I have a dell screen at work I can try it on
  • [16:12:49] <koen> I hope the neuros people don't get jealous :)
  • [16:16:21] <mru> koen: I can't see any problems with my video picture
  • [16:16:42] <mru> you said you saw possibly motion-related weirdness
  • [16:17:02] <koen> yes
  • [16:17:29] <mru> that would be using software yuv to rgb conversion, right?
  • [16:17:59] <koen> yes
  • [16:18:33] <koen> an earlier build is ok, but I sadly don't know the mplayer and ffmpeg revision that was built from
  • [16:19:11] <mru> I'll make sure I'm using latest ffmpeg
  • [16:20:11] <koen> I'm using libavcodec from your branch
  • [16:23:09] <mru> I know I had a mistake there for a short while
  • [16:23:19] <mru> maybe you checked it out at the wrong time
  • [16:24:49] <mru> latest ffmpeg + my neon stuff looks fine
  • [16:25:01] <koen> revision a4764a5e2207aa17769b477f717d970d67a9ca73
  • [16:25:58] <mru> I merged some more stuff just now
  • [16:26:05] <mru> but that rev should be fine too
  • [16:26:33] * RogerMonk|linux (n=rmonkloc@host86-132-218-155.range86-132.btcentralplus.com) Quit (Read error: 110 (Connection timed out))
  • [16:28:28] <mru> could be an mplayer bug
  • [16:28:33] <mru> I'm not using mplayer
  • [16:29:33] <koen> you are using ffmpeg to play the videos?
  • [16:30:26] <mru> I'm using a very simple player that I wrote this afternoon
  • [16:30:48] <mru> I don't think anything else supports the omapfb overlay
  • [16:31:11] <mru> since I had to fix the driver first
  • [16:31:21] <koen> git or wtbu kernel?
  • [16:31:24] <mru> git
  • [16:31:49] <koen> is your player online somewhere?
  • [16:32:01] <mru> no
  • [16:35:21] <mru> can you make a screenshot showing the problem?
  • [16:39:03] * BThompson (n=BThompso@cpe-76-185-93-11.tx.res.rr.com) has joined #beagle
  • [16:43:39] * jconnolly__ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) has joined #beagle
  • [16:44:19] <keesj> LRL?
  • [16:52:18] * jconnolly_ (n=jconnoll@pool-71-125-246-229.nycmny.east.verizon.net) Quit (Read error: 110 (Connection timed out))
  • [16:59:22] <koen> keesj: http://lugradio.org
  • [17:03:34] <jkridner> sakoman: just saw http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/revision/info/4a58e20520c4cd28841500b946f0ad09a1619834. thanks! you going to push this upstream as well?
  • [17:04:14] <jkridner> has anyone verified the monitor timings on those settings?
  • [17:05:07] <jkridner> still a half-step to getting EDID to drive the monitor settings, but very handy.
  • [17:06:39] <jkridner> what does it mean to be "reduced blanking"?
  • [17:06:46] <jkridner> interval is short?
  • [17:09:31] <koen> mru: http://scap.linuxtogo.org/files/97ee71b79fef7674452ba6fed0703161.png
  • [17:11:31] <mru> koen: that looks pretty bad
  • [17:11:54] <mru> looks like a colour conversion bug
  • [17:12:44] <koen> in the scene with the river the grass is pretty nice, albeit blocky, and the river (that is flowing) is real bad
  • [17:13:36] <mru> is there a -vo option to dump the raw frames to a file?
  • [17:14:34] * JoeBorn (n=jborn@dsl017-022-247.chi1.dsl.speakeasy.net) Quit (Nick collision from services.)
  • [17:15:00] * ScumBagBob (n=jborn@dsl017-022-247.chi1.dsl.speakeasy.net) has joined #beagle
  • [17:15:23] <mru> I suppose a really broken motion compensation could cause such effects
  • [17:15:46] <mru> but that doesn't normally give colours like that
  • [17:19:35] <mru> but first try with an up to date ffmpeg
  • [17:25:36] <koen> mru: the output from -vo png looks ok, so I guess mplayer messed up
  • [17:25:48] <mru> that's odd
  • [17:25:54] <mru> png also has to do the colour conversion
  • [17:26:17] <mru> what colour format is your X?
  • [17:26:20] <mru> 16 bpp?
  • [17:28:56] <koen> 16bpp indeed
  • [17:30:19] <mru> probably a bug in yuv to rgb565 conversion
  • [17:30:30] <mru> it's probably not used very much
  • [17:30:42] <koen> I guess so :)
  • [17:33:58] <mru> still strange that it only seems to affect areas with motion
  • [17:50:59] <Crofton> Freedom Bag Water!
  • [17:51:28] <mru> ???
  • [17:51:42] <Crofton> http://www.youtube.com/watch?v=1yMRsO_4lOM
  • [17:51:51] <Crofton> Some people still have a sense of humour
  • [17:52:37] * Crofton is originally British
  • [17:52:59] <Crofton> "stealing our language"
  • [18:05:16] <mru> hehe
  • [18:07:39] <mru> so if you're british, what made you leave this lovely rain-soaked paradise?
  • [18:08:05] <mru> hmm.. it's actually stopped raining
  • [18:48:37] <koen> Crofton: how's the dsplink stuff coming along?
  • [19:05:02] <koen> "if you use the continental measurement system: more that a 1000 torques"
  • [19:05:11] <koen> Top Gear is great :)
  • [19:25:35] * jkridner|work1 (n=a0321898@nat/ti/x-5a8719851dbbf072) Quit (Remote closed the connection)
  • [19:28:33] * jkridner_ (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [19:28:54] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (Read error: 104 (Connection reset by peer))
  • [19:39:31] <sakoman_> jkridner: I'll send the patch upstream after we get a little feedback from folks here
  • [19:40:03] <sakoman_> jkridner: reduced blanking is described here: http://www.uruk.org/projects/cvt/
  • [20:07:13] * Olipro (i=Olipro@unaffiliated/olipro) Quit (Read error: 104 (Connection reset by peer))
  • [20:07:49] <Crofton> not coming along
  • [20:08:06] <Crofton> totally tied up getting the house we are renting ready :(
  • [20:09:57] <Crofton> I can see the light at the end of the tunnel though
  • [20:10:36] <Crofton> mru, we left in 1963
  • [20:12:33] <mru> that's a long time ago... I was -17 then
  • [20:13:44] <Crofton> heh
  • [20:13:50] <Crofton> I was 2
  • [20:14:15] <Crofton> oh well, plumbing and base for kitchen floor need to go in
  • [20:17:13] * Olipro (i=Olipro@unaffiliated/olipro) has joined #beagle
  • [20:38:14] <koen> hmmm
  • [20:38:22] * likewise (n=likewise@82-171-51-231.ip.telfort.nl) has joined #beagle
  • [20:38:35] <koen> 2 years ago I was in key west enjoying crepes
  • [20:38:52] * koen looks at the rain outside
  • [20:40:23] <sakoman_> koen: it is sunny and 40C here today
  • [20:40:32] <sakoman_> rain sounds nice ;-)
  • [20:49:56] <Crofton> 23 C 110% humiity here
  • [21:07:09] <sakoman> Crofton: 15% RH here. easy to understand why half the state is burning
  • [21:08:09] <sakoman> good breeze today. from the right direction too. sky is blue again!
  • [21:09:17] <koen> so it doesn't look like a scene from a sci-fi movie anymore?
  • [21:12:06] <sakoman_> no, not today. yesterday it really did, but today feels almost normal
  • [21:12:20] <sakoman_> amazing the difference from day to day
  • [21:14:14] <sakoman_> FEMA set up their base camp a few miles down the road, so we see lots of green busses shuttling firefighters to & from the various fires
  • [21:14:53] <sakoman_> There's a huge water bomber that is here from British Columbia -- about the size of a 747
  • [21:17:18] <sakoman_> http://www.redding.com/news/2008/jul/05/martin-mars/
  • [21:41:18] * travisutk (n=travis@mil.engr.utk.edu) has joined #beagle
  • [21:41:49] * travisutk (n=travis@mil.engr.utk.edu) Quit (Client Quit)
  • [21:49:50] * likewise (n=likewise@82-171-51-231.ip.telfort.nl) Quit ()
  • [22:43:27] <mru> we really need to do something about all the random failures of things
  • [22:43:53] <mru> like on every few boots, the kernel fails to talk to the rtc
  • [22:44:08] <mru> other times usb ethernet (gadget) doesn't come up
  • [23:06:02] * RogerMonk|linux (n=rmonkloc@host81-159-44-181.range81-159.btcentralplus.com) has joined #beagle
  • [23:10:56] <RogerMonk|linux> hi koen
  • [23:21:53] <sakoman_> mru: agreed, git kernel is still *way* to flakey for my taste on beagleboard. On the EVM it is quite stable. One of the many things on my to do list is to investigate why the stability disparity
  • [23:23:16] <mru> there's the serial console dropout too
  • [23:24:10] <sakoman_> But first I need to finish the asoc driver and figure out why beagle demo rootfs in nand doesn't work
  • [23:25:32] <sakoman_> mru: I suspect a config option difference is behind some of the flakiness. Koen has lots more options enabled in the beagle defconfig than I do on the EVM
  • [23:26:28] <mru> perhaps it's worthwhile going over my config and see if there's stuff I don't need there
  • [23:26:50] <sakoman_> If you've got the time I think that would be a great idea!
  • [23:29:59] <sakoman_> mru: are you using OE builds?
  • [23:30:04] <mru> no
  • [23:30:05] <RogerMonk|linux> mru - it would also be worth running your stuff against the TI 0.9.8 kernel
  • [23:30:36] <RogerMonk|linux> mru - do you have an EVM?
  • [23:30:41] <mru> no
  • [23:30:59] <mru> I have the rev b beagle, that's all
  • [23:32:38] <sakoman_> mru: wat do use use to build your rootfs image?
  • [23:32:46] <sakoman_> s/wat/what/
  • [23:32:58] <mru> gentoo
  • [23:33:20] <mru> and some brute force
  • [23:33:50] <mru> like telling it to ignore dependencies
  • [23:34:17] <sakoman_> OE is working well for me, so I'm not going to push my luck by trying something else
  • [23:37:40] <mru> well, I've never used oe before, but I know my way around gentoo
  • [23:44:06] * jkridner|work (n=a0321898@nat/ti/x-59bc368bcf386791) has joined #beagle
  • [23:45:33] * esden`away is now known as esden