adamw_ | xiangfu, can we have an item about full screen shows up in test program? If yes, make this item as an optional but not include it into totally pass counting. | 03:19 |
---|---|---|
xiangfu | adamw_, " full screen shows up in test program" what you mean 'full screen' ? | 03:20 |
adamw_ | so far now I'd prefer to test incoming camera quality check in test program | 03:20 |
adamw_ | yes, full screen | 03:21 |
adamw_ | then I don't need to power-cycle again to rendering mode or select 'full screen' patch in gui | 03:22 |
adamw_ | I'd like test program to have this function while I can also test all keyboards for incoming parts check. | 03:23 |
adamw_ | Of course in gui can also do everything, but I'd this 'full screen' included in test program, if it's easy. ;-) | 03:23 |
xiangfu | let me check | 03:28 |
xiangfu | adamw_, just double check the videoin test. it only use half screen. | 04:00 |
xiangfu | adamw_, you just want full screen? | 04:00 |
xiangfu | adamw_, or direct load videoin test will give blank screen, I have to start 'vga' test first, then 'videoin' will working | 04:00 |
adamw_ | xiangfu, yes, the initialization on vga firstly then video-in, so I'd also suggest that it also initiate vga chip before video-in test while I press 'h' to test video-in, i.e. I think it doesn't matter to add initialization in video-in test item, how do you think? | 04:04 |
xiangfu | adamw_, yes. but before test videoin. better test VGA. | 04:05 |
adamw_ | when you repeatedly press 'h' to test camera, you will get '5' and '4' not '7' and '4'. did you see that whenn you repeatedly test video-in | 04:06 |
adamw_ | xiangfu, sure, agreed, so in order to test video-in, i have to press 'd' to test vga first, so i don't think i need to always press 'd' again | 04:07 |
xiangfu | adamw_, yes. it' give me 5 and 4 when repeat press 'h' | 04:08 |
adamw_ | btw, check if it's possible make it full screen in test program. if it's easy. | 04:08 |
adamw_ | xiangfu, yes, pls take some times to fix that from '7' to '5' | 04:09 |
adamw_ | it must be s/w initialization in video chip, maybe reset video codec somewhere, when I repeatedly test it | 04:09 |
adamw_ | so i won't be confused that if camera detect is not good, actually this is definitely s/w initial problem. I want to see every time it shows '7' and '4' when I press 'h'. | 04:11 |
xiangfu | adamw_, ok. 1 try to full screen. 2. check why it's give '5' sometimes. it should always '7' right? | 04:13 |
adamw_ | xiangfu, yes, thanks a lots. | 04:13 |
xiangfu | adamw_, seems the half screen is on purpose. | 04:17 |
adamw_ | my question is the vga pattern can be full screen, but why camera's out can not pass through a full screen, if it's a little hard, no rush to understand it now. ;-) | 04:20 |
xiangfu | adamw_, no. the video in buffer is 720x288. and VGA buffer is 640x480. | 04:24 |
xiangfu | so it cut the video in buff to from 720x288 to 640x288 | 04:24 |
xiangfu | I can insert a duplicate data in 288. it's like 1 2 3 4 --> 11 22 33 44 , make 288 stretch to 480 | 04:26 |
adamw_ | you can study for a while first, not directly insert, since my goal is to see full screen in test program. so inserting data is if a good idea, maybe you can ask wpwrak. or you can study how gui to process this full screen's method in 640 * 480 mode firstly? ;-) | 04:33 |
adamw_ | well..no rush on this feature. thanks. :) | 04:33 |
xiangfu | where I can find more info about m1 TMU | 05:06 |
xiangfu | ok. seems the easy way is just insert duplicate data , under flickernoise. it's using TMU to display full screen. if I understand correct. | 05:09 |
xiangfu | http://milkymist.org/socdoc/tmu2.pdf | 05:12 |
GitHub23 | [autotest-m1] xiangfu pushed 2 new commits to master: http://git.io/4Vd3jg | 05:18 |
GitHub23 | [autotest-m1/master] build depends libs - Xiangfu Liu | 05:18 |
GitHub23 | [autotest-m1/master] tests_videoin: stretch to fullscreen - Xiangfu Liu | 05:18 |
GitHub70 | [autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/Yyb14w | 05:27 |
GitHub70 | [autotest-m1/master] add git rev to boot.crc.bin - Xiangfu Liu | 05:27 |
wpwrak | booting ... | 06:45 |
wpwrak | ah, test programs :) | 06:55 |
aw | rc3 accessories packing 30 sets done without m1/case: http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_30sets_accessories_packing.JPG | 07:19 |
aw | http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_30sets_accessories_packing1.JPG | 07:20 |
aw | those 30 sets I put accessories firstly by following instructions. later I'll put whole assembled M1 with case in EVA. | 07:23 |
aw | now next step: assembly of m1 with cases. | 07:23 |
qi-bot | The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09022011-1116/ | 10:11 |
lekernel | xiangfu, is there anything new in those openwrt images? | 10:17 |
adamw_ | finger cot: http://downloads.qi-hardware.com/people/adam/m1/pic/rc3_m1_case_assemble_finger_cot.JPG | 13:58 |
aeris | Plus pratique les gants... | 14:03 |
wpwrak | aeris: i guess the cute fingertip thingies give you better respiration | 14:05 |
aeris | It's true | 14:05 |
kristianpaul | nice cot, very fingy ;) | 14:07 |
Fallenou | nice ! | 14:08 |
kristianpaul | actually because when you uses gloves doest feel very confortable for manipulate tiny styuff | 14:08 |
lekernel | I'm sure wpwrak could find an interesting name for those | 14:08 |
kristianpaul | s/for/to | 14:09 |
kristianpaul | yup | 14:09 |
wpwrak | "finger cot" appears to be a sensible name ... the expression does exist in regular english | 14:11 |
adamw_ | my poor english so just found that name for it. ;-) | 14:12 |
adamw_ | well...before put into EVA, need to check and clean if need. :) | 14:13 |
xiangfu | lekernel, (openwrt) no. I just setup the build. | 14:17 |
lekernel | xiangfu, maybe it can skip it if there has been no new commit since last build? | 14:19 |
xiangfu | lekernel, yes. in TODO list. haven't setup that. :) | 14:20 |
lekernel | wolfspraul, to improve startup feedback, what do you think of blinking the render LED while the patches are compiling? | 15:16 |
wpwrak | i wonder if it would be really so hard to just cache compiled patches ... kinda the equivalent of for p in *.patch; do c=`md5sum "$p" | sed 's/ .*//'`; if [ ! -r "$c" ]; then compile <"$p" >tmp && mv tmp "$c"; false; fi && load_patch "$c"; done | 15:59 |
GitHub156 | [autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/DsW8NQ | 16:00 |
GitHub156 | [autotest-m1/master] output build data time and git rev when start - Xiangfu Liu | 16:00 |
wolfspraul | sure - blinking, why not :-) | 16:03 |
lekernel | wpwrak, in theory not, but you have to define a format for loading and storing, which isn't supported yet | 16:10 |
lekernel | also it should do the right thing when loading a patch that has been compiled by an earlier incompatible version of FN | 16:11 |
wpwrak | (format) ah, i see. so it's not just a long byte string you could just dump | 16:12 |
wpwrak | (incompatible) erase the cache each time you upgrade FN ? :) | 16:12 |
wpwrak | (or downgrade, same-grade, whatever) | 16:13 |
wolfspraul | I think we can also delete cache files each time the patch is edited/written, since we control the (few) access paths in the sources quite well | 16:13 |
wolfspraul | that would solve the need for any timestamp or hash | 16:14 |
wpwrak | this wouldn't affect the out-of-the-box experience because adam would have already sat through that initial compilation when testing | 16:14 |
wpwrak | wolfspraul: according to sebastien, no all access paths are controlled | 16:14 |
wpwrak | e.g., FTP or such | 16:14 |
wolfspraul | how is that not controlled? :-) | 16:17 |
wolfspraul | that's the secret radio backdoor in the xilinx fpga? | 16:17 |
wolfspraul | :-) | 16:17 |
wolfspraul | maybe it's ugly, but definitely it's another idea. just adding to the list. | 16:18 |
wpwrak | dunno. maybe it's a program that comes with RTEMS lekernel hasn't modified or doesn't want to modify | 16:18 |
wpwrak | to reliably delete the cache, you'd have to add taps to all the places that could change a patch. or introduce some generic file monitoring service to RTEMS | 16:19 |
wpwrak | well, one approach would be to have a designated upload area, from where patches are then moved through a controlled process | 16:20 |
wpwrak | the process would basically go like this: cd uploads/; for p in *.patch; do if [ -r "../patches/$p" ]; then c=`md5sum "../patches/$p" | sed 's/ .*//'`; rm -f ../cache/$c; fi; mv "$p" ../patches; ...compile...; done | 16:23 |
wpwrak | and most important, have a button to unconditionally delete the whole cache and force recompilation of all patches :) | 16:23 |
lekernel | wpwrak, a simple solution is to store the FN version number in the compiled patch, and ignore cached patches that do not have the same version tag as the current running software | 16:24 |
lekernel | the hashing part is easy, storing/loading compiled patches needs a bit of thought | 16:25 |
wpwrak | lekernel: yes, version numbers would work too. delete-on-upgrade would simple reuse the compile-if-not-cached mechanism, which may or may not be a little easier. depends a bit on what else you do when upgrading. | 16:28 |
kristianpaul | or add regex-core for better speed for patch compilation? | 16:41 |
kristianpaul | regex or whatever operation when compiling a patch could be improved in hardware | 16:41 |
wpwrak | huh ? you mean for the lexical scanner ? that should be O(n) :-) or is there some weird misuse of regexes in the patch compiler ? | 16:44 |
kristianpaul | dunno, just guessing :-) | 16:45 |
lekernel | nah, the patch compiler is using lemon+re2c (nice tools when the GNU stuff makes it hard to run the generated parsers on a non-GNU system) in a simple way | 16:49 |
kristianpaul | what is basically the procedure? path to magic ecuations that later are looped against the pfpu? | 16:57 |
lekernel | it is explained in thesis.pdf | 16:59 |
kristianpaul | yes i _still_ reading | 16:59 |
qi-bot | The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09022011-2351/ | 22:46 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!