<kristianpaul>
xiangfu: how long take your mm1 to load flicernoise?
<kristianpaul>
I'm not sure but with current resolution seems the jpg wallpaper add some delay for gui loading...
<xiangfu>
~13 secs
<xiangfu>
after press three button for reboot
<xiangfu>
kristianpaul: yes. depends on the wallpapers size.
<kristianpaul>
this is with last bios commits? as seems milkymist splah logo was disable at boot
<kristianpaul>
hmm
<xiangfu>
kristianpaul: no.
<kristianpaul>
k
<kristianpaul>
is it size of cpu usage at the when processing the jpg..?
<kristianpaul>
humm
<kristianpaul>
ignore 'at the'
<xiangfu>
kristianpaul: the wallpaper have to be png
<xiangfu>
kristianpaul: are you using a jpg wallpaper?
<kristianpaul>
ah sorry, no no
<xiangfu>
kristianpaul: I have test before if the png wallpaper size big. it needs more time to load.
<kristianpaul>
i just using xiangfu's image ;-)
<xiangfu>
kristianpaul: without any wallpaper it's faster.
<kristianpaul>
i see :-)
<kristianpaul>
yeah, i just noticed that today
<xiangfu>
I also using xiangfu's image :)
<wolfspraul>
xiangfu: boot time is very important, I suggest for your next image by default you leave the wallpaper out then
<wolfspraul>
it should boot into rendering automatically anyway, imo
<xiangfu>
wolfspraul: ok
<azonenberg>
Have you guys considered DVI output at all?
<azonenberg>
They added TMDS support in spartan-3a
<azonenberg>
i havent worked with the 6 but i assume it's there
<wolfspraul>
azonenberg: yes definitely lekernel thought about this, and it's doable afaik. One of the nearly infinite things that _could_ be done.
<wolfspraul>
he is also thinking about s-video and tv-out support (with a vga to tv-out adapter cable)
<wolfspraul>
so far there is only lekernel doing such kind of work thought, so it's all up to his prioritizations and overview over the complete project as to when it's done
<wolfspraul>
unless someone like you comes along and lends a helping hand :-)
<lekernel>
wolfspraul: btw, if we start rearranging the power supply components, maybe it's a good time to start thinking about making room for a HDMI connector
<lekernel>
(I don't know where Adam is planning to put those zeners and fuse ...)
<kristianpaul>
vga to HDMI? :-)
<lekernel>
no, direct HDMI
<wolfspraul>
lekernel: how big are those components? I didn't even ask Adam about size (or cost) yet, I just hope this is settled asap and we can move forward :-)
<lekernel>
it's just a HDMI connector and perhaps some ESD protection parts (0402 or the like)
<lekernel>
it goes straight to the fpga
<larsc>
this probably been discussed already, but why not displayport instead of HDMI?
<lekernel>
but let's not delay rc3 for that, especially since it won't be supported in the fpga design anytime soon
<lekernel>
hdmi is used more often
<kristianpaul>
i agree with larsc idea, actually wpwrak also pointed a interesting feature of adding a small lcd display to the box :-)
<larsc>
my new laptop has a dual-mode displayport connetor which allows connecting both displayport and HDMI cables.
<larsc>
imo that would be the best option for the milkymist
<wolfspraul>
lekernel: now I meant the size of the fuse and zeners
<wolfspraul>
I hope this is all small and won't cause layout issues
<lekernel>
larsc: isn't supporting those two standards a significant technical mess (USB-like)?
<azonenberg>
havent actually implemented either but was reading up on them a while ago
<lekernel>
isn't HDMI just digital DVI with the possibility to fit additional packetized data (audio streams, DRM crap, ...) into the padding bytes?
<azonenberg>
lekernel: First, iirc DVI supports HDCP as well
<azonenberg>
Though i've never considered implementing it for obvs reasons :P
<azonenberg>
But yeah, both are TMDS at the physical layer
<azonenberg>
Layer 2 is either raw video data (DVI) or interleaved frames of video and other data (HDMI)
<azonenberg>
lekernel: Lol, you and me are the only fans of sputter deposition on fb
<azonenberg>
Something tells me it's not the most popular subject
<lekernel>
hmm... I thought there were HDMI->DVI passive adapter and the other way around
<lekernel>
maybe HDMI displays can also accept raw video data
<azonenberg>
lekernel: Thats possible
<azonenberg>
It's also possible that the HDMI headers are in the blanking interval
<azonenberg>
So that you can transparently feed them to DVI
<azonenberg>
But going the other way around almost certainly involves adding packet headers
<azonenberg>
I'm not sure, like i said i havent actually implemented either yet
<azonenberg>
I do know they are compatible at the physical layer, both are R/G/B encoded as TMDS plus a clock at the pixel frequency (i.e. 1/10 the bit rate)
<lekernel>
anyone has experience with the elphel theora encoder?
<lekernel>
mclk0,    // system clock, phase 0 (@negedge) clk,      // this module clock (trying negedge - may change to reduce ground bounce
<lekernel>
wtf ...
<azonenberg>
?
<azonenberg>
is he suspecting ground bounce inside the fpga?
<azonenberg>
Sounds like bad power filtering to me
<lekernel>
yeah, same here
<azonenberg>
not enough vccint bypass caps etc
<azonenberg>
or enough but too big/too small/too fast/too slow
<lekernel>
and I can't see any reason for an hardware computation accelerator in FPGA to mess up with the clocks instead of being a pure synchronous design
<azonenberg>
Yeah
<azonenberg>
i'm sure you know more about fpga stuff than i do (just getting started) but that much seems clear
<lekernel>
also I don't see any test bench and I don't really believe that such code can be debugged by just downloading to FPGA ... maybe I'm looking in the wrong place