| vladkorotnev | hello everyone :P | 06:15 |
|---|---|---|
| vladkorotnev | I got an old Russian game ">;5 'C45A" (transliteration: Pole Chudes) to run on my Ben NanoNote :D | 06:19 |
| vladkorotnev | demo: http://www.youtube.com/watch?v=gA27ig45O6w | 06:29 |
| xiangfu | vladkorotnev, do you fix your gcc problem? | 06:30 |
| vladkorotnev | xiangfu: yes, updated to 2011-05-24 image | 06:30 |
| xiangfu | :) | 06:30 |
| xiangfu | vladkorotnev, please test and give feedback. I am try to make dvdk happy :) | 06:31 |
| vladkorotnev | is it supposed to turn off the Ben screen after some inactivity? | 06:31 |
| xiangfu | not under gmenu2x. others should works fine. | 06:31 |
| vladkorotnev | I know :P | 06:31 |
| vladkorotnev | bye everyone | 06:35 |
| kyak | guess there was too much talking yesterday and dvdk didn't notice my remark abotu plplot -\ | 06:38 |
| kyak | xiangfu: how do you think we mark it BROKEN for now? | 06:38 |
| xiangfu | yes. ok for me, (under 'trunk' branch) | 06:39 |
| 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 | 06:39 |
| kyak | and it will fail soon, judging on BUILD_LOG size :) | 06:39 |
| xiangfu | run sed '/plplot/s/=y/=m' now ... :) | 06:40 |
| xiangfu | kyak, I just mark all plplot to '=m' | 06:45 |
| kyak | heh, not sure if it would help now | 06:48 |
| kyak | the make has probably decided what to build and in what order | 06:48 |
| kyak | already | 06:48 |
| kyak | do you think it re-reads .config every time it proceeds to building of next package? | 06:49 |
| qi-bot | [commit] kyak: plplot: mark as BROKEN for it doesn't build in trunk http://qi-hw.com/p/openwrt-packages/5fdb51a | 06:52 |
| xiangfu | (re-reads .config) not sure. let's see | 07:05 |
| qi-bot | The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log//home/xiangfu/compile-log//openwrt-xburst.trunk-full_system-05252011-0754/ | 10:22 |
| xiangfu | kyak, ^ | 10:23 |
| xiangfu | modify the .config before the package build works fine. | 10:23 |
| xiangfu | kyak, only the URL is wrong. I will fix it. | 10:23 |
| 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 | 10:43 |
| whitequark | if that was you, then reply please :) | 10:43 |
| wolfspraul | maybe mth? look here http://en.qi-hardware.com/irclogs/search?q=ipu | 10:47 |
| wolfspraul | march 30... | 10:47 |
| wolfspraul | or roh | 10:48 |
| wolfspraul | http://en.qi-hardware.com/irclogs/qi-hardware_2011-03-30.log.html | 10:48 |
| kyak | xiangfu: heh, nice :) | 10:59 |
| kyak | xiangfu: do you have an overview about how many packages (=m) have failed? | 10:59 |
| whitequark | wolfspraul: thanks a lot | 11:03 |
| whitequark | roh: hi! can you reply to some more stupid questions about IPU? | 11:08 |
| 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 | 11:21 |
| dvdk | kyak: you wrote plplot fails to build? | 11:22 |
| dvdk | do you have a build log handy? | 11:22 |
| kyak | dvdk: it's here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.trunk-full_system-05252011-0754/ | 11:22 |
| dvdk | kyak: you wrote that you marked it as @broken? it's not marked in the last checkout | 11:24 |
| kyak | it's marked broken in trunk | 11:28 |
| dvdk | ok, but does build fail in master or in trunk or in both? | 11:28 |
| kyak | it fails in trunk | 11:29 |
| dvdk | ah, ok, so no problem for current firmware? | 11:30 |
| kyak | no, it fails in trunk only | 11:30 |
| dvdk | that's good, then there is no need to hurry :) | 11:31 |
| Action: dvdk didn't ge t much sleep recently | 11:31 | |
| kyak | you should definitely sleep well before having a look at that :) | 11:32 |
| dvdk | just reading the build log. but don't even find a "real" error message other than "package/feeds/qipackages/plplot failed to build." | 11:33 |
| dvdk | was that a parallel build? | 11:33 |
| dvdk | uh? | 11:33 |
| dvdk | "Entering directory '...plplot" ... error ... "leaving directory '..plplot'". it doesn't even try to run th emakefile? | 11:34 |
| kyak | it doesn't build driversd | 11:36 |
| kyak | and then fails during install stage | 11:36 |
| kyak | that's al i know | 11:36 |
| dvdk | ok, my mistake, somehow i accidentally modified the build_log | 11:37 |
| dvdk | kyak: i think i have found the problem (just looking at the build log) | 11:48 |
| dvdk | it says 'WARNING: libltdl library not found. Setting ENABLE_DYNDRIVERS OFF.' | 11:48 |
| dvdk | so that's why there are no .so drivers generated, and installation fails | 11:49 |
| dvdk | strange libltdl is listed under build_depends | 11:49 |
| dvdk | the line before that it says ' Looking for dlopen in dl - not found' | 11:49 |
| dvdk | maybe libltdl/libdl are note the same in trunk? | 11:49 |
| kyak | hm | 11:52 |
| kyak | btw.. is it possible to link all these dyndrivers statically? | 11:52 |
| kyak | i think it's linked already in one libplplot.so ? | 11:53 |
| kyak | perhaps it would be easier than figuring our why configure can't find libltdl | 11:53 |
| dvdk | kyak: no i don't want that the way it is now, we can install stuff like the qt output separately. | 11:54 |
| kyak | ah, right.. | 11:54 |
| dvdk | also we only load those drivers which are really used | 11:54 |
| dvdk | if we always pulled in qt, we'd map 16MB of .so code | 11:54 |
| dvdk | (i guess) | 11:54 |
| kyak | ok | 11:54 |
| kyak | would be intersting to have a look at config.log | 11:55 |
| dvdk | i can run a few more tests. currently plplot doesn't even compile in master branch for me (dependency problem? don't know) | 11:55 |
| dvdk | yes that'd be nice | 11:55 |
| kyak | http://fidelio.qi-hardware.com/~xiangfu/openwrt-xburst.trunk/build_dir/target-mipsel_uClibc-0.9.32/plplot-5.9.7/ | 11:56 |
| kyak | and there is no config.log.. was it the message from cmake? | 11:56 |
| kyak | dvdk: btw, perhaps it also makes sense to rewrite the Makefile, cause it was written in days when there was no cmake.mk | 11:57 |
| kyak | i don't know if this would help | 11:58 |
| dvdk | kyak: current cmake.mk won't help, doesn't support some tricks we're doing. would have to recode that. | 11:58 |
| dvdk | s/recode/add | 11:58 |
| dvdk | btw there's the log: | 11:59 |
| dvdk | CMakeFiles/CMakeError.log | 11:59 |
| dvdk | "libdl.c:(.text._dl_parse_relocation_information+0x1dc): undefined reference to `TLS_DTPREL_VALUE'" | 11:59 |
| dvdk | that's the problem. new uclibc? no TLS support? | 11:59 |
| kyak | new uclibc - for sure. and don't know what the hell TLS is | 12:00 |
| kyak | but it looks like the problem is on libdl side anywau.. | 12:01 |
| dvdk | "thread local storage" (maybe?) | 12:01 |
| dvdk | not necessarily, maybe we need to link another lib when using libdl? | 12:01 |
| dvdk | but libdl is used everywhere. if this is broken, you'd have many more build problems | 12:02 |
| kyak | maybe it's used, but "TLS" fucntions are not used | 12:02 |
| 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 | 12:04 |
| dvdk | doing my next try, building plplot at least on master (enabled fortran support, maybe that's needed? | 12:05 |
| dvdk | ) | 12:05 |
| wpwrak | DocScrutinizer: (EL PCB tester) hmm, how exactly would that work ? and where do you get such a display ? | 12:06 |
| 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 | 12:09 |
| wpwrak | phew. now there's a piece that's hard to source :) | 12:10 |
| DocScrutinizer | I'm sure 3M or sb is selling this stuff by the meter nowadays | 12:10 |
| DocScrutinizer | maybe you even can get paint to apply to a glas covered with the gnd electrode SnO2 | 12:11 |
| DocScrutinizer | or was it ZnO2? the transparent stuff used in LCD | 12:12 |
| DocScrutinizer | hard to source - maybe. Hard to build - don't think so | 12:13 |
| 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" | 12:16 |
| DocScrutinizer | wpwrak: got the basic idea? | 12:20 |
| DocScrutinizer | it's not a QA tester but a mere RE tool | 12:21 |
| DocScrutinizer | for complex multilayer PCB to analyze the connections | 12:24 |
| 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 | 12:25 |
| DocScrutinizer | soory for this being somewhat anti-topic here ;-D | 12:26 |
| 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 :) | 12:28 |
| wpwrak | DocScrutinizer: i wonder how they actually do the electrical testing of PCBs in industry. bed of nails seems ... messy | 12:29 |
| DocScrutinizer | wpwrak: already thought about it, use front 'half' of a plasma screen | 12:29 |
| 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 | 12:31 |
| DocScrutinizer | can be done with one pair of CNC probes | 12:31 |
| wpwrak | okay, that's for large volumes, where you make a custom tester. but for smaller/prototype volumes ? | 12:32 |
| wpwrak | ah, cnc probes. that would be slow then. but probably okay for small volumes | 12:32 |
| wpwrak | been trying to figure out a way to do such things with my mill. testing pcbs is so boring ;-) | 12:33 |
| DocScrutinizer | anyway doing this N^2 times for a unknown PCB with N (>1000) pads is a nogo | 12:34 |
| DocScrutinizer | having a way to sense all pads concurrently (like with my EL tester) will reduce the effort from N^2 to N | 12:35 |
| wpwrak | another way: heat the pad and look at the board with an IR camera | 12:37 |
| 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 | 12:37 |
| DocScrutinizer | (heat) wont't fly | 12:38 |
| wpwrak | (heat) would be worth a try ... if i had one of these expensive ir cameras :) | 12:38 |
| DocScrutinizer | you can't follow a trace >10mm in layer 4/8 this way | 12:39 |
| wpwrak | you should be able to see where it comes out again | 12:39 |
| DocScrutinizer | esp the fine ones used today, which are like 0.05mil | 12:40 |
| DocScrutinizer | nah | 12:40 |
| wpwrak | Cu should still conduct the heat a lot better than the FR4 | 12:40 |
| wolfspraul | DocScrutinizer: why is this anti-anything? that's great stuff | 12:40 |
| DocScrutinizer | if it doesn't come out <10mm from your heated pad, you get nothing useful | 12:40 |
| wolfspraul | thanks a lot for sharing | 12:40 |
| DocScrutinizer | wolfspraul: it's about RE of closed hw :-) | 12:41 |
| qi-bot | [commit] kyak: gcc-mips: restore cache-amnesia patch to fix build on x64 http://qi-hw.com/p/openwrt-packages/681b260 | 12:41 |
| qi-bot | [commit] kyak: centerim5: fix git url; checkout mob branch http://qi-hw.com/p/openwrt-packages/f741694 | 12:41 |
| wolfspraul | let's call it analysis first | 12:41 |
| wolfspraul | and analysis can be used for many different applications | 12:41 |
| DocScrutinizer | indeed | 12:41 |
| wolfspraul | I'm serious. not trying to 'hide' reverse engineering | 12:42 |
| wolfspraul | reverse engineering is an awesome technique in and of itself | 12:42 |
| DocScrutinizer | and the project itself can be attributed open hw anyway | 12:42 |
| wolfspraul | efficient analysis ideas and tools can come in handy in many situations | 12:42 |
| wolfspraul | so - great stuff! :-) | 12:43 |
| DocScrutinizer | this method, while not fit for decent QA of PCB, could come in handy for a quick and dirty good/bad test | 12:43 |
| 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 :-) | 12:44 |
| DocScrutinizer | as it detects one of the most annoying failure patterns of PCB: shorts | 12:44 |
| 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 | 12:46 |
| DocScrutinizer | I hope this chan is logged ;-D | 12:47 |
| DocScrutinizer | with proper date stamps | 12:47 |
| DocScrutinizer | you should probably make sure your DUT PCB has the hydrogen side of current flow, not the oxigen one ;-D | 12:48 |
| wpwrak | DocScrutinizer: try it and send pictures ? | 12:49 |
| DocScrutinizer | might consider it, yeah. Alas I have no good camera | 12:49 |
| DocScrutinizer | esp for the bga pads that are microscopic | 12:50 |
| DocScrutinizer | you'd need a really really good camera for that | 12:50 |
| DocScrutinizer | plus professional lighting, stand etc | 12:51 |
| DocScrutinizer | sounds like sth I could do for a master thesis :-D | 12:51 |
| wolfspraul | DocScrutinizer: yes the channel is logged and the logs were even beautified recently... | 12:58 |
| DocScrutinizer | :-D | 12:58 |
| DocScrutinizer | just for eventual lawsuits | 12:58 |
| wolfspraul | http://en.qi-hardware.com/irclogs/ | 12:58 |
| 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 | 12:59 |
| DocScrutinizer | and I'm not really in the situation for registering patents | 13:00 |
| 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 :) | 13:00 |
| DocScrutinizer | wpwrak: (heat) on vias you lose | 13:08 |
| DocScrutinizer | I bet a beer it's not worth trying | 13:08 |
| DocScrutinizer | what you *can* get by checking heat is the actual routing of a burried trace, when you send current thru it | 13:10 |
| 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) | 13:10 |
| 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) | 13:11 |
| wpwrak | yeah, current always works :) O(n^2), though. | 13:11 |
| wpwrak | are you trying to reverse-engineer something specific ? | 13:12 |
| 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 | 13:13 |
| DocScrutinizer | wpwrak: nothing special. Just looking at this N900 bare board and pondering about the few testpoints not mentioned in the 'leaked' schematics | 13:14 |
| DocScrutinizer | rhen recalling how I started my chitchat with OM, by ranting "gimme schematics, or I'll do <see above>" ;-D | 13:15 |
| wpwrak | ;-) | 13:16 |
| wolfspraul | you can use sandpaper to go through the layers and then scan them | 13:16 |
| DocScrutinizer | indeed, but that's a lousy method, and frequently introduces lots of errors on vias | 13:16 |
| DocScrutinizer | and usually will need >5 PCB to ruin that way | 13:17 |
| DocScrutinizer | also takes "ages" | 13:18 |
| wolfspraul | I haven't done it myself, but definitely you can do it with one pcb | 13:18 |
| DocScrutinizer | and all your hair | 13:18 |
| wolfspraul | http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#PCB_layers | 13:18 |
| wolfspraul | steve|m did it a little while back with a board | 13:19 |
| wolfspraul | http://en.qi-hardware.com/irclogs/qi-hardware_2011-02-21.log.html#t02:48 | 13:19 |
| wolfspraul | "I used corning 120, and 400 for polishing it before scanning" | 13:19 |
| 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" | 13:19 |
| wolfspraul | "400 is only used like 30-50 seconds :)" | 13:20 |
| DocScrutinizer | duh, nice job | 13:21 |
| 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 | 13:21 |
| DocScrutinizer | didn't think it could be done that cleanly | 13:21 |
| 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 | 13:21 |
| roh | re | 13:22 |
| DocScrutinizer | lo roh | 13:22 |
| 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. | 13:22 |
| wolfspraul | it is slow and tedious, no doubt | 13:22 |
| wolfspraul | many hours with the sandpaper | 13:22 |
| DocScrutinizer | and won't show micro-short defects etc | 13:23 |
| wolfspraul | and you need a few iterations before you are good at it | 13:23 |
| wolfspraul | but other than that it's a simple and effective technique to picture the layers | 13:23 |
| DocScrutinizer | indeed | 13:23 |
| qi-bot | [commit] kyak: ghostscript: update to 9.02, fix build http://qi-hw.com/p/openwrt-packages/601c607 | 13:23 |
| DocScrutinizer | I knew of this, but didn't think it's that easy | 13:23 |
| DocScrutinizer | anyway it's not exactly for any nondestructive testing, obviously ;-D | 13:24 |
| wolfspraul | indeed | 13:24 |
| wolfspraul | ;-) | 13:24 |
| wolfspraul | for the pics of that smartphone (G2), I paid about 100 USD | 13:24 |
| wolfspraul | I give them 2 boards, 100 USD, they send me the jpegs 2 days later | 13:25 |
| wolfspraul | even more like 90 USD I think | 13:25 |
| DocScrutinizer | now you only need an autistic nerd to convert these pics to a connection-table | 13:25 |
| wolfspraul | and I didn't bargain much | 13:25 |
| wolfspraul | the kid that is doing the sanding maybe gets 2 USD / hour... | 13:25 |
| wpwrak | USD ~500/month ? wow ! | 13:26 |
| qi-bot | [commit] Xiangfu Liu: dega: using nanonote version source code http://qi-hw.com/p/openwrt-packages/6f32e10 | 13:27 |
| xiangfu | wolfspraul, ^ see the line_three of this diff :D | 13:31 |
| qi-bot | [commit] kyak: ghostscript: really update to 9.02 http://qi-hw.com/p/openwrt-packages/11ff553 | 13:31 |
| wolfspraul | wpwrak: is it 'wow' because so low or so high? | 13:32 |
| wpwrak | so high ! isn't that what fully grown factory workers make ? | 13:33 |
| wolfspraul | yes but they just take one of their workers | 13:34 |
| wolfspraul | "today, you have to sandpaper this pcb" | 13:34 |
| wolfspraul | :-) | 13:34 |
| wpwrak | great way to escape the daily boredom of the factory line ;-) | 13:37 |
| 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 | 13:38 |
| roh | teachers of professions.. like if you end up in siemens 'lehrwerkstatt' for some time | 13:39 |
| roh | not neccessarily a nice experience, but usually one which makes your handywork improve a lot | 13:40 |
| 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? | 13:51 |
| dvdk | oops, compile error (branch master | 14:00 |
| dvdk | package dropbear) | 14:00 |
| 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 | 14:00 |
| 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 | 14:00 |
| Action: kristianpaul wonder what you can buy with 500usd in china | 14:21 | |
| whitequark | does anyone have docs on Ingenc SIMD instruction set? | 18:06 |
| kristianpaul | nope :( | 18:23 |
| kristianpaul | but | 18:23 |
| kristianpaul | dingux wiki have some data about it | 18:24 |
| kristianpaul | i heard also mplayer source code from ingenic have it | 18:24 |
| kristianpaul | have imoplemented SIMD as asm, | 18:24 |
| whitequark | kristianpaul: the mplayer code is a huge load of crazy shit | 18:30 |
| whitequark | you'll need to be an ingenic developer to understand even a small bit of it | 18:31 |
| whitequark | the dingux wiki has a really great manual | 18:33 |
| whitequark | thanks | 18:33 |
| kristianpaul | yeah but not said i dint point you to mplayer | 18:55 |
| whitequark | kristianpaul: well, I knew about mplayer and already checked it as a possible source | 18:59 |
| whitequark | and it's an awful source of information for a complex thing like SIMD ISA | 18:59 |
| kristianpaul | btw can you tell us what are you planning to do with SIMD and the nanonote? | 19:15 |
| zear | hey | 19:15 |
| kristianpaul | hai | 19:15 |
| zear | i left you guys just for a moment and you've done a wireless adapter already? :D | 19:15 |
| kristianpaul | pcb so far | 19:15 |
| zear | well, as long as it works, i'm gonna order two :D | 19:16 |
| kristianpaul | SMT is a WIP but not updates from tuxbrain tha i'm aware off | 19:16 |
| kristianpaul | yeah it does zear | 19:16 |
| kristianpaul | did you saw wpwrak maill about the tunnel he made to do ssh and ping between nanonotes? | 19:16 |
| zear | i think i've seen the vid | 19:17 |
| kristianpaul | ya, that famous video indeed ;-) | 19:17 |
| zear | btw, did owrt got any better in the terms of the libs and toolchain? | 19:17 |
| zear | so i can port some games without a bigger hassle? | 19:18 |
| kristianpaul | well. i guess you should consult about owrt libraries avaliabillity | 19:20 |
| 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 | 19:21 |
| kristianpaul | so wait xiangfu or ask kyak i hink | 19:21 |
| kristianpaul | think* | 19:21 |
| zear | yeah, same, with the exception i also used the dingoo toolchain with statically linked binaries :D | 19:21 |
| kristianpaul | hey, i about to point you that (statically linked games) | 19:22 |
| 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? | 19:22 |
| zear | kristianpaul, you could like the binary dynamically and keep your own libs in the local directory | 19:23 |
| zear | and change the priority of libs over the system ones | 19:23 |
| kristianpaul | oh | 19:24 |
| zear | export LD_LIBRARY_PATH or something | 19:24 |
| kristianpaul | ah, true :-) i forgot is all about those env variables.. | 19:25 |
| kristianpaul | so, what games are you wishing to port zear ? :o | 19:26 |
| zear | kristianpaul, i already did some ports very early in the nn history | 19:26 |
| zear | yet before the first batch | 19:26 |
| zear | though it was all statically linked with the dingoo libs | 19:27 |
| zear | i did spout, prboom, eduke32 | 19:27 |
| zear | also cave story, which i never released | 19:27 |
| zear | brb | 19:27 |
| kristianpaul | ah yes i remenber prboom | 19:28 |
| kristianpaul | and gmenu2x wich not a game but very important | 19:28 |
| kristianpaul | and that make me remenber somebody was asking for dmenu the other day | 19:28 |
| Jay7 | one day someone was asked me about making standalone fb menu from kexecboot :) | 19:48 |
| kristianpaul | Jay7: yes :-D | 19:50 |
| wpwrak | Jay7: makes perfect sense. ideally, kexecboot should just be a bundle of general components. the fewer kexecboot-specific parts you need, the better. | 19:50 |
| Jay7 | btw, may be good idea to do this.. | 19:51 |
| Jay7 | fb lib + menu lib + xpm lib + ... :) | 19:51 |
| kristianpaul | yay, the ENC28J60 just get to my mother work :-) | 19:53 |
| kristianpaul | i'll get some fun with linux soon it seems | 19:54 |
| kristianpaul | bitbang or spi? | 19:54 |
| kristianpaul | ENC28J60 <- http://www.sigmaelectronica.net/tarjeta-ethern-p-1503.html | 19:54 |
| zear | kristianpaul, i wouldn't bother playing with dmenu | 19:55 |
| 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 | 19:56 |
| zear | plus it had bugs, a lot.. ;) | 19:56 |
| zear | kristianpaul, and thanks you've remembered about gmenu2x ;) | 19:57 |
| zear | i have also ported dgclock, though it was later reported by someone else from the original sources without button caption changes ;) | 19:58 |
| kristianpaul | zear: btw you know other projects like gmenu2x but a bit simpler, but not dmenu? :p | 19:58 |
| zear | there is a mc-like menu | 19:59 |
| zear | written in sdl | 19:59 |
| zear | for the dingoo | 19:59 |
| zear | no idea if the code is open though | 19:59 |
| kristianpaul | so how you get in to it? or just heard/saw pics? | 20:00 |
| zear | it was released for the dingoo, i haven't tried it myself | 20:00 |
| zear | just saw the pictures | 20:00 |
| zear | let me find it | 20:00 |
| zear | kristianpaul, oh hey, the source is actually out | 20:01 |
| zear | http://boards.dingoonity.org/dingoonity-news/dinguxcommander-2-1/ | 20:01 |
| zear | kristianpaul, compiles fine for x86 | 20:03 |
| wpwrak | kristianpaul: (enc28k60) ubb + bitbang ! ;-) | 20:04 |
| kristianpaul | wpwrak: got it :-) | 20:06 |
| kristianpaul | k? | 20:07 |
| kristianpaul | the 100Mb/s version ? | 20:07 |
| kristianpaul | wpwrak: if it is chip compatible i can order one why not | 20:08 |
| kristianpaul | so far this is just 10Mb/s | 20:09 |
| wpwrak | the chip operates with 3.3 V, so it should be fine | 20:11 |
| wpwrak | seems to need 5 I/O lines. UBB has 6. more than enough ;-) | 20:14 |
| kristianpaul | zear: an nc... | 20:53 |
| kristianpaul | well i was in thinking something else | 20:54 |
| kristianpaul | like a kexecboot-like menu :p | 20:54 |
| zear | kristianpaul, this thing can actually launch binaries | 20:57 |
| kristianpaul | zear: yeah but is a file browser.. | 21:05 |
| zear | well, i don't really see a difference ;) | 21:05 |
| kristianpaul | well,if your apps are in the same dir, will look like more a menu. | 21:05 |
| zear | yep | 21:05 |
| kristianpaul | zear: have you seen kexecboot menu? | 21:06 |
| zear | looking at it now | 21:06 |
| zear | looks nice, but a file browser is so much easier in use ;) | 21:06 |
| kristianpaul | really? | 21:07 |
| zear | i can only imagine the ordeal of adding new links to that thing :) | 21:07 |
| 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 :-) | 21:09 |
| kristianpaul | also i forgot to said, somebody was/is digging and removing som unusefull code from gmenu2x, thats could change things | 21:10 |
| whitequark | kristianpaul: is the source code for that fork published? | 21:10 |
| whitequark | that's interesting | 21:10 |
| kristianpaul | may be last image already included that.. well i dont know | 21:10 |
| wpwrak | zear: a file browser is also a little fat ... | 21:10 |
| kristianpaul | whitequark: in projects.qi-hardware.com there is one for gmenu2x fork i think | 21:11 |
| kristianpaul | i know the code is around | 21:11 |
| kristianpaul | i saw several commits from qi-bot last weeks | 21:11 |
| zear | wpwrak, i thought you guys were a bunch of geeks who dislike anything that's fool proof ;) | 21:12 |
| kristianpaul | no no, well thats not the idea i think | 21:13 |
| zear | well, gmenu2x does the job just fine, doesn't it? | 21:15 |
| zear | kristianpaul, there's also this: http://home.gna.org/gp2xmb/ | 21:16 |
| zear | it needs some work, but is presenting very well | 21:16 |
| kristianpaul | zear: kinda it does, but is just getting fat/slow as time goes | 21:16 |
| kristianpaul | woah looks interesting | 21:17 |
| kristianpaul | gp2xmb^ | 21:17 |
| zear | kristianpaul, here you can see it in action: http://www.youtube.com/watch?v=eSxwkB3a9J8 | 21:17 |
| zear | (whenever dingux is on) | 21:18 |
| kristianpaul | zear: is feasible to port this gp2xmb? | 21:20 |
| kristianpaul | may be you already looked at the code?.. | 21:20 |
| zear | it was ported to the dingoo, so i see no reason why it couldn't be compiled for the nn | 21:20 |
| zear | i don't know about the code, but feature wise the dingux port was reather broken | 21:21 |
| zear | it was quite an early port though | 21:21 |
| zear | but then somebody ported gmenu2x and everybody forgot about that | 21:21 |
| kristianpaul | hum.. | 21:27 |
| kristianpaul | * >=libsdl-1.2.11 | 21:28 |
| kristianpaul | * >=sdl-mixer-1.2.7 | 21:28 |
| kristianpaul | * >=sdl-gfx-2.0.13 | 21:28 |
| kristianpaul | * >=sdl-image-1.2.5 | 21:28 |
| kristianpaul | * >=libconfig-1.0.1 | 21:28 |
| 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 | 21:43 |
| wpwrak | zear: (fool proof) oh, i wouldn't worry about that. fools are creative ;-) | 21:49 |
| zear | ;) | 21:50 |
| kristianpaul | thats true | 21:53 |
| kristianpaul | all we are ;) | 21:59 |
| grunthus | Hi, having reflashed my Ben, I notice the backlight stays on, with no timeout. | 22:29 |
| grunthus | Not so good for battery life. | 22:29 |
| larsc | but the screen is off? | 22:33 |
| grunthus | Hi, no the screen stays on too, should have said. | 22:34 |
| grunthus | had a look in dingoo settings, but didn't see a timeout setting there. | 22:34 |
| grunthus | got to go now, perhaps see you here again larsc, thankyou. | 22:43 |
| --- Fri May 27 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!