<GitHub86>
[milkymist/symtab] libfpvm/x86-linux/Makefile: support silent builds as well - Werner Almesberger
<GitHub36>
[flickernoise] wpwrak pushed 1 new commit to symtab: http://git.io/elOy7g
<GitHub36>
[flickernoise/symtab] ptest/Makefile: added "silent" copy operation - Werner Almesberger
cladamw [cladamw!~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
devn_ [devn_!~devn@rot13.pbqr.org] has joined #milkymist
cladamwa [cladamwa!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
sh[4]rm4 [sh[4]rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@cl-498.udi-01.br.sixxs.net] has joined #milkymist
kristianpaul [kristianpaul!~kristianp@unaffiliated/kristianpaul] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
frdminc_ [frdminc_!47b8b83e@gateway/web/freenode/ip.71.184.184.62] has joined #milkymist
<frdminc_>
xiangfu: hi, wpwrak tells me you are the DMX expert
<xiangfu>
frdminc_, not expert. I have try some DMX fixtures with Milkymist One :)
<frdminc_>
xiangfu: Have you gotten multiple DMX lights to do different things at the same time with any of the current patches?
<frdminc_>
(I have 3 lights each of which has 4 addresses - R G B and on/off/brightness/strobe
<xiangfu>
frdminc_, Hi there is one patch that support DMX out: Rozzor & Aderrasi - Canon (DMX out).fnp
<xiangfu>
but there are only dmx1/2/3/4 mean four channels.
<xiangfu>
frdminc_, now Milkymist one support 8 output channels.
<frdminc_>
xiangfu: ah okay so I'm not missing anything. So it would be possible to write a patch that controlled 2 lights seperately, but not 3.
<frdminc_>
xiangfu: although I'm a bit confused as with the "DMX Desk" it looks like you can control up to 256 channels manually.
<xiangfu>
(controlled 2 lights seperately) totally ok.
<xiangfu>
DMX Desk. yes. we can control all 512(not only 256 :) channels manually,
<xiangfu>
M1 can act like a DMX device or DMX controller.
<xiangfu>
under the DMX settings: there two columns , idmx1/2/3/4/5/6/7/8 and dmx1/2/3/4/5/6/7/8
<xiangfu>
idmx* mean dmx input.
<xiangfu>
dmx* mean dmx output.
<frdminc_>
xiangfu: so 8 channels programmatically or 512 channels manually, is that right?
<xiangfu>
yes. that is correct.
<frdminc_>
xiangfu: is the 8 channels programmatically a hardware or software limitation?
<xiangfu>
software limitation.
<xiangfu>
at begin we support 4 channels. now we have 8. will have more in future.
<frdminc_>
xiangfu: thanks a lot. So it looks like I want to work on something pretty simple getting an effect to use all of the available 8 DMX outputs might be a simpler thing. But for party tomorrow will just set all 3 lights to use the same DMX addresses :)
<xiangfu>
yes. 3 lights use the same DMX addresses.
<xiangfu>
please share your patches with us. we need more DMX patches. for now there are only one.
<xiangfu>
I want finish one dmx patch. I am slow. still not write it. :(
<xiangfu>
frdminc_, when you switch patches. from DMX patch to a non-dmx patch. all dmx variables will set as 0.
<xiangfu>
mostly mean the light will off.
<frdminc_>
xiangfu: actually I think I found 1-2 other patches that did some DMX stuff.
<xiangfu>
frdminc_, if you already prepared some patches. a word around for now is add a default dmx* value in all your non-dmx patches.
<xiangfu>
frdminc_, great where is them?
<frdminc_>
xiangfu: I'm far away from actually modifying or writing anything
<frdminc_>
xiangfu: They were just included with the set of patches it shipped with. They had DMX in the name somewhere. I'm not in the same place as the M1 at the moment so can't take a look right now.
<xiangfu>
oh. correct. there are two patches that have dmx output. sorry.
cjdavis1 [cjdavis1!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
<xiangfu>
frdminc_, in this patch 'Rozzor & Aderrasi - Canon (DMX out).fnp' I think you can just map dmx2/3/4 to R G B. then it will work out of box.
<frdminc_>
xiangfu: Need to sleep now, 1am my time... but thanks a lot... I'll need to look at "MIlkymist One & DMX fixtures" closer later today, looks like you got Drawing Board to do something somehow :)
<xiangfu>
frdminc_, and map the dmx1 to ' on/off/brightness/strobe' . set it to ON. for in that patch is set it '1' mean '255'
<xiangfu>
frdminc_, sure. goodnight.
<frdminc_>
xiangfu: yeah that one works fine, want to change dmx1 to have more variation oh as my lights start to strobe at a certain dmx1 level.
<xiangfu>
frdminc_, have a nice party tomorrow. :)
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
<GitHub79>
[scripts] xiangfu pushed 2 new commits to master: http://git.io/GfBQlA
<GitHub79>
[scripts/master] rtems is changed to git. cvs not working anymore - Xiangfu Liu
<GitHub79>
[scripts/master] compile-milkymist-firmware.sh: no needs handle cvs rtems - Xiangfu Liu
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
rejon [rejon!~rejon@203.81.22.139] has joined #milkymist
<xiangfu>
wpwrak, just sent out the audio indicate patches. :)
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
<wpwrak>
xiangfu: do the bars grow from the top ? if yes, can you make them grow from the bottom ?
<xiangfu>
wpwrak, yes. it grow from the top. I don't know how to make it from bottom.
<wpwrak>
for the levels, i was thinking of showing line in and mic levels separately. so that one can also see how they relate to each other. that may need extra processing.
<xiangfu>
the MTK only have two option.: 'horizontal' or 'vertical'
<wpwrak>
but let's see how a combined meter does. maybe it's already good enough
<xiangfu>
wpwrak, ' line in and mic levels separately' have no idea how to do this. but when I mute the Line-in. it all about MIC. when I mute Mic it's all about Line-in. but don't know how to separate them :(
<xiangfu>
wpwrak, you mean we have 9 bars. 3 for Line-in, 3 for Mic. 3 for combined audio.
<xiangfu>
?
<wpwrak>
ah, i was thinking of just two, one for mic and one for line. that would be a more traditional arrangement
<wpwrak>
but perhaps what you've done works well in practice, too. it would have the advantage of using things we already have, so we don't need to make the poor little lm32 work too hard :)
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
<wpwrak>
/opt/milkymist/mtk.git/doc/mtk-users-guide.txt line 518 ;-)
<xiangfu>
read three more lines is always good. :) I only read the 517 line. :(
<xiangfu>
will try that.
<xiangfu>
thanks wpwrak
<wpwrak>
and i think it would look better if the indicators were on the right side not on the left side
<wpwrak>
that's for the usual left-to-right reading direction: first we set the input levels (left), then we show the resulting values (right)
<xiangfu>
I like the left. because the left part is READ-ONLY. :)
<wpwrak>
also, do the ranges make sense ? i see that you have 0-300 and 0-600, but you scale *100
<xiangfu>
in the commit log there are some values of those three.
<wpwrak>
oh, i see. not just 0.0-1.0
<xiangfu>
I just manually set them to 0-300, 0-600. I don't what is the MAX value of those three.
<xiangfu>
have to offline. back in about ~2 hours.
<wpwrak>
let's see what the flickernoise manual says ...
<wpwrak>
hmm, 1.3 is already "load". so perhaps not more than 0.0-1.5 or 0.0-2.0
<wpwrak>
maybe we need to rescale things elsewhere too
lekernel [lekernel!~lekernel@f052069021.adsl.alicedsl.de] has joined #milkymist
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #milkymist
cladamw [cladamw!~Adam@host-222.80-43-115.dynamic.totalbb.net.tw] has joined #milkymist
* xiangfu
is back :)
wolfspraul [wolfspraul!~wolfsprau@p5B0AA732.dip.t-dialin.net] has joined #milkymist
<cladamw>
lekernel, wpwrak, wolfspraul , ( m1 h/w version naming ): M1v4.x ? or any idea ?
<wolfspraul>
ah
<wolfspraul>
good point
<wolfspraul>
please make sure that the product name is always "Milkymist One"
<wolfspraul>
that's important
<wolfspraul>
then we have a datecode
<wolfspraul>
but the problem is, if we only have product name + datecode, it's hard for internal communication
<cladamw>
Althougt wiki on qi or milkymist wiki, they are something named rc2 already. but now it's time to change it.
<wolfspraul>
like we are working towards what now?
<wolfspraul>
I think we keep it simple, and just can say "rev 4" or "R4" instead of RC4 ?
<wolfspraul>
rc = release 'candidate'
<wolfspraul>
some people may get hung up on that
<wolfspraul>
how about just remove the 'C'
<wolfspraul>
R4
<cladamw>
with datacode is surely markable to trace even like while not final but still discussing or reviewing.
<wolfspraul>
well datecode for sure, datecode is great
<wolfspraul>
yyyymmdd
<wolfspraul>
I suggest "R4" instead of RC4
<lekernel>
the FN "about" dialog already displays a "revision" which is the bare encoded value on the PCB, i.e. n-1 for RCn
<cladamw>
some kinds of like xiangfu's release version with datacode
<wolfspraul>
we need a name for releases we are working towards, to facilitate internal communication
<lekernel>
so it starts at 0 for our first 6 prototype series
<wolfspraul>
so we can talk about rc2, rc3, and we know what we mean
<lekernel>
we can call RC4 R3
<wolfspraul>
if the 'candidate' thing makes some people unsafe, let's remove the C
<wolfspraul>
no '3' please
<wolfspraul>
R4
<lekernel>
by the way - is there support for ethernet in the linux port?
<cladamw>
current "about" is marked => Board: M1 (PCB rev. 2) for original rc3
<cladamw>
that's being the final released version, for intenal reviewing control we can add like wolfspraul said that usually we want to name schematic communications.
<xiangfu>
also I think we should remove PCB.
<cladamw>
so M1 (PCB rev. 3.20120113) ? for internal discussion for better?
<cladamw>
I'd like to give it a new naming code. :-)
<wolfspraul>
the purpose of these things is to facilitate internal communication
<wolfspraul>
for focus
<lekernel>
wolfspraul: ok, let's do like that
<wolfspraul>
yes, from now on we remove the 'C'
<wolfspraul>
that's all
<wolfspraul>
and the software needs to write it like that in the GUI too
<wolfspraul>
maybe a +1 is needed somewhere, that should be possible :-)
<cladamw>
so if final then we call "M1 R4", right?
<wolfspraul>
we are working on R4 now, yes
<wolfspraul>
and when you make the pcb, it will also get a datecode, but that's only on the silkscreen
<wolfspraul>
meanwhile the GUI will say "Milkymist One (R4)" or any other pretty printing like "revision 4" or "hardware version 4" or whatever
<wolfspraul>
but that's just the GUI
<cladamw>
so the "about" will be "PCB rev.3" or just "M1 R4"?
<wolfspraul>
for internal communication like here it's R4
<cladamw>
mmm
<wolfspraul>
the about should be easily understood, so it should definitely have a '4'
<wolfspraul>
other than that it's about making people understand, not us, but users looking at this about dialog
<wolfspraul>
so I suggest "Milkymist One (R4)" or "Milkymist One (rev 4)" or "Milkymist One (revision 4)"
<wolfspraul>
probably I would pick the first one since it's shortest
<cladamw>
alright, me => also pick first = "Milkymist One (R4)"
<cladamw>
any else vote?
<cladamw>
seems done, tks !
<xiangfu>
Milkymist One (R4) +1 :)
<wolfspraul>
the "+1" is the vote, not a proposal for a string extension :-)
<wolfspraul>
just saying
<wolfspraul>
R4+1=R5 ?
<wolfspraul>
:-)
<cladamw>
;-O
<wolfspraul>
unless there are complaints, I will start referring to earlier releases with just "r" as well
<wolfspraul>
so I will not say "rc2", I will say "R2"
<wolfspraul>
I think this should still be clear, and consistent with our naming going forward
<wolfspraul>
so the one we work on now is R4
<wolfspraul>
whatever we don't want to get into R4 is pushed out to R5. etc.
<wolfspraul>
just R from now on...
<wolfspraul>
hey 'R' can also stand for 'run'
<wolfspraul>
run, revision, release
<cladamw>
okay ;-)
<wolfspraul>
onto R4!!!
<wolfspraul>
:-)
<cladamw>
wpwrak, about latest emails on: "consider scrapping the AUX* and VIDEO* input paths. That's R2
<cladamw>
through R9, and C4 through C8. Maybe keep the DC block footprints
<cladamw>
(C4 through C8), so that one could solder something external
<cladamw>
(just in case)."
<wolfspraul>
ah there's a collision. R4 could be mistaken for a resistor.
<wolfspraul>
but I think from the context it will always be clear whether the resistor or the board revision is meant
<xiangfu>
wpwrak, another 3 patches send out.
<wolfspraul>
so I still go with R4 (for the board revision)
<cladamw>
for schematic compiler problems, I'll still put another real "part" on that one terminal of those DC block footprints. so the part i currently used a "TPxx" instead.
<wolfspraul>
if anybody feels bad about that naming collision, the board revision could be BR
<wolfspraul>
but I think that's ugly
<wolfspraul>
R4
<xiangfu>
lekernel, from Lars email: So VGA, Keyboard and network will work
<wolfspraul>
the context will always clarify between resistor and board
<xiangfu>
lekernel, but I am not sure the new minimac will. I think the kernel is old.
<cladamw>
wolfspraul, BR? "Board Revision"?
<lekernel>
R. period
<wolfspraul>
R.4 ?
<wolfspraul>
lekernel: you mean that?
<lekernel>
R4
<wolfspraul>
ah :-)
<wolfspraul>
yes sure, R4
<wolfspraul>
context makes it clear
<wolfspraul>
lekernel: I had another question/idea that just popped to my mind
<wolfspraul>
many notebooks still have VGA output
<wolfspraul>
i.e. analog video
<wolfspraul>
is there a way to feed a vga output into m1 ?
<wolfspraul>
maybe with the help of some cable we could build?
<lekernel>
with the new adv7181c maybe
<wolfspraul>
or is there no way to make the ADC convert that back?
<lekernel>
up to 1024x768
<lekernel>
this will need some rework of the FPGA and software though
<wolfspraul>
it might add value to some people
<wolfspraul>
yeah no rush or anything, I just realized
<wolfspraul>
with the adv7181b definitely not?
<lekernel>
definitely not
<wolfspraul>
ok
<wolfspraul>
another reason why to upgrade to C - great
<lekernel>
let me check for the -C ...
<wolfspraul>
thanks!
<lekernel>
yes, that would work (with the proper FPGA and software support, which isn't close to existing right now)
<lekernel>
even 1080i
<wolfspraul>
with what cable though?
<lekernel>
and 720p
<lekernel>
RGB VGA pins to RCA
<lekernel>
and sync-on-green
<wolfspraul>
a standard cable that goes from 15-pin vga to 3*rca? or 1*rca ?
<lekernel>
3*RCA
<wolfspraul>
do such cables exist? or we would need to build one?
<wolfspraul>
well a lot of work in between, but good stuff
<wolfspraul>
first update to adv7181c - moving in R4
<wolfspraul>
then a lot of work in fpga and software
<wolfspraul>
then a cable, easily sourcable or custom-made
<wolfspraul>
but good to know that it's possible
<xiangfu>
lekernel, I should require both RESOURCE_AUDIO, and RESOURCE_SAMPLER?
<lekernel>
xiangfu: exact same as the variable monitor, since you are spawning the same task
<lekernel>
meh I doubt the minimac driver really works. if it does, it's with bugs.
<xiangfu>
ok got it.
<lekernel>
seems it's still for the old core
<lekernel>
anyway - it's better than nothing, it's a decent starting point for a driver for the new core
<xiangfu>
ok. now it's better.
<xiangfu>
lekernel, I think it time to do a push. :)
<xiangfu>
lekernel, the last patch I didn't add the resmgr_release under 'OK' event. already fixed in local.
<lekernel>
xiangfu: don't use the window title in resmgr_acquire, just one word
<lekernel>
xiangfu: otherwise be consistent with all other places where resmgr_acquire is called
<lekernel>
xiangfu: also, I think LoadDisplay can take floating point values directly (but check)
<lekernel>
other than these two points it's fine
<xiangfu>
about LoadDisplay values: I would like keep them for now. I think when we dig into more about the values. I will create another patch. :)
<xiangfu>
I would like check all resmgr_acquire. make them all using windows titles. that make people easy understand.
<lekernel>
xiangfu: it only has to do with code simplicity. I think the LoadDisplay already has a "scaler" built-in, no need to duplicate it
<lekernel>
xiangfu: so you'd give it the range you expect for bass/mid/treb, and then feed the values to it directly
<xiangfu>
just checked. after the changed Variable monitor. all resmgr_acq is using windows titles. except 'rendering' mode.
<xiangfu>
let me check the LoadDisplay now.
<xiangfu>
I think the 'LoadDisplay' is better then 'Scale' :)
<xiangfu>
sorry. just ignore my last message.
<xiangfu>
test the float value now...
<xiangfu>
yes. float works fine.
<wpwrak>
(R4) can we change R3 in R4 to 10 kOhm ? ;-)
<wpwrak>
but i guess we could just call it "r4". reduces the difference to rc4 by one bit :)
<wpwrak>
(resistor) ah, i see that you already noticed :)
<xiangfu>
wpwrak, I will do a git push. there are two small patches not send to mailing list. 1. using float value directly. 2. add the resmgr_release in both OK and Cancel event.
<GitHub121>
[flickernoise] xiangfu pushed 8 new commits to master: http://git.io/qkmxYg
<GitHub121>
[flickernoise/master] gui/audio add Bass Mid Treb indication bar - Xiangfu Liu
<GitHub121>
[flickernoise/master] gui/audio: connect the indicate bar to bass,mid,treb - Xiangfu Liu
<GitHub121>
[flickernoise/master] gui/audio: make the bar from bottom to top - Xiangfu Liu
<wpwrak>
lekernel: do the ranges of the values look weird to you, too ? or is this a documentation problem ?
<lekernel>
both I think :-)
<lekernel>
what it does is FIR-filter the incoming audio into three bands, then take the sum of squares of each output
<lekernel>
taking the square root of that would probably help
<wpwrak>
what does milkdrop do ? and do they document their real range ?
<lekernel>
something similar except it does a more expensive Fourier transform
<wpwrak>
sqrt would help against outliers, yup
<wpwrak>
hmm, fft is a bit suckish indeed
<wpwrak>
unless there's some fun way to do this in the fpga :)
<lekernel>
btw the main reason why we do not have sqrt atm is that we didn't have libm or anything when I first wrote that code (in late 2008/early 2009)
<wpwrak>
heh :)
<lekernel>
wpwrak: yeah, but 90% of geeks confuse "signal processing" and "FFT" :-)
<Scopeuk>
confuse or get the sub set wrong?
<lekernel>
"my winmodem does a FFT" etc.
<wpwrak>
that's probably the same people who'd say the Windows(tm) on your M1 looks funny :)
<wolfspraul>
wpwrak: in those cases you would want to say "can we change R3 in rev4 to xxx"
<wolfspraul>
but in 99% of cases R4 should be clear from context
<wolfspraul>
I looked at some usb board connectors I found here, they are all 5-pin, 100 mil headers
<wpwrak>
the most common is 5x2, for two ports. two pins have no signal and one of them is removed, for keying
<wolfspraul>
one is D-, one is D+, one GND, one power
<wpwrak>
yup. just 1:1 full-size usb
<wolfspraul>
in my cables I think the gnd is going to 2 pins
<wolfspraul>
the colors on the board side are red-white-green-black-black
<wolfspraul>
so we want a 4*1 or 5*1 header?
<wpwrak>
5x2, keyed ? :)
<wolfspraul>
seems 5*1 (or rather 5*2)
<wpwrak>
a 4x1 plug or a 5x1 plug should fit on 5x2 keyed as well.
<wolfspraul>
yes
<wolfspraul>
I just want to make sure we don't screw this up, it's easier than anyone would think
<wolfspraul>
seems 5*2 header, exact pin assignment should be standardized then (to be confirmed)
<wolfspraul>
lekernel: yes that's a good one, thanks! [migen conversion task]
<wolfspraul>
I don't expect to find anybody, and I don't expect to be up to the task myself, but it gives us a good story to go around with, something valuable and worthwhile we can invite people to wholeheartedly
wolfspraul [wolfspraul!~wolfsprau@p5B0AA732.dip.t-dialin.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AA732.dip.t-dialin.net] has joined #milkymist
<lekernel>
"NOTWITHSTANDING ANYTHING ELSE WILL CADENCE'S TOTAL AGGREGATE LIABILITY FOR ANY CLAIM, SUIT, PROCEEDING OR OTHERWISE, RELATING IN ANYWAY TO THE DFI SPECIFICATION EXCEED $1.00USD"
<lekernel>
lol
<wpwrak>
there'll probably be a multi-billion lawsuit over that clause alone :)
<lekernel>
for once, there doesn't seem to be anything evil in that, is there?
<wpwrak>
clause 6 seems a little odd
<wpwrak>
clause 3 also leaves it open whether there are any patent traps. e.g., the whole thing would be compatible with RAND/FRAND patents
<wpwrak>
(held by cadence & associates)
<wpwrak>
clause 6 could perhaps be construed as including the licensee's own implementations
<lekernel>
"and provided by Licensee for the purpose of further developing, modifying or changing the DFI Specification."
<wpwrak>
no, that one has "as a result of the use of the Communications in developing ..."
<wpwrak>
whatever that means
<wpwrak>
i.e., if you implement the DFI spec, do you "develop" it ?
<wpwrak>
but it's probably not an issue. you could only be hassled over that by your contract partner, which seems to be either just candence or maybe the whole gang of participants. but not just any random rogue troll
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wpwrak>
and since there are no disreputable companies among the participants, e.g., apple, kodak, and such, it's probably okay
<wpwrak>
that clause 3 leaves the door open for (F)RAND is more problematic. at least an assurance that the participants hold no patents affecting DFI (unlikely) or o do not intend to enforce those they hold against licensees would be welcome
<wpwrak>
this is a big problem with standards and organizations that accept flat out patented stuff without any waivers
<wpwrak>
e.g., don't touch anything from ETSI that's not at least ~18 years old. like good wine, technology gets more palatable with age :)
<lekernel>
The DFI specification supports a 1:2 or 1:4 MC to PHY frequency ratio,
<lekernel>
meh
<lekernel>
so if you have DDR3 at 800MHz (1600Mbps/pin) you must run the memory controller at 200MHz at least
<lekernel>
that's not easy in those slow and crappy FPGAs
<wpwrak>
if it was easy, where would be the fun ? :)
<lekernel>
well... in fact it seems straightforward to "extend" DFI to support abitrary clock multipliers anyway
wolfspraul [wolfspraul!~wolfsprau@p5B0AA732.dip.t-dialin.net] has joined #milkymist
<lekernel>
"for frequency ratio systems, the control signal interface, the write data interface and the read data enable signal will all be suffixed with a â_pNâ where N is the
<lekernel>
phase number."
<lekernel>
phew... lack of structured signals in *HDL kicks again
<wpwrak>
;-)
<wpwrak>
be happy that you can name them :) "connect signal 124 to 743" :)
wolfspraul [wolfspraul!~wolfsprau@p5B0AA732.dip.t-dialin.net] has joined #milkymist
<lekernel>
i'll rather write a Migen DFI wrapper that takes care of this stuff automatically :)
<lekernel>
then I have a Python object for each phase number
<wolfspraul>
the specification from ddr-phy.org is free and open for Milkymist to use?
<lekernel>
there's even a right to "distribute and copy" the document
<wolfspraul>
nice
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
<lekernel>
meh, seems this Spartan6 DDR PHY allows only one DRAM command per DFI clock (even though it multiplies the clock by 2)
<lekernel>
and it definitely makes sense to send e.g. a read and a precharge command to different DRAM banks in the same DFI cycle
Technicus [Technicus!~Technicus@DSLPool-net208-2.wctc.net] has joined #milkymist
<lekernel>
WTF? this thing appears to send all commands to the DRAM *twice*
<lekernel>
ha! no, they inhibit the chip select signal on every second cycle
<lekernel>
that's lousy
<kristianpaul>
workaround? :)
lekernel_ [lekernel_!~lekernel@g225036034.adsl.alicedsl.de] has joined #milkymist
<lekernel_>
ask kristianpaul to write a better PHY
<kristianpaul>
lol, i dint complain about it ;)
r33p [r33p!~rep@bon31-2-89-85-157-97.dsl.sta.abo.bbox.fr] has joined #milkymist
frdminc [frdminc!47c0a200@gateway/web/freenode/ip.71.192.162.0] has joined #milkymist
<frdminc>
It turns out that the (non-bluetooth, propriatary USB dongle) keyboard I got to control the M1 remotely doesn't work with the M1. Has anyone gotten a different kind of remote keyboard/mouse working - eg something like x2x or x2vnc?
<wolfspraul>
frdminc: hmm, sorry to hear that. what model did you get?
<wolfspraul>
Werner is using a Rii Remote (same tech as yours) successfully, and we are even thinking about including such a type of keyboard/pad in the box in the future.
<wolfspraul>
wpwrak: do you think you could have fixed keyboard related bugs after our last 2011-11-29 release?
<frdminc>
logitech k270 kb and anywhere mouse. They use the same USB dongle. On Linux it shows up as a USB HID; I'll get the exact messages if you'd like. I'm trying an older wireless kb/dongle atrm.
<wolfspraul>
yes please do so
<wolfspraul>
in the past finding a keyboard that would work was a hit and miss game, but slowly we are fixing bug by bug
<wpwrak>
rii should be okay around that time. there may be more fixes after nov 29.
<wpwrak>
but mose likely it's a HID report format problem
<wolfspraul>
can he upload something that would help us fix it?
<wpwrak>
just a format we don't recognize with the overly primitive parser we have now
<frdminc>
wolfspraul: BTW Star Simpson is here, we were talking about M1 and of course it turns out she's met all you guys in CN :-)
<wolfspraul>
ah great, say hello! (although I didn't meet her in person)
<frdminc>
I'm just getting one of those USB Ethernet externder things for the future.
<frdminc>
Ah yeah I think she mentioned rejon, thought she mentioned you but guess not.
<frdminc>
Sweet the Adesso Inc WKB-4000US wireless keyboard does work... can just return all the logitech stuff :)
<wolfspraul>
they should all work, maybe in a few months :-)
<wolfspraul>
if you have a little time, please update the wiki
<wolfspraul>
if not, also ok
<wolfspraul>
we are on it
<frdminc>
hmm may have spoke too soon... stopped working.
<frdminc>
II'm planning on spending quality time with the wiki after the party
<frdminc>
If you un/replug it starts working again... looks like maybe the sleep state is "confusing" the M1.
<wolfspraul>
possible :-)
<wolfspraul>
wherever you look - bugs and missing features
<wolfspraul>
a developer's dream
<wolfspraul>
:-)
<frdminc>
:-)
<wolfspraul>
"if you don't find a bug or problem on your first day of using the product, you have a special right to return for a full refund and free beer..."
<wpwrak>
some keyboards go to suspend if you don't use them for a short while
Gurty [Gurty!~princess@mtg95-7-78-233-26-36.fbx.proxad.net] has joined #milkymist
<wpwrak>
typically there's a button that wakes them up. e.g., on the rii it's shift
<wpwrak>
we don't implement usb suspend but ... that shouldn't bother the device
<wpwrak>
could be that something else trips it, though
<wolfspraul>
if frdminc really sees a sleep-related bug, that's the first time I hear about it wrt keyboards and quite important I think
<wolfspraul>
hoepfully after your party we have some time to get dumps or logs from those devices
<wolfspraul>
can you find some good developers who might be interested in joining Milkymist? even explaining and talking about the project may attract some...
<wpwrak>
i hope to kill a lot of those remaining usb problems in the next 1-2 weeks. we still have a few unsolved issues. e.g., 1) only a few hardcoded report formats; 2) no CRC; 3) for some reason, lots of RX timeouts (which may be false alarms, but then we should at least suppress the alarm)
<wolfspraul>
dozens or more people could easily hack on m1 without any fear of overlap or redundancy :-)
<wpwrak>
so it's fragile. but works surprisingly well ;-))
<frdminc>
hmmm keyboard has been working fine for a while now, and itself has issues, so perhaps if treated delicatly / not moved it'll work for the party.
<wolfspraul>
good luck!
<wpwrak>
maybe try to find a 2nd one and bring it too, in case the other quicks
<wpwrak>
s/quicks/quits/
<frdminc>
wpwrak: oh I'm doing a permanent installation in a space; so plenty of wired KBs avail if needed :)
* frdminc
will take pics when done
<lekernel_>
isn't USB suspend only activated at the host's request?
<lekernel_>
did they ALSO felt the need, that suspend mode can be activated by the device?
<lekernel_>
is Rube Goldberg the chair of the USB design committee?
<wpwrak>
i've only heard of host-activated
<lekernel_>
we should have used PS/2 instead. much much easier to get to work with all devices :p
<wpwrak>
and no, i don't think it was mr. goldberg. i think usb was kafka's project for a phd in engineering :)
<wpwrak>
ps/2. bah ! use the full-sized DIN connector of the original IBM PC:)
<wpwrak>
a "sleep issue" may also come from the usb device doing its own suspending. e.g., the rii suspends after only a few seconds. it'll wake up if you press shift or power-cycle it (it has a little switch on the side to cut battery power)
<wpwrak>
if you don't realize what's happening, you may think it is malfunctioning
<wpwrak>
i guess each generation must have its algol 68 :)
<wpwrak>
geeks breed slowly, so the time between generations (algol 68, 1968 vs usb, 1995) is about right. expect the next complexity explosion around 2020-2025
<wpwrak>
lekernel_: i think you should be around the right age for chairing a design standardization committee around that time :)
<wolfspraul>
hmm, my RC2 froze again in rendering, I think I can reproduce it after about a few hours at most right now
<wolfspraul>
since we never specifically tracked down the root cause of the freezes, I am wondering whether we should we worried going forward that they might reappear?
<wolfspraul>
I don't remember any report of RC3 freezing, but I do feel a little uneasy about it :-)
<wolfspraul>
to worry or not to worry?
<wpwrak>
if it's just a lone rc2, perhaps not :)
<wpwrak>
my rc3 has been rendering pretty much endlessly without freeze
<lekernel_>
same here (both R2/R3 ...)
<wpwrak>
of course, there could be device variations or the different power supply could have an effect
<wolfspraul>
it's definitely not a lone rc2, I remember several reports of rc2 freezing
<wpwrak>
heh :)
<wolfspraul>
I'm not overly worried right now, just as we dig in and fix and polish everywhere, the freezes I am seeing are a constant reminder for me that that issue seemingly went away in RC3 without any specific action against it taken
<wpwrak>
well, you can go though the changes from rc2 to rc3, see if anytbing looks suspicious ...
<wolfspraul>
yes exactly, I don't think so :-)
<lekernel_>
wolfspraul: are the ferrite beads removed?
<wolfspraul>
I mean there was a lot, could be anything
<wolfspraul>
lekernel_: no idea
<wpwrak>
which software version do you have now ?
<lekernel_>
wolfspraul: well, look at your board
<wolfspraul>
I could send it back to adam for checks & service ;-)
<wpwrak>
hehe, a lot + no idea sounds like a good start for debugging ;-)))
<wolfspraul>
wait need to open the case...
<lekernel_>
he, you can tell if a ferrite bead is there or not, can't you?
<lekernel_>
no need for Adam's intervention I hope
<kristianpaul>
mt rc2 never froze rendering
<kristianpaul>
s/mt/my
<wolfspraul>
I cannot - where do I need to look?
<frdminc>
sweet, everything is working except I underestimated how hard the UI would be to use in 640x480 in a massively non-right-angled trapizoid...
<wolfspraul>
I take a pic :-)
<lekernel_>
frdminc: as far as the UI is concerned you can switch to 1024x768
<lekernel_>
wolfspraul: L19 close to the video input and L3 close to J3
<lekernel_>
wolfspraul: you should have molten solder blobs in both places, not actual components
<frdminc>
lekernel_: it's running to a piece-of-shit unfocusable projector via a vga to s-video converter that needs 640x480. VNC would be really useful right now. The option now is, what, send OSC commands?
<kristianpaul>
yeah i had those L* fixes
<wpwrak>
or maybe actual components drowned in solder
<frdminc>
(option for remote control via ethernet)
<wolfspraul>
hmm. I could have sworn I applied L3/L19 at some point, but L19 is still there :-)
<wolfspraul>
then probably L3 as well, can't find it right now, one sec
<wpwrak>
frdminc: how many hours do you have left ? :)
<wpwrak>
frdminc: there's also the IR remote control. not sure what it can do, though. (haven't tried mine yet)
<lekernel_>
wolfspraul: problems related to those beads did crash my M1
<wpwrak>
lekernel_: did it also crash when just running ? or only when connecting things ?
<wolfspraul>
L3 also still there, yes
<frdminc>
wpwrak: party o'clock is 10pm (+4h). For now I'm going to grab a IPKVM switch I have hanging around and set up a performance / IR / etc. Later it looks like I can leave the IPKVM there and get a signal splitter for like $25.
<wolfspraul>
yes, I am very careful with the connectors, but not sure whether L3/L19 can also freeze the board without being touched (which is my case)
<wpwrak>
wolfspraul: (L3, L19) you and jon may want to visit adam :) (or has jon his fixed now ?)
<wolfspraul>
I don't know, I try to get old boards fixed whenever possible
<lekernel_>
wolfspraul: time to use your soldering iron? :)
<wolfspraul>
but it's a lot of work, I guess I never cared for my own board enough!!! ;-)
<kristianpaul>
for not fixing L* seems not ;)
<wolfspraul>
yes I should try, that's really easy
<wpwrak>
frdminc: btw, why do you have to go to the GUI during performance ? the idea is generally that you shouldn't need that
<wolfspraul>
lekernel_: do you think L3/L19 can also be responsible for freezes when m1 is untouched, just running?
<lekernel_>
L19 may give some trouble if you have a weak soldering iron, because the ground plane sucks the heat
<lekernel_>
maybe, let's find out
<wpwrak>
frdminc: cute :)
<frdminc>
wpwrak: yeah I get that, but for this one I was going to be learning, and anyway I'll want to interact with the M1 in-place without having to move it all the time, and for that it needs to be usable in its current location of about 10'; off the ground and 15' from any wall.
<lekernel_>
frdminc: you want to use the GUI live?
* frdminc
contemplates going to a local store to get that cable...
<frdminc>
lekernel_: yeah, that's the general idea, at least until I get more of a clue. And also be able to use the GUI without moving the M1 from its installed location all the time during non-performance.
<lekernel_>
ah, that's also why you want wireless keyboards and such
<wpwrak>
or a rather long USB cable rather stylishly hanging from the ceiling into the middle of the dance floor :)
<wolfspraul>
I'm looking into them now, if I can find something cheap and well working, maybe we kick the silicone keyboard and remote control out in favor of one of them
<wolfspraul>
but one by oen
<wpwrak>
i wonder when we'll have the first case of wireless M1-jacking :)
<lekernel_>
I wonder if long USB cables might unearth some more timing related bugs in the softusb design
<wpwrak>
lekernel_: just wait for hubs :)
<roh>
*eg*
<wpwrak>
in any case, there are still known issues with low-level timing. at least the stack complains bitterly and quite a lot. just happens to work. need to analyze that stuff ...
* frdminc
notes his wireless keyboard actually seems to be working fine atm
<wolfspraul>
frdminc: which one is it?
<wpwrak>
lekernel_: you may appreciate that USB close simplicity in the case of hubs and, instead of requiring complicate store-and-forward, conveniently extend the already extremely tight timing just across the whole hub chain
<wpwrak>
s/close/chose/
<frdminc>
wolfspraul: the adesso one I mentioned earlier.
<wolfspraul>
how can they do this 300 megabytes / sec superspeed stuff now?
<wolfspraul>
I wish I had more patches that are not highlighting the fact that there is a rectangular boundary around the whole thing
<frdminc>
re: case for RF keyboards, IMHO doing it in software would be preferable (eg a root-window vnc server or using something like pyjamas so the UI is available in exactly the same way locally with normal gtaphical toolkit and via the web with javascript)
<wolfspraul>
so basically no solid colors along the sides
<wpwrak>
probably a somewhat different L2 protocol. already high-speed changes a few things, adds new packet types and so on
<wpwrak>
not sure if VNC wouldn't be quite a lot of work ..
<lekernel>
there's also the VNC server in QEMU that we can copy code from
<wpwrak>
particularly if the mask could change dynamically :)
<lekernel>
wpwrak: what would be the needed feature set for the next TMU?
<lekernel>
support for RGB 10:10:10 and ARGB 8:8:8
<lekernel>
:8
<lekernel>
what primitive polygon? the current rectangles are convenient because they're easy to do without bugs :-)
<lekernel>
but a bit limiting maybe
<wpwrak>
err, what polygon ? for the overall shape ? or for the vertices
<lekernel>
atm the only supported configuration is a tesselation of straight rectangles
<lekernel>
but if we switch to e.g. arbitrary triangles then we can draw any textured 2D polygon
<lekernel>
now - we have to draw each of these triangles correctly in all configurations including messy corner cases, and without visible "seams" at common edges of triangles when alpha blending is enabled
<lekernel>
this isn't easy
<wpwrak>
hmm, dunno how that would change things. i don't understand the logic of effect generation that well yet
<lekernel>
it doesn't change anything for the current process (that's why I took the rectangle shortcut)
<lekernel>
but if you want fancy things like dynamic alpha mask
<lekernel>
you could do it with a translucent 2D polygon overlaid on the picture
<wpwrak>
apropos easy. when you run the 8 bit starfield, do you see an array of red pixels ? if yes, are they artefacts or do they seem intentional ?
<lekernel>
huh?
<lekernel>
where?
<wpwrak>
over the entire frame
<lekernel>
those are white, no?
<wpwrak>
ah sorry, it's the inner workings of my new computer
<wpwrak>
there's a static array of red pixels
<wpwrak>
16x16
<wpwrak>
but i'm not sure if this it the patch's doing or something going wrong in the lower layers
cjdavis [cjdavis!~cjdavis@cpe-71-67-99-208.cinci.res.rr.com] has joined #milkymist
<lekernel>
could be a bug... the black pattern on the bars of "slow shift matrix" shouldn't be there, and might be related