<xiangfu> lekernel: small patch for input.c http://pastebin.com/eTXxcJsu
<xiangfu> I found this:
<xiangfu> guirender.c:input_add_callback(mtk_input);
<xiangfu> guirender.c:mtk_input(&e[i+1], count-i-1);
<xiangfu> guirender.c:input_delete_callback(mtk_input);
<xiangfu> yes. it not cause any problem. just fyi :)
<xiangfu> lekernel: the shortcut for 'fbgrab' patches. sended out
<xiangfu> usb cable for daughter board http://ntcdistributing.com/images/UH2-2MBR02-12large.jpg
<xiangfu> wolfspraul: I think this usb cable is not good for milkymist one
<xiangfu> I only remove the 'Video-in Side' keeps all other. and screw the top.
<wolfspraul> xiangfu: yes I know
<wolfspraul> I think for real developers who always, for months, want access to jtag, they will all do that
<wolfspraul> but then there are people who need jtag only once every few months, maybe for a major update. At least until we have the GUI update done really well.
<wolfspraul> and for those it is easier to just take off the top
<wolfspraul> then reflash, then put the top back on
<xiangfu> oh. yes. that make sense.
<wolfspraul> but if you constantly want jtag, you will instead take the side element out, and put the top back on
<wolfspraul> then you will need a normal USB cable
<wolfspraul> getting the side element out is quite hard, you have to remove the screws of the video-in connector, and maybe also the screws on the bottom so that the side part is loose enough to be lifted
<wolfspraul> let's see how all this goes.
<wolfspraul> :-)
<wolfspraul> xiangfu: but I totally agree with your comment.
<wolfspraul> I will also leave the side open.
<wolfspraul> some people may also add an extra hole on the side
<xiangfu> I am think screw a hole on my 'video-in' side element :)
<wolfspraul> yes :-)
<kristianpaul> just make a hole for the jtag cable,of course using proper tools
<kristianpaul> s/make/made
<wolfspraul> the upward pointing USB cable has limited value, for sure
<wolfspraul> and the limited value may even go lower in a few months as we improve everything
<wolfspraul> so we may drop it again at some point. maybe we even drop the entire jtag-serial board at some point. Don't know.
<wolfspraul> now we need these things, to make the starting point easier, for a lot of people in different use cases.
<wolfspraul> I doubt the news have a big impact, but we need to keep the routine and keep pushing for a wider audience...
<wolfspraul> oops, wrong channel :-)
<xiangfu> kristianpaul: don't have that tools for now :)
<lekernel> wolfspraul: what's wrong with the current gui update?
<lekernel> "At least until we have the GUI update done really well."
<lekernel> xiangfu: why do you need "[PATCH 1/3] delete input callbacks from last"?
<xiangfu> hmm.. I found the main.c and guirender.c both run "input_add_callback(mtk_input);" and guirender.c run "input_delete_callback(mtk_input);" every time it delete . it delete the mtk_input in main.c
<xiangfu> lekernel: sorry. maybe I man wrong. just ignore that patch.
<xiangfu> lekernel: I should look into more detail.
<xiangfu> s/man/am
<xiangfu> just ignore that patch.
<lekernel> xiangfu: what guirender does is disconnect MTK from the events when rendering
<lekernel> so MTK does not draw stuff to the framebuffer anymore
<lekernel> otherwise you'd see flickering buttons, mouse cursor etc. when touching the mouse during rendering :)
<lekernel> it's a bit hacky, but it works
<xiangfu> lekernel: thanks for the info.
<xiangfu> some question. there is a "stop_callback" in guirender.c
<xiangfu> if there any reason the the stop_callback have to run inside  guirender.c when the guirender() success execute
<xiangfu> the rename the reboot.c to shortcuts.c. and add the "CTRL + F12" to that file.
<lekernel> yeah you can move it to reboot.c
<lekernel> so you have only one event hook
<lekernel> the stop_callback in guirender.c has nothing to do with the event hooks
<xiangfu> lekernel: ok.
<xiangfu> lekernel: I think I will try to focus on mkyaffs2image next few days.
<xiangfu> my TODO list on milkymist is here: http://en.qi-hardware.com/wiki/User:Xiangfu#Milkymist_One
<xiangfu> any feedback will be great :)
<xiangfu> (btw I test "creating a sub-folder on the flash and then uploading a file via FTP",test 24KB file and 3MB file. 24kb file works fine. 3MB file have problem. the m1 just freeze)
<xiangfu> back online later. will read log :)
<wolfspraul> lekernel: maybe it is evolving quicker than I can catch up. What's wrong is that I haven't tried yet :-)
<wolfspraul> so I should rephrase "after Wolfgang realized how good the GUI update already is, ..."
<lekernel> there aren't many issues with the GUI update. it's just select file and click flash.
<lekernel> and I haven't found a single bug there so far
<wolfspraul> ok, but I also want it to go to a website and download stuff
<lekernel> otoh if you're using FTP to transfer the files you might run into the ethernet bugs
<wolfspraul> milkymist.org/m1-updates/latest/...
<wolfspraul> will xiangfu's fbgrab also work during rendering?
<wolfspraul> will it stop rendering for x seconds?
<lekernel> yes
<wolfspraul> ok but it works, great
<CIA-43> flickernoise: Xiangfu Liu master * r17de0a3 / (5 files):
<CIA-43> flickernoise: move all fbgrab to one module
<CIA-43> flickernoise: Signed-off-by: Xiangfu Liu <xiangfu@sharism.cc> - http://bit.ly/dJIZjH
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r3fe7024 / src/Makefile : add fbgrab to Makefile - http://bit.ly/hHscbq
<CIA-43> flickernoise: Xiangfu Liu master * r953d9bb / (5 files):
<CIA-43> flickernoise: add global shortcuts module bind Ctrl + F12 to 'fbgrab'
<CIA-43> flickernoise: Signed-off-by: Xiangfu Liu <xiangfu@sharism.cc> - http://bit.ly/ehQGrL
<CIA-43> flickernoise: Sebastien Bourdeauducq master * rbda6c50 / src/Makefile : update Makefile - http://bit.ly/hQDKoo
<wolfspraul> lekernel: in the email to rejon, what do you mean with "proper lighting and black background"?
<wolfspraul> you mean black background for the projector to project to? light what?
<lekernel> use a black surface behind the dancer/object so the background doesn't get into the visual effect
<lekernel> no
<lekernel> camera+light | dancer | black background
<wolfspraul> ah I see. both refer to video-in.
<wolfspraul> got it
<lekernel> I use a piece of black cloth I can hang when using it
<wolfspraul> I never tried the actual video-in rendering, only made it to the preview dialog so far :-)
<xiangfu> kristianpaul: lekernel the IRCLOG search fixed. :)  http://en.qi-hardware.com/mmlogs/search?q=testing
<kristianpaul> :_)
<xiangfu> there are one typo in apache  configure file.
<kristianpaul> hmm ;)
<xiangfu> kristianpaul: but the log file you send to me have early logs which en.qi-hardwware.com/mmlog don't have :)
<xiangfu> kristianpaul: "/path" typo.
<kristianpaul> xiangfu: yeah :-)
<lars_> 'shell/ash.c:70:3: error: #error "Do not even bother, ash will not run on NOMMU machine"' :/
<lekernel> yeah stupid
<lekernel> and I'd even say never mind :)
<lekernel> so I guess the linux port is doing pretty well, now that you're trying to compile new apps?
<lars_> i finaly found time today to put everything together
<lars_> hm... of course it does not work on the real hw :/
<kristianpaul> :(
<lekernel> lars_: works in QEMU and not on real hw? what happens?
<lekernel> btw is the instruction cache properly flushed when dynamically loading code?
<lars_> lekernel: the kernel doesn't show any life signs
<lekernel> huh... it worked before
<lars_> i'm trying to bisect it
<lekernel> what happened?
<lars_> no idea
<lars_> i switched from .37 to .38 and added mwalles patches
<lars_> and it still works in qemu
<lekernel> weird
<lekernel> Fallenou: does RTEMS support M_EXT for mbufs?
<lekernel> because if it does, you should not need to copy memory in the ethernet driver
<Fallenou> dunno
<Fallenou> will check
<lekernel> there's also this cluster thing which might allow a copy-free driver, but I don't remember how it works
<Fallenou> lekernel: yes rtems does support M_EXT
<Fallenou> I will try to use it
<kristianpaul> copy-free driver :o
<lekernel> maybe the right thing to use is the "mbuf cluster"
<lekernel> it should support up to 2048 byte packets
<lekernel> m_pulldown(struct mbuf *m, int off, int len, int *offp)
<lekernel>              Ensure that the data in the mbuf chain starting at off and ending
<lekernel>              at off+len will be put in a continuous memory region.  len must
<lekernel>              be smaller or equal than MCLBYTES.
<lekernel> MCLBYTES == 2048
<lekernel> and MCLBYTES is the size of a mbuf "cluster" (whatever that means)
<Fallenou> hum hum will se maybe tomorrow
<lekernel> hasn't used mbufs since 2005
<Fallenou> i'm sick and my head is starting to explode
<Fallenou> will goto bed
<kristianpaul> looks what is a mbuf
<Fallenou> kristianpaul: a structure that contains ethernet packets, in bsd world
<Fallenou> equivalent of skbuff of linux
<Fallenou> to avoid too much copying
<kristianpaul> oh i see
<Fallenou> *gone*
<lekernel> ah, mbuf cluster is just a special case of M_EXT
<lekernel> The system also supplies a default type of external storage buffer called
<lekernel>      an mbuf cluster.  Mbuf clusters can be allocated and configured with the
<lekernel>      use of the MCLGET macro.
<lekernel> I don't think we should use the mbuf cluster
<lekernel> but use MEXTADD() and recycle the data buffers (with proper locking ofc to avoid problems like the random crashes we see now)
<lars_> blames mwalles patches. 2.6.38 without them works fine
<mwalle> hey :b
<mwalle> which patch?
<lars_> don't know yet
<lars_> i applied the whole series you sent some time ago
<mwalle> lars_: and the kernel doesnt print anything?
<lars_> nothing
<lars_> even with earlyprintk
<lars_> hm, now it works
<lekernel> btw, is 720p over VGA common?