<kristianpaul>
wolfspraul: I saw it in Xiangfu blog, also in openwrt xbusrt for qi, support and related information for a hanvon ebook
<kristianpaul>
so i'm curios if were some plans around this technology?
<kristianpaul>
if it was at the same time you founded the color digital dictionary? but then comunity just focus on a general porpuse computer pocket computer instead of a ebook? so thats the end of the history?..
<kristianpaul>
morning btw :-)
<rjeffries>
According to goo.gl 33 people clicked on my note today about Milkymist (across identi.ca, twitter and Buzz)
<wpwrak>
kristianpaul: the past tense of "find" is "found", the past tense of "found" as in "foundation" is "founded" :)
<kristianpaul>
ouch, sorry :/
<rjeffries>
wpwrak indeed, a combo ofIngenic SOC and Linux with Propeller chip as "helper" chip would give VGA, also a LOT of i/o it's cheap too.
<wpwrak>
kristianpaul: with an english as good as yours, those little mistakes are actually quite amusing ;)
<roh>
UGH!
<roh>
made internetz work again.
<wpwrak>
rjeffries: dunno if the prop is worth the trouble. i like the concept, but wouldn't, say, a cpld or a small fpga serve us better ?
<rjeffries>
wpwrak an OK way to get ethernet connectivity will be ATusb working on a cheap linux router
<roh>
what-a-ugly-hack ... use the common wifi from the neighbours till we get our own link (and a wired one to them)
<kristianpaul>
wpwrak: fpga cames in different LUT sizes, so well..  :_)
<rjeffries>
a hood thought experiment is what will stimulate demand for ATusb. that will drive unit vosts lower
<wpwrak>
rjeffries: (atusb) yup. it's another thing with high setup cost but better per unit cost afterwards. less so than UBB, but still
<rjeffries>
wpwrak since Ben++ is a hazy future, Ben+ubb+simple Propeller boardwith putpose of adding i/o to Ben might work
<rjeffries>
I winder if we could have an adequate VGA interface that way?
<wpwrak>
rjeffries: (prop) perhaps. don't know how much the prop can do in parallel. e.g., if one peripheral plus communication with the ben already eats up all the cogs, it's not worth the trouble. if it can indeed do a bunch of things, maybe.
<wpwrak>
rjeffries: is there a decent free C compiler for the prop by now ?
<rjeffries>
wpwrak there is a C compiler ay long last not sure of code quality
<wpwrak>
rjeffries: for vga, consider using a cicuit like the prop uses with ubb. i'm not entirely sure if it could work, but it might
<wpwrak>
rjeffries: (c compiler) is it open source ?
<rjeffries>
wpwrak I will check on that C compiler just forund out about it  recently
<roh>
last time i checked propeller didnt even have a compiler running on something else than some dosbox
<wpwrak>
rjeffries: well, the problem with non-commercial licenses is that they conflict even with loss-making endeavors like ours
<rjeffries>
yeah {ropeller 2 has been stalled. I think it is still being developed by one genius but oddball engineer and a smart layout person
<rjeffries>
not sure that is what that licese means I read it that you can not SELL the LCC software
<wpwrak>
rjeffries: (prop 2) two people ? aw ... is parallax that small or have they basically abandoned the architecture ?
<rjeffries>
nope the propller was as I remember a one mad design. prety amazing in my opinion
<wpwrak>
rjeffries: "not sell" probably means that you can't ship it with a ben in any form
<rjeffries>
s/mad/man but a funny typo
<wpwrak>
rjeffries: similar to anything mp3
<rjeffries>
wpwrak mayeb I;ll do some email sleuthing on lcc
<wpwrak>
rjeffries: (one mad) indeed ;-)
<rjeffries>
i meant to write one-man design effort
<wpwrak>
rjeffries: yeah, but some aspects of the thing carry a whiff of madness ;-) and of course, there's genius as well. they sometimes go hand in hand :)
<wpwrak>
(madness) particularly the bit about the own programming language and making the device a self-contained development platform. argh.
<wpwrak>
that's like building a statue to the knights of NIH (Not Invented Here), resting on a tall tower placed upon a great pyramid (carried by four elephants standing on a tortoise, and so on :)
<rjeffries>
yes agree wpwrak. I do hope Propeller 2 sees the light of day however
<rjeffries>
wpwrak yjis Propeller dev board has a loy og available plu-in modules. fairly cheap.
<dvdk>
anybody around here mind to comment about a hacky openwrt recipie?
<dvdk>
trying to package a recent mplayer
<dvdk>
mplayer requires some directories from the ffmpeg source tree.  the part that is is staging_dir/usr/include doesn't suffice
<dvdk>
now I link part from ffmpeg's build directory directory into mplayer's build directory
<dvdk>
that's ugly.
<dvdk>
is there a way to make such a build recipie work reliably?  i.e. can I write dependencies in a way that ffmpeg build directory is always created before compiling mplayer?
<dvdk>
how can i find out the version number number of the ffmpeg that is build so i know the name of the build dirs?
<kyak>
dvdk: maybe create a little script for that?
<dvdk>
hi kyak
<dvdk>
a script for which part?
<dvdk>
here is the ugly shell script code i put into build/configure:
<dvdk>
mkdir -p $(PKG_BUILD_DIR)/ffmpeg
<dvdk>
for i in $(PKG_BUILD_DIR)/../ffmpeg-0.5.*/libavutil; do \
<kyak>
e.g. when you symlink the ffmpeg dir, first do something like "find $BUILD_DIR -name "ffmpeg*" -depth 1
<dvdk>
ok, that is similar to the for i in *... loop i use that guarantees i use the latest ffmpeg verison found
<kyak>
yeah
<kyak>
i agree it looks ugly
<kyak>
but should work reliably
<dvdk>
but as the build system knows which version it builds (and resolves the libffmpeg dependency i gave), can't it give me that knowledge?
<dvdk>
kyak: only as long as shell sorting also matches version sorting :)
<dvdk>
going from ffmpeg 5.9 to 5.10 will cause trouble :)
<dvdk>
Ah, got it, maybe i can get ffmpeg version from the pkgconfig .pc files installed to the staging dir.
<dvdk>
but then, still, there is no guarantee that the ffmpeg build_dir actually exists.
<dvdk>
it is only re-generated when ffmpeg package becomes outdated and make rebuilds it, no?
<kyak>
the build_dir for ffmpeg should always exist, because mplayer depends on ffmpeg
<kyak>
therefor, ffmpeg always builds before mplayer
<dvdk>
kyak: yeah, but if ffmpeg compilation succeeded, then somebody may cleanup the build dir, and makefile won't regenerate it, since ffmpeg is up to date?
<dvdk>
now build fails with libavutil/sample_fmt.h missing.  well, maybe ffmpeg 0.5.4 is too outdated, and I need to search for a matching mplayer revision...
<kyak>
dvdk: you someone would clean up the build dir via make clean, it would also delete files from staging dir
<kyak>
so it would lead to rebuilding of package
<dvdk>
kyak: rm -rf build_dir :)
<kyak>
if someone had removed the build dir manually, he's on his own
<kyak>
he knows what he does :)
<dvdk>
ok, so then i guess the hacky recepie idea is good :)
<dvdk>
ouch, mplayer r32500 _contains_ a private libavutil directory.
<kyak>
dvdk: do you think it might be a good idea to pacakge our own ffmpeg?
<kyak>
and to link mplayer statically to it?
<dvdk>
kyak: not sure.  mplayer is a very special beast.
<dvdk>
kyak:
<kyak>
name it "ffmpeg-for-mplayer"
<dvdk>
kyak: the cleanest solution would be to roll our own mplayer tarball that *includes* ffmpeg.  everything else is just plain hacky
<dvdk>
after all the mplayer configure script overwrites configure settings of ffmpeg etc.
<dvdk>
so we should treat them as one tarball
<dvdk>
these two pieces of sw are not really factored.  maybe because developers are mostly the same.
<kyak>
is it problematic to build the ffmpeg that mplayer pulls from ffmpeg git?
<dvdk>
kyak: the ffmpeg mplayer pulls is placed under mplayer's build dir, *because* mplayer build process hacks it in various ways.
<kyak>
yeah, so what?
<dvdk>
include files are used that are not even public api includes etc.
<dvdk>
to mplayer ffmpeg  is not a library, it's a part of its source code with deep connections into every part
<dvdk>
what i want to say is
<kyak>
developers somehow intend to build mplayer like that.. could we just follow it?
<dvdk>
that's what i want to say.  building ffmpeg and mplayer separately is a headache
<dvdk>
but there is no proper tarball that includes both.
<dvdk>
so we'd have to make and host one ourselves
<dvdk>
doing a non-versioned git pull from ./configure asks for trouble
<kyak>
could we patch the configure to not ask for anything, and just pull the ffmpeg?
<dvdk>
kyak: we could but i'd advise against it.  this breaks many aspects of openwrt build system
<dvdk>
also without asking for a special git revision, every compile would yield a different result
<kyak>
but we can pin the specific git revision
<dvdk>
we could.  but then we'd pull for every rebuild.
<dvdk>
openwrt's download rules cache everything in ./dl
<wolfspraul>
so there is a lot actually right in 320x240 (60 videos), then another cluster at 640x480 (178 videos), 1280x720 (49 videos), and even full HD I guess 1920x1080 (12 videos)
<dvdk>
well, the best idea would be to transcode for nanonote resolution anyways.
<dvdk>
the scale can scale from any size to (almost) any size.
<wolfspraul>
I am hoping one day we can have a client that can browse, download and display from a repository like Wikimedia Commons
<wolfspraul>
transcoding would probably be very painful, if someone watches a video only once
<wolfspraul>
(Wikimedia Commons is not a serious video repo now - simply too few videos. Just to get the idea across)
<dvdk>
well, i could easily write a script that transcode just everything and puts it on qi-hardware.com :)
<dvdk>
nanonote cpu-power isn't currently strong enough for 640x480, so downscaling on the NN wouldn't be very useful.
<dvdk>
video aborted with OOM after a few minutes.  are we leaking memory?
<dvdk>
trying with -vc theora (i.e. official theora decoder) instead
<dvdk>
wolfspraul: then there is also vodo.net
<wolfspraul>
you mean it's not realistic that a 640x480 theora video is scaled down and displayed at 320x240, in real-time?
<dvdk>
maybe after some tweaking.  currently not.  not without simd optimizations etc.
<dvdk>
scaling is not the problem.  it's mostly for free
<dvdk>
but decoding is costly, and we only have a tiny cache, no L2 cache etc.
<wolfspraul>
nice link about vodo.net - thanks! didn't know about it
<dvdk>
you should see pioneer one :)
<wolfspraul>
unfortunately non-commercial, but nice project nonetheless
<dvdk>
was just going to complain about the license :)
<wolfspraul>
well it's ok. it seems they are trying to create ways to build a distribution and monetization network/channel for the creators. more power to them.
<wolfspraul>
I believe this should be done on 'free first', then 'pay', but it's good that many people try different things in parallel.
<wolfspraul>
nothing better than paying for free content, imo
<wolfspraul>
voluntarily of course, based on the degree of appreciation for the work :-)
<dvdk>
ok, we have a demuxer problem.  the ffmpeg ogg demuxer leaks memory (or just needs lots of it)
<dvdk>
running mplayer -demuxer ogg seems to fixes the leak
<dvdk>
Maybe we should get the Nanonote listed under Theora Hardware at http://wiki.xiph.org/Theora_Hardware (once everything works stably / is part of official firmware)
<DocScrutinizer>
wolfspraul: h-e-n hostmode for N900 earned some 60EUR donations from 2010-11 til now
<wolfspraul>
dvdk: definitely, we should list it
<DocScrutinizer>
60..100¬ total
<wolfspraul>
maybe one day we have Theora encoding in Milkymist too, who knows... I see Elphel 333 in that list :-)
<wolfspraul>
what is h-e-n hostmode?
<dvdk>
wolfspraul: looks like a wiki, so only needs  signing up for an account :)
<wolfspraul>
let's get it into a OpenWrt or Jlime image first though
<dvdk>
maybe wait a week or two, until everything stabalized.
<DocScrutinizer>
hostmode-easy-now, my project to put USB hostmode back into N900
<wolfspraul>
otherwise it's a bit of vaporware/wishful thinking
<dvdk>
wolfspraul: sure.
<dvdk>
wolfspraul: what i coded so far is tested with and packaged for our openwrt image.
<wolfspraul>
DocScrutinizer: well that's not too bad, at least some bits... how did you get that (which payment method)?
<kristianpaul>
DocScrutinizer: your lucky paypal allow you receive donations, sadl not my case :/
<kristianpaul>
(vodo) looks nice, okay i just installed the firefox extention now..
<DocScrutinizer>
kristianpaul: believe me, I feel like it's not been worth the effort - and I actually *hate* paypal
<kristianpaul>
he :-)
<DocScrutinizer>
well, it came handy for paying some weird stuff for N900 I ordered in HK
<DocScrutinizer>
spare speakers for example
<kristianpaul>
yes paying is what all people is allowing to :-)
<kristianpaul>
I got my MM1 that way
<DocScrutinizer>
the N900 tends to fry speakers due to the very good class-D amp
<viric>
Maybe I should try to get mplayer working in the nanonote too...
<kristianpaul>
viric: then and you dvdk and kyak can do a hackatoon ;)
<DocScrutinizer>
0..30kHz +/-0dB ;-D
<kristianpaul>
0? 0_o
<DocScrutinizer>
sure, class-D
<DocScrutinizer>
that's the problem
<DocScrutinizer>
that's why Nokia delayed rollout of N900 - they had to invent xprot speaker protection in PulseAudio
<viric>
kristianpaul: Maybe you mean '-ton', and not '-toon'? :)
<DocScrutinizer>
well, actually INput is decoupled by 100nF/?10kR?
<viric>
Or even '-thon'
<kristianpaul>
viric: sure sure  :-)
<DocScrutinizer>
hackytoon
<DocScrutinizer>
hackyphoon
<DocScrutinizer>
hackartoon
<viric>
hackycoon
<viric>
(~tycoon)
<DocScrutinizer>
:-D
<wolfspraul>
DocScrutinizer: how do you feel about Nokia/Meego/WinMobile and the future of phones at Nokia?
<DocScrutinizer>
dark sad story
<viric>
what is the state of GSM stacks usability in linux?
<viric>
Isn't there any 'arduino gsm module' around? :)
<wolfspraul>
DocScrutinizer: he, come on. That's not the final word :-) The future begins now.
<wolfspraul>
even inside Nokia there will be some signs of life once it's becoming more clear that they hit the self-destruct button
<wolfspraul>
although I wouldn't count on that or wait for that
<DocScrutinizer>
meego dudes are rather agnostic about special system architecture needs for mobile battery-powered devices...
<DocScrutinizer>
Nokia officially put meego on "strictly educational" status. No further plans for a product line based on it
<DocScrutinizer>
maemo been killed in favour of meego long ago
<DocScrutinizer>
elopcalypse
<wolfspraul>
yes ok but what's next...
<DocScrutinizer>
samsung?
<viric>
what's the next to fall?
<wolfspraul>
no what's the next best mobile device/smartphone to run free software on
<wolfspraul>
DocScrutinizer: any particular mode or line in mind at Samsung?
<wolfspraul>
model
<kristianpaul>
yes plese tell!!, my 10 year old phone will die soon, i'll need buy a mobilephone soor or later :/
<DocScrutinizer>
nope, nothing that's matching my taste
<kristianpaul>
:(
<DocScrutinizer>
I got 2 pcs N900, considering to get a 3rd one
<kristianpaul>
hmm, what GSM chips uses that N900?
<DocScrutinizer>
maemo's still alive
<DocScrutinizer>
BB5
<wolfspraul>
kristianpaul: buy the cheapest 20 USD phone and let's continue with NanoNote, Milkymist, etc. if you want to go pro join the osmocom project
<wolfspraul>
:-) (I had to give that feedback, no? :-))
<viric>
wolfspraul: that's what I planned to do :)
<kristianpaul>
yeah, i tought that alredy :-)
<viric>
Can someone with arduino pieces make something close to a gsm phone?
<kristianpaul>
just somethimes, i miss mobile connectivity, may be i just need a gsm-3g modem dongle..
<viric>
kristianpaul: sometimes I miss lack of connectivity
<wolfspraul>
we'll get to the connectivity
<kristianpaul>
;)
<wolfspraul>
at least once we do, there will be something new there
<wolfspraul>
for sure
<kristianpaul>
is at gome
<kristianpaul>
s/gome/home
<kristianpaul>
viric: surely you can, but the point is not just buy something thats works byt it self (gms side), in the other hand better get something you can build/hack on :-)
<kristianpaul>
arduino and his majority shield market is not that way to go i think..
<kristianpaul>
will buy a 20usd phone with lighting :-)
<wolfspraul>
I think the key is to join existing projects, and incrementally improve those.
<wolfspraul>
rather than starting yet another big meta-project that will produce nothing but bloat and distraction after a while.
<DocScrutinizer>
wolfspraul: USB hostmode is pretty much final
<viric>
I've a friend, university teacher, that gives as homework to students to improve wikipedia articles
<DocScrutinizer>
finished*
<viric>
someone on electronics should do something similar :)
<wolfspraul>
actually all the pieces are there, they are just combined in horrible ways (well, most pieces are there, some black spots arguably)
<kristianpaul>
DocScrutinizer: nice link, no usefull datasheets afaiks ;)
<wolfspraul>
viric: yes, perfect!
<DocScrutinizer>
kristianpaul: there are no datasheets for BB5
<wolfspraul>
that's exactly what I mean, indeed
<kristianpaul>
(combined in horrible ways ) oh yes
<viric>
Is GSM here to stay many years still?
<DocScrutinizer>
hmm, yup
<kristianpaul>
world is slow,hardware costs money..
<wolfspraul>
hard to predict
<kristianpaul>
hmm
<wolfspraul>
but that kind of thinking may mislead you - gsm is here today, join osmocom, n900, etc. and do something today
<viric>
If someone made an easyly hackable GSM device, it would be potentially forbidden to be sold to the public, isn't it?
<wolfspraul>
otherwise you think too strategically, always looking for the perfect entry spot, factor in inertia, new development, etc. etc. you will never stop thinking :-)
<wolfspraul>
FUD
<wolfspraul>
that's total nonsense, really
<viric>
ah ok
<viric>
I remember hearing stories like this.
<wolfspraul>
some kids believe in santa claus too, which is not a bad thing necessarily
<wolfspraul>
you bet
<wolfspraul>
of course
<wolfspraul>
the Internet is full of rubbish nowadays, isn't it :-)
<wolfspraul>
amazing to see the comment section on many serious news publications nowadays
<wolfspraul>
any insanity clinic certainly would have no problem looking for patients there
<viric>
wolfspraul: the standards for 'insanity' have changed along time ;)
<wolfspraul>
to keep it real: there is absolutely no worry in my mind that a 100% free phone would not meet regulatory requirements in all important markets
<wolfspraul>
in a licensed spectrum, let alone an unlicensed spectrum
<viric>
ok
<viric>
btw
<viric>
as you know chinese production...
<wolfspraul>
of course it's all work, many markets, many local jurisdictions, many powerful players who may create this or that entry barrier
<wolfspraul>
welcome to the real world
<viric>
I've seen a thread about getting a Loongson3 computer out of china
<viric>
A chinese said: it's available, but not to be sold abroad, due to lack of certifications
<kristianpaul>
have a loongsoon computer
<viric>
and people saying "I want one anyway"
<wolfspraul>
what is your question?
<viric>
wolfspraul: what is the chance that, nowadays, a product meant for the chinese market, meets european certifications, let's say?
<wolfspraul>
if you take a random 'china only' product, and submit it to CE and especially RoHS testing (long story), chances that it will not meet those are 90% at least
<wolfspraul>
_but_ the whole story is much longer
<kristianpaul>
you should ask insted how by pass that regulations and get that item shippend to your home easilly ;)
<wolfspraul>
often it may be only some small blip somewhere in a measurement, or difference in measurement, that will make a device pass CCC test (the Chinese one), but fail the equivalent CE test
<viric>
And a question related... I imagine it's much safer to wait for a product to pass the certifications, than to bypass them. At least, from my ignorance, this is the path I prefer now.
<wolfspraul>
and then the problem in a high-volume production is that any change is risky
<wolfspraul>
so if the product is already made in high-volume, and now someone wants to make 'a few' changes to pass CE, no matter how irrelevant that failure is, who will take the risk?
<wolfspraul>
so unless there is a strong sales partner in the EU, it will not happen
<wolfspraul>
RohS is another story, it is typically not checked, and the way RohS is enforced is such that EU agencies 'co-work' with importers and manufacturers 'towards' RoHS
<viric>
Ok
<wolfspraul>
because in the end it is just impossible to be sure about every last connector, every cable, the print color on the box, etc.
<wolfspraul>
so if the Chinese manufacturer is willing to sign a RohS self-compliance document, good for you
<viric>
the whole free market is optimised to economic benefit, and not to safety... so no wonder.
<wolfspraul>
if not, you have to sign it, and be ready to dig through the materials if something comes up one day
<wolfspraul>
nah, that's too cynical.
<wolfspraul>
Loongson is very political, it's the Chinese (government) answer to Intel.
<viric>
this is as I understood it too
<wolfspraul>
so those are all big players, I have zero insights into the strategies that are going on around Loongson right now.
<wolfspraul>
but you cannot see it so simple as in 'that's all crap and they will never pass the great EU standards'
<wolfspraul>
1) not everything in China is crap
<viric>
well, I have two loongson2f and a NN, so I imagine they passed all the certifications :)
<wolfspraul>
2) the EU standards may by far not be as great as some people think they are, and they may not be enforced as diligently as some people think they should be
<viric>
sure sure.
<viric>
in some products we are using Lin Engineering motors, chinese, and I think they are around the best stepper motors around
<wolfspraul>
for everything I manufacture, I definitely try to meet all CE, FCC, RohS, WEEE requirements
<wolfspraul>
but it's ongoing work, that kind of stuff never stops
<DocScrutinizer>
kristianpaul: there's a 'leaked' schematic of N900, with full detail of BB5, and there's the ISI API specs, and ofono, to learn talk to BB5 chip
<wolfspraul>
also actually those standards are moving targets, they are being edited, tightened, etc.
<viric>
clear.
<DocScrutinizer>
kristianpaul: still insufficient to build own equipment based on BB5 chips, not to mention you probably can't buy any
<viric>
There was a time where some software companies started to give out the source code of their games (ID software, Apogee, ...)
<DocScrutinizer>
wolfspraul: you know about zoom-II witch never came to market in the UMTS enabled variant, due to RoHS issues? :-D
<viric>
No phone company is releasing all about their old phones? :)
<Jay7>
viric: it's very expensieve because of patents law
<DocScrutinizer>
the 3G modules they planned to use was not compliant
<Jay7>
lawyers should be sure that they open no patented tech's
<viric>
Jay7: how so? Patents are public designs, isn't it?
<Jay7>
main problem is cross-licensing
<viric>
I mean, the *already patented tech* should be that more easily publicable
<viric>
Jay7: but I'm not understanding anything under 'cross-licensing problem'
<viric>
dvdk: what is the performance comparision between mplayer with your patches or without?
<Jay7>
viric: company A licensing some technology from company B to make some product
<viric>
Jay7: not-patent-related you mean, rigth?
<Jay7>
then company A can't publish some things that affected by tech from company B w/o permit from B
<viric>
ok
<viric>
unless they agreed to publish that.
<Jay7>
and because of total patent's mess nobody can publish anything
<viric>
that could be a good proof about the lack of public benefit from patents
<viric>
(if it is about patents)
<dvdk>
viric: you have a nanonote: download the package and test yourself :)
<dvdk>
what do you mean with 'patches'? the hw acceleration part?
<viric>
dvdk: yes
<viric>
dvdk: I don't use openwrt in it...
<viric>
dvdk: the same bbb.ogv video could be played, before your patches, in the nanonote?
<dvdk>
viric: that get the source and compile it for whatever you use :)
<dvdk>
viric: yes it could, however software-scaling to fullscreen was too slow.
<viric>
but for a video meant for the nanonote screen size... thinking of no later scaling...
<dvdk>
not so sure about bbb320.ogv (saw my last mail?), here no scaling is required, only yuv->rgb conversion
<viric>
ok
<dvdk>
had problems with 320 width video at 30 fps, that's why the scaler.
<dvdk>
the updated mplayer uses ffmpeg's fftheora for decoding which should be fastre.
<viric>
faster than what?
<dvdk>
viric: faster than using official libtheora
<dvdk>
ffmpeg integrates better with mplayer (less copying data around etc.), also i guess that ffmpeg developers produced faster code.
<viric>
ok
<dvdk>
viric: which os are you using?
<dvdk>
on nanonote
<viric>
dvdk: "nanonixos" (cough)
<dvdk>
hu?  you mean your nn is a paperweight :) ?
<viric>
haha
<viric>
it works, boots, has mplayer, rss reader, browser, network, ... :)
<dvdk>
well, if it has mplayer, it should be trivial to package the accelerated vidix  driver for it.
<viric>
I'll try to.
<dvdk>
tell me if you need any help with that.
<viric>
sure.
<viric>
what about that 'mplayer2' btw?
<dvdk>
so the vidix stuff currently consists of (1) the jz47xx_vid.so library (sourceforge), and a tiny patch to mplayer that makes it load the lib.
<dvdk>
viric: mplayer2 dunno.
<dvdk>
away for a few minutes
<dvdk>
back
<dvdk>
viric: interesting, this nanonixos.  didn't even here of nixos until now.
<viric>
Be welcome in #nixos :)
<dvdk>
viric: maybe once openwrt works :)
<viric>
you will wait for the distribution to work, before switching to another? That's altruism ;)
<dvdk>
viric: stubbornness
<viric>
hehe
<viric>
dvdk: I think only me uses nanonixos
<dvdk>
viric: it looks like you are the inventor of nanonixos :)
<dvdk>
standard autoconf/automake, cross-compiles without problems.  install the jz47xx_vid.so to /usr/lib
<dvdk>
that's all
<dvdk>
command line for use is -vo cvidix -sreenw 320 -screenh 240 -fs (put it into the config file)
<dvdk>
s/screenw/screenw
<dvdk>
s/sreenw/screenw
<dvdk>
jz47xx_vid is a library, no kernel patches required
<viric>
clear
<dvdk>
i'm going to try to get jz47xx_vid into mplayer upstream, once it works stably.  until then i'm quite happy about that thing being a separate package, so i don't have to apply monster-patches whenever i rebuild mplayer
<dvdk>
hey, they finally started to rewrite the mess that is named mplayer.  cool.
<viric>
:)
<viric>
and getting vlc on the nanonote? no chance?
<viric>
dvdk: the jz47xx thing builds just fine by nix
<dvdk>
viric: that.s the power of autoconf/automake :)
<viric>
right
<dvdk>
viric: vlc is a little too bloated? lots of thread use etc. not good for a tiny cpu.
<viric>
ah ok
<viric>
I did not know
<dvdk>
just guessing.
<viric>
:D
<viric>
dvdk: I'll be using mplayer-snapshot-20101227. May it work?
<dvdk>
sure.
<dvdk>
if the patch applies, you should be fine.  same patch worked for 1.0rc2 and for svn head
<viric>
I don't disable any codecs... :)
<dvdk>
viric: btw nix is not cross-compiled as far as i see.  so you compile on NN or using qemu-mips?
<viric>
nanonixos is cross compiled
<viric>
by nix
<viric>
nixpkgs allow cross compilation
<viric>
nix-build -A MPlayer  => builds locally
<viric>
nix-build -A MPlayer.hostDrv => cross builds
<dvdk>
ok, so not a port of standard nixos, but kind of a new flavour
<dvdk>
?
<viric>
nixos is not cross-copmiled.
<dvdk>
understand.
<dvdk>
using functional language for build specification is extremely nice
<dvdk>
.
<viric>
but nixpkgs, that nixos and nanoixos use, work not only cross-compiled, but they work locally compiled also in bsd, darwin, cygwin, ...
<viric>
so you can ask for 'vim' on darwin, cygwin, cross-build  to a nanonote, to a sheevaplug...
<viric>
with a single specification, customisable: nixpkgs.
<viric>
nixos is a GNU/Linux distribution not cross build.
<dvdk>
read about it.  fixes many, many problems that come with openwrt and debian.  (especialy with autoconf doing things it wasn't configured to do, resulting in bad dependency infos etc.)
<viric>
You can use nix+nixpkgs in any GNU/Linux distribution
<viric>
you don't need to switch to start using it
<dvdk>
ok, very interesting.  thanks.  people have been using build server extensions on debian to track dependencies.  Nix is much cleaner.
<dvdk>
yeah, don't worry, i cannot migrate yet, as openwrt is not yet working :)
<dvdk>
don't have enough time on my hands.  still, good to know that makefile and per scripts are not the only options left.
<viric>
But I mean... it should be trivial to install nix, get a copy of nixpkgs, and "nix-env -i MPlayer" for example :)
<viric>
So don't imagine that you need to do a lot of work to start using ig
<viric>
it
<viric>
And it works orthogonal to your linux distribution (all stored in /nix/... paths)
<dvdk>
ok, it's just starting to climb upward on my todo list.
<dvdk>
well, keep me posted how the mplayer thing works.  have to leave for some matters in meatspace.
<viric>
sure
<dvdk>
cu
<wpwrak>
hmm. ingenic specify the 4720 up to 240 MHz
<wpwrak>
if i toggle GPIOs as fast as i can, i get a square wave with a frequency of 6.588 Hz. so that's 13.176 Mchanges/sec
<wpwrak>
316/13.176 = 23.98, so the GPIO update rate seems to be CCLK/24
<wpwrak>
the GPIOs are in the address range 0x10000000-0x10ffffff, so according to 4720pm section 24, they're on APB. APB is supplied by PCLK.
<kyak>
dvdk: trying to follow your instructions in "Nanonote video playback update", have no luck -\
<dvdk>
kyak: where's the problem?
<dvdk>
checking the mail, maybe i gave wrong urls?
<kyak>
dvdk: i start the "mplayer bbb320.ogv -vo cvidix -screenw 320 -screenh 240 -fs -demuxer ogg", and then there is black screen
<wpwrak>
according to CPCCR (PDIV=2), PCLK = X1/3. X1 is not defined anywhere. we do know though that CCLK=X1. however, this still leaves the possibility that "X1" only has local significance, such as "input of the respective divider"
<kyak>
though i hear some noise from speaker
<kyak>
dvdk: the urls all worked fine
<dvdk>
kyak: strange.
<dvdk>
can you record the stdout/stderr using mplayer ... &> log
<wpwrak>
it we assume that X1 is global, that would make PCLK = 105.333 MHz. the GPIO update rate would thus be PCLK/8. seems sluggish.
<wpwrak>
let's see what else we know about PCLK ...
<dvdk>
ok, comparing fftheora and libtheora, difference in performance is not too string.
<kyak>
dvdk: how to get rid of that blinking cursor?
<dvdk>
kyak: there should not be a cursor.  have you still &> logfile?
<dvdk>
it sends an ioctl() to /dev/tty to hide the cursor
<dvdk>
works here
<dvdk>
(from ash, launched from gmenu2x)
<kyak>
ah ok
<kyak>
i launch via ssh
<dvdk>
no, you're right there is a cursor at the bottom .  hmm.
<dvdk>
ahh, same for me, launched from ssh for testing :)
<kyak>
:)
<wpwrak>
let's see what happens if i lower HCLK ...
<kyak>
dvdk: btw, have no problems with alsamixer
<dvdk>
kyak: hmm.
<dvdk>
maybe the newer mplayer is fixed and unmutes at startup?
<kyak>
actually, i don't remember having such problem at all
<dvdk>
kyak: no mplayer does not unmute.
<wpwrak>
system no longer responds. sigh. not unexpected, though.
<dvdk>
maybe problem with my gmenu2x config.  gmenu2x config once crashed on me, resetting screen brightness etc.
<kristianpaul>
wpwrak: playing with UART-SPI bridge with the atmega? :)
<wpwrak>
kristianpaul: naw, video out
<kyak>
dvdk: you are right, there is not cursor when i launch mplayer from tty
<wpwrak>
kristianpaul: we're about 5% too fast for CGA (pixel clock)
<kyak>
dvdk: the videos are pretty much unsrollable -\
<kristianpaul>
vide out? in the atmega??
<kristianpaul>
atmel*
<wpwrak>
kristianpaul: no, ben+ubb
<kristianpaul>
oh !
<kristianpaul>
cool
<kyak>
dvdk: i mean, can't rewind or fast forward
<kristianpaul>
wpwrak: why you mentioned UART then ? i dont get it yet or was not related?
<dvdk>
the ogg demuxer is flakey.
<dvdk>
try to rewind in larger steps (up/down or pgup/pgdown)
<dvdk>
without -demuxer ogg you have better rewinding, but memory is going to run out
<wpwrak>
kristianpaul: i'm trying to figure out how the clocks in the ben are really related. the documentation is not very helpful.
<wpwrak>
kristianpaul: in particular, i'm trying to find out if i could make the gpio update rate a little faster.
<wpwrak>
kristianpaul: not sure yet how i'll deal with the clock difference. one possibility would be to tweak the ben's system clock. another would be to insert delay cycles in the video timing. both approaches have their ups and downs.
<wpwrak>
sigh. doesn't like it if i change PCLK either. neither up nor down.
<wpwrak>
of course, i could change it within my evil loop. that one shuts down most of the rest of the system anyway.
<kristianpaul>
evil loop :D
<viric>
dvdk: trouble building mplayer. grrr
<dvdk>
kyak: you're right seeking is pretty broken.  hmm.
<wpwrak>
kristianpaul: well, it disables the lcd controller and interrupts ... :)
<dvdk>
kyak: worked with earlier mplayer versions i tried, though.
<wpwrak>
2.8 us. good. and i could probably make it even faster. the 34.6 us in a 31.77 us time slot are still there, though. hmm.
<roh>
doesnt get what all that complexity should be for
<roh>
i mean.. vga out? seriously? what a waste of time
<wpwrak>
hmm ... lbu $5,... followed by andi $5,$5,0xff  that's kinda stupid
<wpwrak>
grmbl. but does't get faster if i hand-optimize it.
<wpwrak>
and if i pre-compute the whole word to store, memory bandwidth makes the prefetching too slow
<wpwrak>
sigh. need to interpolate the pixels then.
<viric>
finally I built mplayer...
<viric>
kyak: were you running mplayer properly before? I don't have much luck...
<viric>
it runs super-slow here.
<viric>
30% of CPU decoding an OGG audio track
<viric>
finally.
<wpwrak>
grmbl. my monitors don't like my beautiful vga signal. bastards.
<andy753421>
wow, there's more people here than i expected
<andy753421>
what the difference between usbboot, zbboot, and jzboot?
<viric>
I only use usbboot
<viric>
but I'm a bit outdated on that
<andy753421>
none of them work with my hardware.. so i need to know which one to try to fix :)
<viric>
what is your hardware?
<andy753421>
it's a cheap ebook, the cpu is a jz4755
<viric>
ah...
<andy753421>
i need to take it apart again because i forgot to check what the flash chip was :(
<viric>
I don't think it's generic code.....
<andy753421>
the windows version of usbboot that ingenics provides can boot it and access the flash, but there doesn't seem to be a firmware for the jz475x in the linux port
<andy753421>
port/rewrite/etc
<viric>
larsc knows well some jz47xx chips
<kristianpaul>
andy753421: hanvon ebook?
<andy753421>
kristianpaul: no, it's a crazy generic one with no identifiable markings, i found a link on some bulk-purchase site for something similar though, hold on
<wpwrak>
heh, mystery solved. hsync must keep on running also when there's no line to display.
<kristianpaul>
andy753421: yes i asaw it, but no too much res as i want
<andy753421>
kristianpaul: ah, that's the best resolution i can do, but i'll see if I can get some better light, and i could take some close-ups if you want
<kristianpaul>
close up nea the right down corner around the soc is calling my atention :-)
<andy753421>
i'll see what i can do, i've got to head in to work for a couple hours right now though
<wpwrak>
good. now i get my test pattern on all my three monitors (xenon, samsung, lg). they don't keep sync, though. wish i had an analog monitor :)
<kristianpaul>
still having his trusty compaq MV500 monitor
<wpwrak>
trusty or rusty ? ;-)
<kristianpaul>
well, it run mm1 patches very well, of course it is not white as in 1995 but it looks resonable good :D