<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.
<xiangfu>
adamw_, " full screen shows up in test program" what you mean 'full screen' ?
<adamw_>
so far now I'd prefer to test incoming camera quality check in test program
<adamw_>
yes, full screen
<adamw_>
then I don't need to power-cycle again to rendering mode or select 'full screen' patch in gui
<adamw_>
I'd like test program to have this function while I can also test all keyboards for incoming parts check.
<adamw_>
Of course in gui can also do everything, but I'd this 'full screen' included in test program, if it's easy. ;-)
<xiangfu>
let me check
<xiangfu>
adamw_, just double check the videoin test. it only use half screen.
<xiangfu>
adamw_, you just want full screen?
<xiangfu>
adamw_, or direct load videoin test will give blank screen, I have to start 'vga' test first, then 'videoin' will working
<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?
<xiangfu>
adamw_, yes. but before test videoin. better test VGA.
<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
<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
<xiangfu>
adamw_, yes. it' give me 5 and 4 when repeat press 'h'
<adamw_>
btw, check if it's possible make it full screen in test program. if it's easy.
<adamw_>
xiangfu, yes, pls take some times to fix that from '7' to '5'
<adamw_>
it must be s/w initialization in video chip, maybe reset video codec somewhere, when I repeatedly test it
<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'.
<xiangfu>
adamw_, ok. 1 try to full screen. 2. check why it's give '5' sometimes. it should always '7' right?
<adamw_>
xiangfu, yes, thanks a lots.
<xiangfu>
adamw_, seems the half screen is on purpose.
<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. ;-)
<xiangfu>
adamw_, no. the video in buffer is 720x288. and VGA buffer is 640x480.
<xiangfu>
so it cut the video in buff to from 720x288 to 640x288
<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
<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? ;-)
<adamw_>
well..no rush on this feature.  thanks. :)
<xiangfu>
where I can find more info about m1 TMU
<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.
<wpwrak>
aeris: i guess the cute fingertip thingies give you better respiration
<aeris>
It's true
<kristianpaul>
nice cot, very fingy ;)
<Fallenou>
nice !
<kristianpaul>
actually because when you uses gloves doest feel very confortable for manipulate tiny styuff
<lekernel>
I'm sure wpwrak could find an interesting name for those
<kristianpaul>
s/for/to
<kristianpaul>
yup
<wpwrak>
"finger cot" appears to be a sensible name ... the expression does exist in regular english
<adamw_>
my poor english so just found that name for it. ;-)
<adamw_>
well...before put into EVA, need to check and clean if need. :)
<xiangfu>
lekernel, (openwrt) no. I just setup the build.
<lekernel>
xiangfu, maybe it can skip it if there has been no new commit since last build?
<xiangfu>
lekernel, yes. in TODO list. haven't setup that.  :)
<lekernel>
wolfspraul, to improve startup feedback, what do you think of blinking the render LED while the patches are compiling?
<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
<GitHub156>
[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/DsW8NQ
<GitHub156>
[autotest-m1/master] output build data time and git rev when start - Xiangfu Liu
<wolfspraul>
sure - blinking, why not :-)
<lekernel>
wpwrak, in theory not, but you have to define a format for loading and storing, which isn't supported yet
<lekernel>
also it should do the right thing when loading a patch that has been compiled by an earlier incompatible version of FN
<wpwrak>
(format) ah, i see. so it's not just a long byte string you could just dump
<wpwrak>
(incompatible) erase the cache each time you upgrade FN ? :)
<wpwrak>
(or downgrade, same-grade, whatever)
<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
<wolfspraul>
that would solve the need for any timestamp or hash
<wpwrak>
this wouldn't affect the out-of-the-box experience because adam would have already sat through that initial compilation when testing
<wpwrak>
wolfspraul: according to sebastien, no all access paths are controlled
<wpwrak>
e.g., FTP or such
<wolfspraul>
how is that not controlled? :-)
<wolfspraul>
that's the secret radio backdoor in the xilinx fpga?
<wolfspraul>
:-)
<wolfspraul>
maybe it's ugly, but definitely it's another idea. just adding to the list.
<wpwrak>
dunno. maybe it's a program that comes with RTEMS lekernel hasn't modified or doesn't want to modify
<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
<wpwrak>
well, one approach would be to have a designated upload area, from where patches are then moved through a controlled process
<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
<wpwrak>
and most important, have a button to unconditionally delete the whole cache and force recompilation of all patches :)
<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
<lekernel>
the hashing part is easy, storing/loading compiled patches needs a bit of thought
<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.
<kristianpaul>
or add regex-core for better speed for patch compilation?
<kristianpaul>
regex or whatever operation when compiling a patch could be improved in hardware
<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 ?
<kristianpaul>
dunno, just guessing :-)
<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
<kristianpaul>
what is basically the procedure? path to magic ecuations that later are looped against the pfpu?