[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