<wpwrak>
then i remove one of the DMA register initializations, and abracadabra, it times out
<wpwrak>
nota bene, the DMA controller it still not even being used
<kristianpaul>
sip tengo un bus pirata y el logic analyzer no el que vende seedstudio pero si hay un port para una board spartanr3 de avnet, con ese me funciona
<kristianpaul>
argg
<kristianpaul>
sorry
<mirko>
kyak: ok, patched it and started compiling - will commit if it succeeds
<mirko>
kyak: quite strange - didn't experience it but the error is an obvious result..
<kyak>
dvdk: hi! i don't know why, but -mc=5.0 seems to help the desync problem. I.e. even if desync happens, it get compensated rather quickly
<dvdk>
kyak: strange
<dvdk>
was just going to look up the demuxer sources
<kyak>
dvdk: also, ffmpeg git revision is not working again :) i updated to the latest git version locally
<dvdk>
kyak: so maybe they're doing something strange with their git repo?  whenever somebody commits, the previous head get unusable?
<dvdk>
any ideas?
<dvdk>
is not a git exepert
<kyak>
me neither.. will need to have a close look
<dvdk>
kyak: alternative: branch their repo on github, and use that :)
<kyak>
dvdk: btw, mplayer runs perfectly fine in latest trunk
<dvdk>
kyak: you mean, ignoring the desyncing problem you encountered?
<kyak>
dvdk: or, as you once suggested, include ffmpeg tarball in files/
<dvdk>
yuck
<kyak>
dvdk: no-no, the same desyncing problem, which goes away with -mc
<dvdk>
ok, let's see what the demuxer has to say
<dvdk>
kyak: btw did you encode with any non-standard keyframe-distance?
<kyak>
huh? how can i know?
<dvdk>
kyak: if you gave -K or --keyint to ffmpeg2theora :)
<kyak>
no, i didn't :)
<dvdk>
kyak: have an idea, there is a way to generate 'no change' frames for theora.  if mplayer doesn't know about them, it might get problems
<dvdk>
maybe ask at #theora
<dvdk>
kyak: yeah looks like theore 'skipped frames'.  -mc 5 allows mplayer to do aggressive sync correction, so it can compensate for the missing frames.
<kyak>
that's what i thought :)
<dvdk>
found it?  'As per the Theora specification, an empty (0-byte) packet is treated as a data packet (a delta frame with no coded blocks). '
<kyak>
so, mplayer is not working according to the specification?
<dvdk>
kyak: guess it drops empty packets, so they never reach the decoder, so mplay encounters one or more missing frames, and can only resync if -mc allows it to skip enough
<dvdk>
kyak: checking for how to patch
<kyak>
dvdk: the problem is "git clone --depth 1"
<kyak>
it only grabs trees for two latest commits
<kyak>
therefore, our FFMPEG_REV is not valdi anymore :)
<kyak>
dvdk: where will input.conf reside then? in /etc ?
<xMff>
better use /etc/mplayer
<dvdk>
kyak: let's use the default config dir=/etc/mplayer/
<dvdk>
so everything in there, including mplayer.config
<xMff>
then various packages could stuff additional config snmippets in there
<dvdk>
s//mplayer.conf
<kyak>
Jay7: openwrt is using malta board for running mips in qemu
<kyak>
dvdk: that sound right
<dvdk>
ok, just trying to build a patched mplayer with fixed ogg demuxer.  somehow applying all our patches fails the pc build :/
<Jay7>
it would be great to have nanonote support in qemu :)
<dvdk>
maybe with --disable-vidix
<kyak>
regarding input.conf, i'm wondering why volume up/down keys don't work in mplayer anymore
<kyak>
i.e. they work in the image i build on my pc
<kyak>
but don't seem to work in release image
<kyak>
need to have a closer look
<kyak>
Jay7: there is qemu-jz project, but don't expect it to work with Ben right away :)
<dvdk>
kyak: because they changed the keycodes of the volume keys from F11/F12 (?) to proper multimedia keycodes volup/voldown?
<kyak>
dvdk: that's another thing, which also breaks these keys, but (it is easily fixed in console keymap) it was only introduced in some later kernels
<kyak>
the release image should not have it
<dvdk>
kyak: sure the input.conf is in the right directory for your mplayer install?
<kyak>
yep, i tried it but adding some other binds
<kyak>
yep, i tested it by adding some other binds
<kyak>
usually, mplayer would say "unknown bind" when some key is pressed
<kyak>
but here in release image it doesn't complain
<kyak>
when i run mplayer in ssh, it reacts for F11/F12 keys.. for some reason volup/voldown are not recognized as F11/F12 by mplayer
<wpwrak>
whitequark: you found one system consisting of several elements that doesn't work. you don't know for sure which of them is misbehaving, you don't know if any of them suffer manufacturing defects, you don't know if any of them suffer design flaws specific to that one product, etc.
<wpwrak>
whitequark: if you had tried a few different headsets, and if they all exhibit the same problem, also with a different dongle on the host, and if you still get the same problems, perhaps also with a different host (cell phone, different OS, etc.), then you could claim that all BT headsets are evil
<wpwrak>
kristoffer: so .. going to make a few vga adapters ? :)
<dvdk>
ok, looks like emtpy video packets are properly enqueued, but for some reason never reach the theora decoder...
<kyak>
dvdk: i will give it a try later.. have to go now
<mth>
do the NanoNote distributions store the kernel in physical NAND blocks or on an UBI volume?
<larsc>
physical
<mth>
is there any kind of mechanism to deal with bad blocks?
<larsc>
except for skipping it not really
<viric>
I don't think so. But you could make uboot (also on nand physical) to find the kernel in another place, if you had bad blocks where the kernel sits
<mth>
so uboot has a list of blocks that hold the kernel?
<viric>
it has the start address where to find it at least
<whitequark>
wpwrak: ah yes, I understand now, thanks
<whitequark>
wpwrak: the interesting thing is, on Windows it recovers much faster (in ~second interval), but still suffers from same issue
<Ayla>
I heard there are attempts at using kexecboot for the nanonote?
<mth>
we are looking for something to replace uboot
<mth>
and a minimal boot loader to load a kexecboot kernel could probably be identical for Dingoo and NanoNote
<mth>
I'm going to get some groceries, back in a bit
<wpwrak>
viric: ah, another wlan module ... yes, looks nice. but ... do you have documentation on the actual protocol ? (i.e., how do i send a packet, how do i pick a channel, who decides which access point to and and how)
<wpwrak>
viric: bom cost isn't too bad of this one. i guess it would be somethink like USD 20-25 for ~1000 units. of course, atben would be about USD 3.7 at such quantities. for an estimate of end-customer pricing, multiply with 3. so that module would increase the price of a ben by ~usd 75, while ieee 802.15.4 would add ~usd 12.
<wpwrak>
viric: besides, there's an easy way to show the benefits of such a module: get one, make an 8:10 card adapter (if has sdio, but doesn't say if you need additional signals. you'll find out ...), find/write a kernel driver, and see how it works :)
<kristianpaul>
"That's our vision of Free. It's not communism. It's not capitalism as we know it. It's definitely not monopolies. It is Free Culture, and Free Enterprise."
<Fusin>
question: why did someone put the gmenu#2 inside init?
<Fusin>
wouldn't be a simple-init script be better for nanonote
<Fusin>
si milar as old slackware did before?
<Fusin>
reason for question: i would like to 'automount' my data partition, but due to this init behavior, I don't know where to insert the aditional script
<Fusin>
s/init/initrc
<mth>
it has to respawn though
<Fusin>
yep, tragedy ;)
<Fusin>
why not first config the device and then load gmenu or a shell?