<vladkorotnev> hello everyone :P
<vladkorotnev> I got an old Russian game ">;5 'C45A" (transliteration: Pole Chudes) to run on my Ben NanoNote :D
<xiangfu> vladkorotnev, do you fix your gcc problem?
<vladkorotnev> xiangfu: yes, updated to 2011-05-24 image
<xiangfu> :)
<xiangfu> vladkorotnev, please test and give feedback. I am try to make dvdk happy :)
<vladkorotnev> is it supposed to turn off the Ben screen after some inactivity?
<xiangfu> not under gmenu2x. others should works fine.
<vladkorotnev> I know :P
<vladkorotnev> bye everyone
<kyak> guess there was too much talking yesterday and dvdk didn't notice my remark abotu plplot -\
<kyak> xiangfu: how do you think we mark it BROKEN for now?
<xiangfu> yes. ok for me, (under 'trunk' branch)
<kyak> ok.. cause it a pity for me to know for sure that build http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.trunk-full_system-05252011-0754/ will 100% fail
<kyak> and it will fail soon, judging on BUILD_LOG size :)
<xiangfu> run sed '/plplot/s/=y/=m' now ... :)
<xiangfu> kyak, I just mark all plplot to '=m'
<kyak> heh, not sure if it would help now
<kyak> the make has probably decided what to build and in what order
<kyak> already
<kyak> do you think it re-reads .config every time it proceeds to building of next package?
<qi-bot> [commit] kyak: plplot: mark as BROKEN for it doesn't build in trunk http://qi-hw.com/p/openwrt-packages/5fdb51a
<xiangfu> (re-reads .config) not sure. let's see
<xiangfu> kyak, ^
<xiangfu> modify the .config before the package build works fine.
<xiangfu> kyak, only the URL is wrong. I will fix it.
<whitequark> several months ago I've asked some stupid questions about the proper way of writing IPU drivers, and someone clever, whose nick I cannot remember now, answered here
<whitequark> if that was you, then reply please :)
<wolfspraul> maybe mth? look here http://en.qi-hardware.com/irclogs/search?q=ipu
<wolfspraul> march 30...
<wolfspraul> or roh
<kyak> xiangfu: heh, nice :)
<kyak> xiangfu: do you have an overview about how many packages (=m) have failed?
<whitequark> wolfspraul: thanks a lot
<whitequark> roh: hi! can you reply to some more stupid questions about IPU?
<kyak> xiangfu: i counted 32 based on BUILD_LOG :) not so many, but some packages are from openwrt-packages git, need to have a look
<dvdk> kyak: you wrote plplot fails to build?
<dvdk> do you have a build log handy?
<dvdk> kyak: you wrote that you marked it as @broken?  it's not marked in the last checkout
<kyak> it's marked broken in trunk
<dvdk> ok, but does build fail in master or in trunk or in both?
<kyak> it fails in trunk
<dvdk> ah, ok, so no problem for current firmware?
<kyak> no, it fails in trunk only
<dvdk> that's good, then there is no need to hurry :)
<dvdk> didn't ge t much sleep recently
<kyak> you should definitely sleep well before having a look at that :)
<dvdk> just reading the build log.  but don't even find a "real" error message other than "package/feeds/qipackages/plplot failed to build."
<dvdk> was that a parallel build?
<dvdk> uh?
<dvdk> "Entering directory '...plplot" ... error ... "leaving directory '..plplot'".  it doesn't even try to run th emakefile?
<kyak> it doesn't build driversd
<kyak> and then fails during install stage
<kyak> that's al i know
<dvdk> ok, my mistake, somehow i accidentally modified the build_log
<dvdk> kyak: i think i have found the problem (just looking at the build log)
<dvdk> it says 'WARNING: libltdl library not found. Setting ENABLE_DYNDRIVERS OFF.'
<dvdk> so that's why there are no .so drivers generated, and installation fails
<dvdk> strange libltdl is listed under build_depends
<dvdk> the line before that it says ' Looking for dlopen in dl - not found'
<dvdk> maybe libltdl/libdl are note the same in trunk?
<kyak> hm
<kyak> btw.. is it possible to link all these dyndrivers statically?
<kyak> i think it's linked already in one libplplot.so ?
<kyak> perhaps it would be easier than figuring our why configure can't find libltdl
<dvdk> kyak: no i don't want that the way it is now, we can install stuff like the qt output separately.
<kyak> ah, right..
<dvdk> also we only load those drivers which are really used
<dvdk> if we always pulled in qt, we'd map 16MB of .so code
<dvdk> (i guess)
<kyak> ok
<kyak> would be intersting to have a look at config.log
<dvdk> i can run a few more tests.  currently plplot doesn't even compile in master branch for me (dependency problem? don't know)
<dvdk> yes that'd be nice
<kyak> and there is no config.log.. was it the message from cmake?
<kyak> dvdk: btw, perhaps it also makes sense to rewrite the Makefile, cause it was written in days when there was no cmake.mk
<kyak> i don't know if this would help
<dvdk> kyak: current cmake.mk won't help, doesn't support some tricks we're doing. would have to recode that.  
<dvdk> s/recode/add
<dvdk> btw there's the log:
<dvdk> CMakeFiles/CMakeError.log
<dvdk> "libdl.c:(.text._dl_parse_relocation_information+0x1dc): undefined reference to `TLS_DTPREL_VALUE'"
<dvdk> that's the problem.  new uclibc?  no TLS support?
<kyak> new uclibc - for sure. and don't know what the hell TLS is
<kyak> but it looks like the problem is on libdl side anywau..
<dvdk> "thread local storage" (maybe?)
<dvdk> not necessarily, maybe we need to link another lib when using libdl?
<dvdk> but libdl is used everywhere.  if this is broken, you'd have many more build problems
<kyak> maybe it's used, but "TLS" fucntions are not used
<dvdk> no, the problem comes from libdl: it might be that libdl now uses libpthread and we'll have to tell plplot to link that, too during detection
<dvdk> doing my next try, building plplot at least on master (enabled fortran support, maybe that's needed?
<dvdk> )
<wpwrak> DocScrutinizer: (EL PCB tester) hmm, how exactly would that work ? and where do you get such a display ?
<DocScrutinizer> wpwrak: the (usually 400Hz though you can use higher freq) AC causes some flourescent substance to shine up by exciting it via capacitive AC field. I dunno where to get those "displays" maybe revamp backlights as used in jets and tanks, or sth
<wpwrak> phew. now there's a piece that's hard to source :)
<DocScrutinizer> I'm sure 3M or sb is selling this stuff by the meter nowadays
<DocScrutinizer> maybe you even can get paint to apply to a glas covered with the gnd electrode SnO2
<DocScrutinizer> or was it ZnO2? the transparent stuff used in LCD
<DocScrutinizer> hard to source - maybe. Hard to build - don't think so
<DocScrutinizer> if you got no better ideas and materials, then cover the whole PCB with a thin film of water with duh lakmus or phenolphtalein, and place a semi transparent conducting thing on top, then do electrolysis by feeding on pad under test with like 5V and see where other pads start "boiling"
<DocScrutinizer> wpwrak: got the basic idea?
<DocScrutinizer> it's not a QA tester but a mere RE tool
<DocScrutinizer> for complex multilayer PCB to analyze the connections
<DocScrutinizer> once you got the BOM, component placement, and this connection list, it's quite easy to feed this to $kicad and get a proper schematics
<DocScrutinizer> soory for this being somewhat anti-topic here ;-D
<wpwrak> DocScrutinizer: hmm. or maybe place the PCB in a vacuum, heat it, inject a high voltage, and watch electrons fly off it, CRT style :)
<wpwrak> DocScrutinizer: i wonder how they actually do the electrical testing of PCBs in industry. bed of nails seems ... messy
<DocScrutinizer> wpwrak: already thought about it, use front 'half' of a plasma screen
<DocScrutinizer> wpwrak: they know their PCB, so have to pin-contact only very few known pads and probe for connect/isolation on a few pairs
<DocScrutinizer> can be done with one pair of CNC probes
<wpwrak> okay, that's for large volumes, where you make a custom tester. but for smaller/prototype volumes ?
<wpwrak> ah, cnc probes. that would be slow then. but probably okay for small volumes
<wpwrak> been trying to figure out a way to do such things with my mill. testing pcbs is so boring ;-)
<DocScrutinizer> anyway doing this N^2 times for a unknown PCB with N (>1000) pads is a nogo
<DocScrutinizer> having a way to sense all pads concurrently (like with my EL tester) will reduce the effort from N^2 to N
<wpwrak> another way: heat the pad and look at the board with an IR camera
<DocScrutinizer> there are possible optimisations for the N^2 scheme, by using combs with a number of 5mm brushes, then pad pintesting only the 2*5mm^2 rectangles where you got a signal
<DocScrutinizer> (heat) wont't fly
<wpwrak> (heat) would be worth a try ... if i had one of these expensive ir cameras :)
<DocScrutinizer> you can't follow a trace >10mm in layer 4/8 this way
<wpwrak> you should be able to see where it comes out again
<DocScrutinizer> esp the fine ones used today, which are like 0.05mil
<DocScrutinizer> nah
<wpwrak> Cu should still conduct the heat a lot better than the FR4
<wolfspraul> DocScrutinizer: why is this anti-anything? that's great stuff
<DocScrutinizer> if it doesn't come out <10mm from your heated pad, you get nothing useful
<wolfspraul> thanks a lot for sharing
<DocScrutinizer> wolfspraul: it's about RE of closed hw :-)
<qi-bot> [commit] kyak: gcc-mips: restore cache-amnesia patch to fix build on x64 http://qi-hw.com/p/openwrt-packages/681b260
<qi-bot> [commit] kyak: centerim5: fix git url; checkout mob branch http://qi-hw.com/p/openwrt-packages/f741694
<wolfspraul> let's call it analysis first
<wolfspraul> and analysis can be used for many different applications
<DocScrutinizer> indeed
<wolfspraul> I'm serious. not trying to 'hide' reverse engineering
<wolfspraul> reverse engineering is an awesome technique in and of itself
<DocScrutinizer> and the project itself can be attributed open hw anyway
<wolfspraul> efficient analysis ideas and tools can come in handy in many situations
<wolfspraul> so - great stuff! :-)
<DocScrutinizer> this method, while not fit for decent QA of PCB, could come in handy for a quick and dirty good/bad test
<wolfspraul> Adam is trying to explain to me for ages how important some particular pcb tests are, but I haven't found the time and concentration yet to mentally absorb it :-)
<DocScrutinizer> as it detects one of the most annoying failure patterns of PCB: shorts
<DocScrutinizer> I think when droned in clear water (with a bit of ions aka salt), and then applied some 10V to one pad and looking with a good camera for bubbles building up on other pads could actually work great
<DocScrutinizer> I hope this chan is logged ;-D
<DocScrutinizer> with proper date stamps
<DocScrutinizer> you should probably make sure your DUT PCB has the hydrogen side of current flow, not the oxigen one ;-D
<wpwrak> DocScrutinizer: try it and send pictures ?
<DocScrutinizer> might consider it, yeah. Alas I have no good camera
<DocScrutinizer> esp for the bga pads that are microscopic
<DocScrutinizer> you'd need a really really good camera for that
<DocScrutinizer> plus professional lighting, stand etc
<DocScrutinizer> sounds like sth I could do for a master thesis :-D
<wolfspraul> DocScrutinizer: yes the channel is logged and the logs were even beautified recently...
<DocScrutinizer> :-D
<DocScrutinizer> just for eventual lawsuits
<DocScrutinizer> nah, I bet this is like all my inventions: somebody did it 6 weeks ago, or will do in two weeks with no apparent link to this conversation
<DocScrutinizer> and I'm not really in the situation for registering patents
<wpwrak> DocScrutinizer: so, do it, take pictures, post it on slashdot. then it will be very hard for someone else to claim prior art later :)
<DocScrutinizer> wpwrak: (heat) on vias you lose
<DocScrutinizer> I bet a beer it's not worth trying
<DocScrutinizer> what you *can* get by checking heat is the actual routing of a burried trace, when you send current thru it
<wpwrak> (heat) dunno. they should still conduct the heat way better than the FR4. if you "inject", say, 100 K, even remote branches shuold get a delta of a few K (delta between heat conducted through direct trace vs. heat conducted through other traces or board material)
<DocScrutinizer> but that'S usually not that much interesting (though I might recycle this isea for a special problem where I need to drill 2 holes into a PCBA)
<wpwrak> yeah, current always works :) O(n^2), though.
<wpwrak> are you trying to reverse-engineer something specific ?
<DocScrutinizer> (heat conducting) the heat conducted to a far away pad directly linked by a trace is way less than that conducted to a parallel trace in a different layer, even when that other trace is thermally "isolated" by some plastic+glass PCB base material
<DocScrutinizer> wpwrak: nothing special. Just looking at this N900 bare board and pondering about the few testpoints not mentioned in the 'leaked' schematics
<DocScrutinizer> rhen recalling how I started my chitchat with OM, by ranting "gimme schematics, or I'll do <see above>" ;-D
<wpwrak> ;-)
<wolfspraul> you can use sandpaper to go through the layers and then scan them
<DocScrutinizer> indeed, but that's a lousy method, and frequently introduces lots of errors on vias
<DocScrutinizer> and usually will need >5 PCB to ruin that way
<DocScrutinizer> also takes "ages"
<wolfspraul> I haven't done it myself, but definitely you can do it with one pcb
<DocScrutinizer> and all your hair
<wolfspraul> steve|m did it a little while back with a board
<wolfspraul> "I used corning 120, and 400 for polishing it before scanning"
<wolfspraul> "I used 120 really most of the time, and from one layer to another I would say something like 25 minutes, excluding the scanning"
<wolfspraul> "400 is only used like 30-50 seconds :)"
<DocScrutinizer> duh, nice job
<wolfspraul> he needed maybe 1-2 boards to become skilled at this, but I think now he feels quite confident with it, and would only need 1 pcb to go through
<DocScrutinizer> didn't think it could be done that cleanly
<wolfspraul> here in China I can give boards to any pcb maker and they will have a kid sandpaper through it and return the scanned jpegs to me
<roh> re
<DocScrutinizer> lo roh
<wolfspraul> DocScrutinizer: those pics are from China, I don't have a url for the boards steve|m sanded, but it also looked quite clean.
<wolfspraul> it is slow and tedious, no doubt
<wolfspraul> many hours with the sandpaper
<DocScrutinizer> and won't show micro-short defects etc
<wolfspraul> and you need a few iterations before you are good at it
<wolfspraul> but other than that it's a simple and effective technique to picture the layers
<DocScrutinizer> indeed
<qi-bot> [commit] kyak: ghostscript: update to 9.02, fix build http://qi-hw.com/p/openwrt-packages/601c607
<DocScrutinizer> I knew of this, but didn't think it's that easy
<DocScrutinizer> anyway it's not exactly for any nondestructive testing, obviously ;-D
<wolfspraul> indeed
<wolfspraul> ;-)
<wolfspraul> for the pics of that smartphone (G2), I paid about 100 USD
<wolfspraul> I give them 2 boards, 100 USD, they send me the jpegs 2 days later
<wolfspraul> even more like 90 USD I think
<DocScrutinizer> now you only need an autistic nerd to convert these pics to a connection-table
<wolfspraul> and I didn't bargain much
<wolfspraul> the kid that is doing the sanding maybe gets 2 USD / hour...
<wpwrak> USD ~500/month ? wow !
<qi-bot> [commit] Xiangfu Liu: dega: using nanonote version source code http://qi-hw.com/p/openwrt-packages/6f32e10
<xiangfu> wolfspraul, ^ see the line_three of this diff :D
<qi-bot> [commit] kyak: ghostscript: really update to 9.02 http://qi-hw.com/p/openwrt-packages/11ff553
<wolfspraul> wpwrak: is it 'wow' because so low or so high?
<wpwrak> so high ! isn't that what fully grown factory workers make ?
<wolfspraul> yes but they just take one of their workers
<wolfspraul> "today, you have to sandpaper this pcb"
<wolfspraul> :-)
<wpwrak> great way to escape the daily boredom of the factory line ;-)
<roh> i wonder how great quality and ingenuity of chinese products could be if they had such good teachers as some of us had here in germany
<roh> teachers of professions.. like if you end up in siemens 'lehrwerkstatt' for some time
<roh> not neccessarily a nice experience, but usually one which makes your handywork improve a lot
<dvdk> why does package plplot cause openwrt to compile octave, too?  didn't even select sub-package plplot-octave.   or aren't sub-package dependcies not tracked independently?
<dvdk> oops, compile error (branch master
<dvdk> package dropbear)
<dvdk> cp: cannot create directory `/home/pub/spock/src/qi/openwrt-xburst/staging_dir/target-mipsel_uClibc-0.9.30.1/root-xburst/./etc/init.d': File exists
<dvdk> make[3]: *** [/home/pub/spock/src/qi/openwrt-xburst/staging_dir/target-mipsel_uClibc-0.9.30.1/root-xburst/stamp/.dropbear_installed] Error 1
<kristianpaul> wonder what you can buy with 500usd in china
<whitequark> does anyone have docs on Ingenc SIMD instruction set?
<kristianpaul> nope :(
<kristianpaul> but
<kristianpaul> dingux wiki have some data about it
<kristianpaul> i heard also mplayer source code from ingenic have it
<kristianpaul> have imoplemented SIMD as asm,
<whitequark> kristianpaul: the mplayer code is a huge load of crazy shit
<whitequark> you'll need to be an ingenic developer to understand even a small bit of it
<whitequark> the dingux wiki has a really great manual
<whitequark> thanks
<kristianpaul> yeah but not said i dint point you to mplayer
<whitequark> kristianpaul: well, I knew about mplayer and already checked it as a possible source
<whitequark> and it's an awful source of information for a complex thing like SIMD ISA
<kristianpaul> btw can you tell us what are you planning to do with SIMD and the nanonote?
<zear> hey
<kristianpaul> hai
<zear> i left you guys just for a moment and you've done a wireless adapter already? :D
<kristianpaul> pcb so far
<zear> well, as long as it works, i'm gonna order two :D
<kristianpaul> SMT is a WIP but not updates from tuxbrain tha i'm aware off
<kristianpaul> yeah it does zear
<kristianpaul> did you saw wpwrak maill about the tunnel he made to do ssh and ping between nanonotes?
<zear> i think i've seen the vid
<kristianpaul> ya, that famous video indeed ;-)
<zear> btw, did owrt got any better in the terms of the libs and toolchain?
<zear> so i can port some games without a bigger hassle?
<kristianpaul> well. i guess you should consult about owrt libraries avaliabillity
<kristianpaul> about toolchain i cant talk too much about it, as the only cross compile i had done for the nanonote was using jlime :p
<kristianpaul> so wait xiangfu or ask kyak  i hink
<kristianpaul> think*
<zear> yeah, same, with the exception i also used the dingoo toolchain with statically linked binaries :D
<kristianpaul> hey, i about to point you that (statically linked games)
<kristianpaul> i cant see better use for something static, well including kernel may be, and btw does nanonote kernel from owrt suppport dynamic module loading?
<zear> kristianpaul, you could like the binary dynamically and keep your own libs in the local directory
<zear> and change the priority of libs over the system ones
<kristianpaul> oh
<zear> export LD_LIBRARY_PATH or something
<kristianpaul> ah, true :-) i forgot is all about those env variables..
<kristianpaul> so, what games are you wishing to port zear ? :o
<zear> kristianpaul, i already did some ports very early in the nn history
<zear> yet before the first batch
<zear> though it was all statically linked with the dingoo libs
<zear> i did spout, prboom, eduke32
<zear> also cave story, which i never released
<zear> brb
<kristianpaul> ah yes i remenber prboom
<kristianpaul> and gmenu2x wich not a game but very important
<kristianpaul> and that make me remenber somebody was asking for dmenu the other day
<Jay7> one day someone was asked me about making standalone fb menu from kexecboot :)
<kristianpaul> Jay7: yes :-D
<wpwrak> Jay7: makes perfect sense. ideally, kexecboot should just be a bundle of general components. the fewer kexecboot-specific parts you need, the better.
<Jay7> btw, may be good idea to do this..
<Jay7> fb lib + menu lib + xpm lib + ... :)
<kristianpaul> yay, the ENC28J60 just get to my mother work :-)
<kristianpaul> i'll get some fun with linux soon it seems
<kristianpaul> bitbang or spi?
<zear> kristianpaul, i wouldn't bother playing with dmenu
<zear> it's fully config file based, means if you want to add a new item to the menu, you have to edit the config file
<zear> plus it had bugs, a lot.. ;)
<zear> kristianpaul, and thanks you've remembered about gmenu2x ;)
<zear> i have also ported dgclock, though it was later reported by someone else from the original sources without button caption changes ;)
<kristianpaul> zear: btw you know other projects like gmenu2x but a bit simpler, but not dmenu? :p
<zear> there is a mc-like menu
<zear> written in sdl
<zear> for the dingoo
<zear> no idea if the code is open though
<kristianpaul> so how you get in to it? or just heard/saw pics?
<zear> it was released for the dingoo, i haven't tried it myself
<zear> just saw the pictures
<zear> let me find it
<zear> kristianpaul, oh hey, the source is actually out
<zear> kristianpaul, compiles fine for x86
<wpwrak> kristianpaul: (enc28k60) ubb + bitbang ! ;-)
<kristianpaul> wpwrak: got it :-)
<kristianpaul> k?
<kristianpaul> the 100Mb/s version ?
<kristianpaul> wpwrak: if it is chip compatible i can order one why not
<kristianpaul> so far this is just 10Mb/s
<wpwrak> the chip operates with 3.3 V, so it should be fine
<wpwrak> seems to need 5 I/O lines. UBB has 6. more than enough ;-)
<kristianpaul> zear: an nc...
<kristianpaul> well i was in thinking something else
<kristianpaul> like a kexecboot-like menu :p
<zear> kristianpaul, this thing can actually launch binaries
<kristianpaul> zear: yeah but is a file browser..
<zear> well, i don't really see a difference ;)
<kristianpaul> well,if your apps are in the same dir, will look like more a menu.
<zear> yep
<kristianpaul> zear: have you seen kexecboot menu?
<zear> looking at it now
<zear> looks nice, but a file browser is so much easier in use ;)
<kristianpaul> really?
<zear> i can only imagine the ordeal of adding new links to that thing :)
<kristianpaul> well, thats a task for the developero, but if the menu worsk, load fast and the know-workign apps get lunched and all wokrs like a charm... well :-)
<kristianpaul> also i forgot to said, somebody was/is digging and removing som unusefull code from gmenu2x, thats could change things
<whitequark> kristianpaul: is the source code for that fork published?
<whitequark> that's interesting
<kristianpaul> may be last image already included that.. well i dont know
<wpwrak> zear: a file browser is also a little fat ...
<kristianpaul> whitequark: in projects.qi-hardware.com there is one for gmenu2x fork i think
<kristianpaul> i know the code is around
<kristianpaul> i saw several commits from qi-bot last weeks
<zear> wpwrak, i thought you guys were a bunch of geeks who dislike anything that's fool proof ;)
<kristianpaul> no no, well thats not the idea i think
<zear> well, gmenu2x does the job just fine, doesn't it?
<zear> kristianpaul, there's also this: http://home.gna.org/gp2xmb/
<zear> it needs some work, but is presenting very well
<kristianpaul> zear: kinda it does, but is just getting fat/slow as time goes
<kristianpaul> woah looks interesting
<kristianpaul> gp2xmb^
<zear> kristianpaul, here you can see it in action: http://www.youtube.com/watch?v=eSxwkB3a9J8
<zear> (whenever dingux is on)
<kristianpaul> zear: is feasible to port this gp2xmb?
<kristianpaul> may be you already looked at the code?..
<zear> it was ported to the dingoo, so i see no reason why it couldn't be compiled for the nn
<zear> i don't know about the code, but feature wise the dingux port was reather broken
<zear> it was quite an early port though
<zear> but then somebody ported gmenu2x and everybody forgot about that
<kristianpaul> hum..
<kristianpaul>     * >=libsdl-1.2.11
<kristianpaul>     * >=sdl-mixer-1.2.7
<kristianpaul>     * >=sdl-gfx-2.0.13
<kristianpaul>     * >=sdl-image-1.2.5
<kristianpaul>     * >=libconfig-1.0.1
<qi-bot> [commit] David Kühling: plplot: fix compile problem on ubuntu 10.10 hosts (host's libm not found) http://qi-hw.com/p/openwrt-packages/54cdac8
<wpwrak> zear: (fool proof) oh, i wouldn't worry about that. fools are creative ;-)
<zear> ;)
<kristianpaul> thats true
<kristianpaul> all we are ;)
<grunthus> Hi, having reflashed my Ben, I notice the backlight stays on, with no timeout.
<grunthus> Not so good for battery life.
<larsc> but the screen is off?
<grunthus> Hi, no the screen stays on too, should have said.
<grunthus> had a look in dingoo settings, but didn't see a timeout setting there.
<grunthus> got to go now, perhaps see you here again larsc, thankyou.