#milkymist IRC log for Wednesday, 2012-01-11

kristianpaulfor the new exp system, is posible add a clk signal but if dvi will have it i'm happy with00:01
kristianpauli dont like borrow clk from the memcard slot, may be not using it (memcard) but i still the chance to make Fatfs work on it someday ;)00:03
wpwrakkristianpaul: suggest it on the list ?00:07
kristianpauloh moment just arriving..00:08
kristianpaulcatching mails..00:08
kristianpauloops i cc joerg and wonder who else..00:18
kristianpaultought the thread was more about J3 xD00:19
wpwrakthat'll be another 50-100 years in purgatory00:19
wpwrakcladamw: the chat with joerg was quite productive :)00:54
cladamwwpwrak, he. morning ! yes , i just finished reading the email. :)00:56
cladamwyes, some dc block cap. we didn't follow wolfson's datasheet suggestions and kept lm4550b's design. ;-)00:59
cladamwwpwrak, "Also rename HP OUT to something that doesn't01:00
cladamw   suggest a strong amplifier. Maybe LINE OUT ?", what's this meaning?01:00
cladamwwpwrak, "Jx and Jy would be unpopulated footprints for 1x3 100 mil (2.54 mm) headers.", Does the word of "unpopulated" is we usually talked as "DNP"?01:06
cladamwwpwrak, above are the problems of my english comprehensive ability. Help me to clarify, tks. :)01:11
cladamwkristianpaul, hi, about the clk you used now, which clk you are pulled out for purpose ?01:14
kristianpaulcladamw: the one from memcard01:47
kristianpaulLOC = A1001:48
kristianpaulmc_clk01:49
kristianpauls/memcard/memory card01:51
kristianpaulah, i used the TP :-)01:51
cladamwmmm...i see01:51
kristianpaulTP-1901:51
kristianpauli needed that extra clock input a lot :)01:52
kristianpaulwas the fast way to solve my not very high knowledge to deal with multiple clocks in the same soc.01:52
kristianpaulwell i was about to make  fifo,but nah too much learning curve again ;)01:53
wpwrakcladamw: (HP OUT) "HP" is for "Headphones". but it seems that the wm9707 doesn't have a headphone amplifier. so we should change the signal name01:54
wpwrak(unpopulated) yes, that's DNP01:54
cladamwkristianpaul, mm... so a header pin of clk would be good for your need.01:59
cladamwwpwrak, okay, tks. maybe we just rename the "HP" to its "LNLVL{_L, _R}".02:00
cladamw"LNLVLOUT{_L, _R}"02:01
kristianpaulwell i hope not just for me, and anyone want to add a custom "board" to M1 and provide aditional clock input02:01
kristianpauli'm OK right now, i just wanted to put my comments... even if are just asking not giving ;)02:02
wpwrak(LNLVLOUT_*) yeah, that would be a possibility. it's very similar to the pin names, though. also, the "LVL" (level) doesn't really seem to add information. but okay, that's a wolfson problem02:03
wpwrakkristianpaul: are those clock outputs only for clocks or can they also be used for other signals ?02:04
cladamwwpwrak, do you think that sd_clk can be wired to new J21?02:04
wpwrakkristianpaul: and how many unused/unconnected clock outputs do we have ?02:04
wpwrakah, those are *_GCLK*, right ?02:05
kristianpaul(unused/unconnected) well last time i asked here and checked schematics (sorry giveup check layout with altimun) zero02:06
kristianpaulright02:06
kristianpauli think can be used for other signals as well, let me check..02:06
cladamwkristianpaul, did you modify verilog yourself about that sd_clk pins? or just used it?02:06
kristianpaulmodified of course to no used sd_clk for sd related task yes02:06
wpwrakIO_L29P_GCLK3_2 seems available (on U22C)02:08
kristianpaullet see02:08
kristianpauli have rc2 just in case02:08
wpwrakIO_L31*_GCLK3*_D1*_2 seems a little wasted for FLASH_D1* too. but i guess that's hardwired for booting ?02:09
kristianpaulseems = populated/routed ?02:09
kristianpaulwaste yes, i noticed that to time ago..02:09
wpwrakit's unconnected in rc302:09
kristianpauland for our loved EDK owners? :-)02:10
wpwrakU22B has a few more: GCLK10 and 1102:10
kristianpaulHE ver yes !02:10
kristianpaulwaste!02:11
Last message repeated 2 time(s).02:11
kristianpauls/HE/HW02:11
kristianpaulargh, i remenber that..02:11
wpwrakso, seems that we could have at least three clocks02:12
kristianpaulah moment, on my rc2 dataheet  IO_LP29_GCLK3 nor routed it seems02:13
kristianpaulbut L29N GCLK2 do02:14
cladamwwpwrak, so can we just list up these requirements firstly on two J21s then determine which should be the rests?02:15
kristianpaulnope sr wpwrak , in my rc2 sch IO_40P_GLCK11 not routed it seems02:16
wpwrak(LN29N) yes. HW_VER_3. i think we can get rid of that ;-)02:17
kristianpaulneither IO_L40N_GCLK1002:17
wpwrakexcellent02:17
kristianpaulor i'm confusing signals?02:17
kristianpaulwpwrak: can you confirm what i said for rc2?02:21
kristianpauli think we're in same page...02:21
kristianpaullet me see rc3 sch02:21
wpwraki have no idea about rc2. but all these signals look available on rc3. and given that rc3 is the basis for rc4 ... ;-)02:23
kristianpaul!!!! :)02:24
kristianpaulbut wait you agree GCLK10 is IO_L40N_GCLK10 ?02:25
kristianpaulin rc302:25
kristianpaulU22B02:25
kristianpaulcause i still dont see where is in routed to/for02:26
kristianpaulsorry,02:26
wpwrakit's probably not routed02:27
wpwrakit's not routed on rc302:27
wpwrakwhat i'm talking about are currently unrouted clocks. i.e., clocks we can bring to the new J21 companion in rc402:27
kristianpaulahhh  !!!02:28
kristianpauli tought we're talking about routed gclk ;)02:29
kristianpaulok02:29
kristianpauli can rest now02:29
kristianpaul:)02:29
kristianpauland try to setup this bluetooth kbd :S02:29
kristianpaulroute yes :)02:33
kristianpaulwpwrak: had you seen the m1 rc3 layout?02:33
wpwrakwell, the pretty-printed version. didn't look much at the gerbers beyond that02:35
GitHub64[milkymist] wpwrak created symtab (+3 new commits): https://github.com/milkymist/milkymist/compare/44acf61^...8dbe0fd07:27
GitHub64[milkymist/symtab] libfpvm: only access node->label if we have an indentifier - Werner Almesberger07:27
GitHub64[milkymist/symtab] libfpvm: introduce "struct sym" as abstraction for an identifier - Werner Almesberger07:27
GitHub64[milkymist/symtab] libfpvm: rename "struct sym" to "struct fpvm_sym" - Werner Almesberger07:27
GitHub26[flickernoise] wpwrak created symtab (+13 new commits): http://git.io/xYjlcA07:27
GitHub26[flickernoise/symtab] compiler: define op_not such that we don't trigger a warning - Werner Almesberger07:27
GitHub26[flickernoise/symtab] compiler: track reduction of "label" use in libfpvm - Werner Almesberger07:27
GitHub26[flickernoise/symtab] compiler: don't predefine identifiers for function names - Werner Almesberger07:27
wolfspraulwpwrak: so it looks like we have the perfect solution for J3?07:59
wolfspraulcladamw: did you see all of this? is it clear?07:59
cladamwregarding to zener diode, need to find real p/n later. else are clear.08:02
cladamwand also regarding to if add clk pins on new J21, seems kristianpaul and wpwrak talked a lot. so will also ask wpwrak later.08:04
wolfspraulyes, I wanted to ask about that to08:04
wolfspraultoo08:04
wolfspraulok good08:05
wolfspraulcladamw: but I think whatever outcome of the clock discussion, that's unrelated to J308:05
wolfspraulso you can 100% finish J3 now, I think08:05
wolfspraultrue?08:05
cladamwyes, i'll draw firstly08:07
cladamwto draw for J308:07
wolfspraulgood. so we first finish J3, then onto J2108:07
cladamwyeah08:07
wolfspraul(and we find out about kpaul's clock thing as well)08:08
wpwrakcladamw: yes ;-)13:28
wpwrakcladamw: i don't think we need to keep footprints for l3, l19. just connect the ground directly13:29
wpwrakcladamw: note that the recommended point for connecting the grounds is across the chip (at least in one case. don't remember whether it was video or audio)13:29
wpwrakcladamw: so the link between the split ground planes should be under the codecs, making sure they have as small a voltage difference between grounds as possible13:30
cladamwwpwrak, yes, i deleted them in sch, then i am thinking that just using directly wire to short those two ground systems(digital&analog) to keep same results as rc3 patch now.13:31
wpwrakcladamw: and l3/l19 disappear for good13:31
wpwrakcladamw: the rc3 solution is sub-optimal. it works, but it could be better. and if you do it properly, there's no place for L3/L19 footprints anyway. problem solved ;-)13:32
wpwrak(properly = connect the ground planes under the chip)13:32
wpwraksee also http://www.analog.com/static/imported-files/data_sheets/ADV7181B.pdf13:34
wpwrakpage 95, figure 4113:34
wpwraksee, there's no place for L19 ;-)13:34
wpwrakand audio is just the same13:35
cladamwConnecting the ground planes under decoder may do or maybe not, I'll try to let house do that. since rc3 already pretty works well, if house guy think they will move too much works, then I'll just let them to 'wire' those splitted planes.13:36
wpwrakthey should do it cleanly, even if it means 10 seconds more work :)13:37
wpwraklet me put it this way: if connecting the ground planes correctly is difficult for some reason, we probably have a problem elsewhere :)13:37
cladamwwpwrak, ;-)13:38
wpwrakjust think of all the generation of poor young engineers who will look at our design, trying to learn from the wisdom of great master adam. they will not understand but honor the example. and in half a century, the world will perish because some black hole containment device at CERN will fail due to an improperly handled surge. because they used a "wire", like great master adam did, instead of connecting split ground planes under the chi13:45
wpwrakp. there will be a lot of angry spirits in the afterlife after that. do you want to risk that ? :-)13:45
cladamwhaha...the rules now is always to follow recommended datasheet which needs senior doctor werner to discover its backend stories. ;-)13:51
wpwrakheh, the thing is actually easy to understand. the only surprising bit is the magnitude of the effect. but well, now we know :)13:53
cladamwwpwrak, the current L19 is too far away from decode, according to figure 41, so yes,13:56
wolfspra1lcladamw: try to cleanup L3/L19 properly13:58
wolfspra1lthat means move under the chip etc.13:58
cladamwlet's move that 'bridge' under chip, current those two planes are splitted very well; so move 'bridge' to there.13:59
wolfspra1lI am not afraid of taking some risks, and rc4 will have a lot of things so if we are afraid of something like that - it feels wrong13:59
cladamwhaha... I am not afraid of somethings, you know Taiwanese engineers, to work with them are not always easy like working with western guys. well... so the problems now is on my site.14:01
cladamwyou've seen much styles of taiwanese. ;-)14:01
wolfspra1lcladamw: do I understand this correct that you are now editing the rc4 schematics in Altium?14:09
wpwrakwhere else ? :)14:11
cladamwwolfspra1l, yes...editing rc4 in AD. but meanwhile I'm making notes more for further layout instructions while editing sch.14:11
wolfspra1lah ok14:11
wolfspra1lnice14:11
wolfspra1lI was *overwhelmed* by how much feedback we seem to have gotten around the elimination/reduction of J3 in just a day ;-)14:12
wolfspra1lburied well, to be resurrected whenever... NICE!14:12
wolfspra1lthat was a far better outcome than I would have expected14:13
wpwraktouching audio is always like opening a can of worms from pandora's superstore ;-)14:13
wolfspra1lso are we ready to take on J21 now?14:14
wolfspra1lthe new 'U-shape' etc14:14
wolfspra1lor still wait a little until things settle?14:14
wpwrakwe have one bit for J21 already: those clock signals. i wonder if there are any other "magic" pins on the fpga ?14:14
wolfspra1labout compatibility, if we switch the header from male to female, is there any hope for pre-rc4 owners?14:15
Action: wpwrak looks questioningly in the general direction of lekernel14:15
wolfspra1lI asked yesterday already - are there some types of female-female adapters that one can plug onto a male one to convert it to a female one?14:16
wolfspra1lif so, that would at least be a hackish workaround for pre-rc4 boards, if the future expansion boards don't electrically utilize the 2nd header we are adding14:17
wolfspra1lor they could just swap the male header to a female one, maybe? I mean on the board...14:17
wpwrakwolfspra1l: they have a number of options: 1) brute force - just make an adapter. 2) make a board variant for rc2/rc3, populated with a female connector instead of the cheaper male. 3) since they may be using a cable anyway (remember, only with rc4, you get proper mechanical stability), have an rc2/rc3 cable variant14:18
wpwrakwolfspra1l: ah yes, 4) unsolder J21 (yuck) and put something female there14:19
wolfspra1lare there female-female adapter pieces?14:19
wolfspra1lif we totally break compatibility, we may also change the pins on J2114:20
wolfspra1lalthough I am not sure whether such freedom would be welcome or not, maybe we will just waste time stirring the pot, without creating value14:20
wpwrak... searching ...14:30
wpwrakperhaps not14:34
wpwrakbut you could make your own. either by soldering receptacles together or with a PCB14:35
wpwrakso, 5) design for rc4+ and make an adapter board for all the of rc2/rc3 customers14:36
wpwrakif we go on like this, we'll soon have more work-arounds than rc2/rc3 owners ;-)14:36
wolfspraulhttp://media.digikey.com/photos/FCI%20Photos/89898-306LF_FCI.JPG14:41
wolfspraul(that one is not entire right yet)14:41
wolfspraulhttp://search.digikey.com/us/en/products/89898-306LF/609-3042-ND/153500314:41
wpwrakah, not bad. yes, that may work14:43
wpwrakmaybe a bit too short for a good connection. but then, you could also use it as a building block for an low-profile adapter14:44
wpwrakmillions of possibilities. no need to worry14:44
wolfspraulok14:45
wpwrakthe most likely outcome is that any "serious" board will require the U anyway, which rc2/rc3 can't do14:45
wpwrakand ad hoc connections (like the usb switch control adam has made for pre-rc4) don't care whether it's male or female14:46
wolfspraulalright then. I just hope we have a long-term expansion system from rc4 on14:49
wolfspraulalthough I have no illusion that the perfect 'expansion' system cannot exist, because one cannot prepare for the unknown...14:49
wpwrakso do we all. like PCI or more long-lived and more popular ;-)14:49
wpwrak(prepare for the unknown) those who fear change must be quite angry at their ancestors who crawled out of the safety of the primordial mud14:57
wolfspraulI just see them crawling out of primordial mud holding a female expansion header15:16
wpwrakyeah. and then they moved right on to building the pyramids using neutrino beam cutters and antigravity. alas, all that was lost when atlantis drowned.15:43
lekernelwpwrak: there are many restrictions on what FPGA pins can drive what. clock signals with a low and predictable skew dedicated route to the global buffers are just one example.16:39
lekernelbut as I told kristianpaul at least 4 times already it's perfectly fine to send any clock through the general purpose routing when there are no tight timing constraints involving that clock and other I/Os16:41
wpwrakclocks seem to be fairly crucial. are there others of similar importance ?16:41
wpwrak(clock on gp) heh :)16:41
lekerneldedicated clock pins are crucial only when such a tightly timed interface exists... which isn't the case today afaik16:43
wpwrakbeing able to have precise clocks seems to be useful in general. you can never be too precise :) (of course, you can over-obsess ...)16:44
lekernelanother area is differential pairs - you can only have differential I/Os on contiguous pins16:46
lekernelthen there are length matching and impedance concerns16:46
wpwrakso we should try to have pairs instead of random picks. let's see how we're doing this far ...16:46
lekernelit never ends, so I'm blissfully ignoring those issues unless there's an actual need for this16:47
lekernelbut so far this expansion connector has been carefully ignored by most people16:47
wpwrakfor now, we're perfect :)16:47
wpwraknot by some who are among those who have the most effect on future M1 development :)16:48
wpwrake.g., adam put it to good use for the usb switch16:48
lekernelyes, but you don't need global clock buffer capable I/Os for this ...16:49
wpwrakjust because we didn't care about exact clock so far doesn't mean we won't in the future :) e.g., this could also be used for diagnostics16:49
lekernelany I/O can reach any global clock buffer through the general purpose routing. only, non-dedicated paths have more skew.16:50
wpwrakand hopefully we'll come across some money in one way or another that will allow us to afford the instruments that will actually let us see those small timing differences ...16:50
wpwrakpretending that the world above 10-20 MHz doesn't exist is arduino engineering ;-)16:51
wpwraki think i just invented a useful term, "arduino engineering" :)16:52
Fallenouit deserves a quote somewhere =)16:52
lekerneloh, we do care about timing where it's needed - on the DDR for example. but I see little use so far on the exp connector16:54
lekernelbut yeah, go ahead and add some if you wish16:56
lekernelas long as it doesn't introduce signal integrity or EMI regressions16:56
wpwrakEMI ought to be agnostic to whether we use an "exact" pin or a less exact one. dunno about signal integrity. i'd hope internal buffers don't notice non-abusive use of the expansion header. of course, if someone just shorts one end of a differential pair to ground, all bets are off ...16:58
wpwrakare there any other "special" pins you'd think could be useful on the expansion header ? (be it for expansion or just for access. i'd also say expansion is more convenient than TP)16:59
lekernelno, the problem is you may have to move some existing tracks around the PCB to get those extra pins routed, and this might cause SI/EMI regressions17:00
lekernelespecially since you are reaching into the higher-density area around the BGA17:00
wpwrakyeah, the easily accessible ones are already wasted on FLASH_D1* :-(17:02
wpwrakwell, we have GCLK0 (AB13) that's not too bad17:02
wpwrakthe FLASH_D1* assignment is hard-wired by xilinx, isn't it ?17:04
lekernelyes, most flash pins are hardwired for fpga configuration17:29
kristianpaullekernel_: (4 times told abput clock), may i bve wrong but i remenber telling you i was going to use that glck ping to replace milkymist soc main clock20:30
kristianpaulso anyway i dont care if J21 will have gclk or not, really, i'm okay with my very custom setup and fpga internal routing ingnorance20:39
kristianpaulso it works for me now from the memory card clk :)20:39
wolfspraulkristianpaul: ahh, wait please :-)20:47
wolfspraulmaybe I'm dumb enough to understand it, I certainly would like to try20:48
wolfspraulyou need a clock signal, from m1 going to your sige evb?20:48
wolfsprauland you don't have that on J21 right now so you take it from the memcard?20:48
wolfspraulis that correct?20:48
kristianpaulyes20:49
wolfspraulbecause I have no idea about that clock, can you tell me what kind of clock it is?20:50
kristianpaulfah wait, from sige evb to m120:50
wolfspraulwhat frequence? what's the purpose?20:50
wolfspraulfrequency20:50
kristianpaul16384Hz20:50
kristianpaulis gps receiver sampling clock20:50
wolfspraulok, it's a clock going from sige to m120:50
kristianpaulyes20:50
wolfsprauland you cannot send that signal in over j21. why not?20:50
kristianpaulxst complains about timing, but i could try again and send proper logs20:51
wolfspraulbut when you route it in over the memcard - no xst complaints?20:52
wolfspraulwhich memcard pin exactly actually?20:52
kristianpaulit complains at first, but the i add to contraint file that this is not a dedicated clock signal, then timing works20:53
wolfspraulso that sige clock becomes your main milkymist clock now?20:53
kristianpaulyes20:53
wolfspraulyou run the lm32 at 16 mhz?20:53
kristianpaulno20:54
kristianpaul16Mhz x 4 :)20:54
wolfspraulah ok :-)20:54
kristianpauland btw the other xst/ise message with J21 was related to some IO2buffer dont remnber well20:54
wolfspraulwhich memcard pin do you use to send the clock in now?20:55
kristianpaulbut my conclusion at that time was that signal could no be routed to a main clock, may be i dont dig enought..20:55
kristianpaulclk pin20:55
kristianpaulTP 1920:55
wolfspraulhmm20:56
kristianpaulmc_clk20:56
kristianpaulis on the datasheet20:56
wolfspraulso those xst warnings you ran into, maybe there would have been ways to address those warnings?20:56
kristianpauli remeber it said cant do soemthing related to a buffer20:57
wolfspraulok20:57
wolfspraulwell thanks a lot that was very helpful for me, at least :-)20:57
wolfspraullearning20:57
kristianpaulme too ;)20:57
wolfspraullekernel says it should be 'perfectly fine' to use the general i/o pins for clocks20:58
kristianpaulbut even for milkymist main clock=20:58
kristianpaul?20:58
larscfor output clocks i think20:58
kristianpaulwhen i was using sige clock for a not main milkymist clock _all_ was gine20:59
kristianpauls/gine/fine20:59
kristianpaulbut as i said, i wanted to have an external clock for milkymist soc20:59
wolfspraulfully understood20:59
kristianpauli wonder if  that fine' to use apply as well20:59
wolfspraulwell we are adding a second 2*9 connector. we can add such a clock pin there :-)20:59
kristianpaulif you can and dont disturb nothing, will be nice! thanks !21:00
larsckristianpaul: wolfspraul only quoted half of what lekernel_ said. he said it is fine for clocks with non critical timings21:00
kristianpaullarsc: indeed !!21:00
wolfspraulyes21:00
wolfspraulwell I have no idea about disturbing21:00
wolfspraulbut I think I understand what you want21:01
kristianpaullarsc: i dint ask for gclk pin before,  until i decide not deal with crossing clock domains, and swtiched soc to single clock, was easier solution :)21:01
wpwrakso the question is basically if you could use a non-GCLK pin as a clock source for the (entire) FPGA itself. correct ?21:32
wpwraka "master clock" does sound like something that's sensitive to accuracy, skew, etc.21:33
kristianpaulcorrct wolfspraul21:36
kristianpaulwpwrak:21:36
wolfspraulso what would go against adding such a gclk pin to the second expansion header?21:41
wolfspraultoo risky?21:41
wolfspraulonly idiots need it? :-)21:41
wpwrakthe only reason against is seems to be potential routing complexity21:42
wpwrakabout only idiots needing it, atben may not have needed its own crystal if the ben could have provided a "clean" clock signal :)21:42
wpwraknot sure if the fpga can provide such a clean clock, but at least it seems that gclk is one step closer to that than any arbitrary pin21:43
wpwrakbesides, if we ever need to debug clocking issues, we'll probably want access to as raw a clock as possible21:44
wpwrakand i'm not even talking about clock input yet :)21:44
kristianpaul:-)21:51
lekernel_kristianpaul: exactly! and that main clock doesn't have timing constraints wrt I/Os, so it's fine to send it through general purpose routing22:57
lekernel_now if you have to run a synchronous interface with some other pins, that's only where the problems arise. though at 16MHz, you're likely to have wide margins...22:58
lekernel_GP routing may produce some slight duty cycle distortion (something I discovered developing the TDC core...) but the DCM will clean that up anyway23:00
wpwraklekernel_: so general i/os are also suitable for the master clock input (i.e., what then goes to the PLL) ?23:04
larschm, maybe a related question. if i have two clocks which are phase synchronized but one is faster than the other, does that reduce the metastability risk when exchanging sinals between the two clock domains?23:05
larscand do i need synchronization at all in this case?23:05
wpwrakwolfspraul: btw, how are things going on the MIDI front ? :)23:14
wolfspraulha23:15
wolfspraulstuff is still standing here, but actually lemme try :-)23:16
wolfspraulicreativ first23:16
wolfspraulmy m1 froze, oh well23:17
wolfspraulmust have happened in last day or so (screen was off, but I kept it running)23:18
wpwrakrc2 has a bad reputation to uphold in that regard :)23:22
wolfspraulfirst I had to choose between keyboard and mosue23:24
wolfspraulremoved the mouse first - bad decision, didn't know how to navigate the menus anymore23:24
wpwraksetting up midi is easy: let's do it for the tornado rain dance rmx: first, go to the midi dialog23:24
wolfspraulnow removed keyboard23:24
wpwrakyou need the mouse :)23:24
wolfspraulI notice that the midi settings dialog does not fit in 640x48023:24
wolfspraulthe icreativ is powered though and m1 running - that's good23:25
wolfspraulpowered from m123:25
wpwrakbtw, a convenient little combo keyboard is the "rii mini remote" something like USD 30-100, depending on where you buy23:25
wpwrakokay, tornado rain dance needs eight controls: 1 = X, 2 = Y, 3 = a fader, 4 = a pot/encoder, 5-8 = faders (don't need to be good quality)23:27
wpwrakfor 1 and 2, use the X/Y mode. select with button on the right side of the icreativ23:27
wpwrakthen click on midi1 and hold down the mouse button23:28
wpwrakthen move the finger horizontally23:28
wpwraki think the value is 12. when you see that, release the mouse button23:28
wpwrakthen repeat for midi2, moving vertically23:28
wpwrakmidi3, the mechanical fader on the left side of the icreativ23:28
wpwrakmidi4, use one of the four encoders23:29
wpwrakmidi5-8, select "control", which gives you 8 faders on the pad. then assign four of them23:30
wpwrakimportant: you have to close the midi window (OK) before the settings become active23:30
wolfsprauldo you see anything under "Latest active controller"?23:31
wolfspraulwhen I click on midi1 and hold the mouse button, I cannot get any "12" to show up23:31
wpwrakyes, the "latest active controller" should change as you use the icreativ23:31
wolfspraulno, nothing there23:31
wpwrakhmm. then usb-midi isn't working23:32
wolfspraulmy notebook shows the icreativ23:34
wolfspraultrying lv3 on m1 now23:34
wpwraklvl3 doesn't work very well because of the odd channel assignment23:35
wolfspraulnothing under 'latest active controller'23:35
wolfspraulbtw, I am using the 2011-11-29 image23:35
wpwrakif you have a serial console, you could see if the bios detects the midi controller23:35
wolfspraulis it even working there?23:35
wolfspraulrebooting m1 with lv3 connected23:36
wpwrak29-11 may be a couple of days too old23:36
wpwrakanything made in december is probably okay23:37
wolfspraulLinux doesn't know the names for either the icreativ or lv3 usb vid/pid - weak23:38
wolfspraulI should help updating linux-usb.org, but also lazy now ;-)23:38
wpwrakit will ... :)23:38
wolfspraulso first thing we need a new release, or I have to build from source23:38
wolfspraulor wait, xiangfu is doing daily builds23:38
wpwraki added my usb zoo to the linux usb database on nov 29. hasn't been accepted yet, though23:40
wolfsprauloh great23:41
wpwrake.g., https://usb-ids.gowdy.us/read/UD/2256/100723:41
wolfspraulamazing that we are the first ones running into this, no?23:41
wpwrakoh, the database is very incomplete. it didn't even have my HP printer23:41
wpwrakhttps://usb-ids.gowdy.us/read/UD/03f0/5c1723:42
wpwraknot the most exotic device on the planet23:42
wolfspraulok so we just didn't care yet to release an update that brings usb-midi out23:44
wolfspraulif that's what blocks my icreativ & lv3 from being recognized23:44
wpwrakyeah. nov 29 is too old. i posted the changes that make everything work on the 30th23:45
wpwrakor at least they should make everything work :)23:45
wolfspraulstill nothing in 'latest active controller' after reboot23:51
wolfspraulI will get an update first (but I won't build from source now)23:52
wolfspraulthat rii mini wireless keyboard you mentioned - it's a wireless one and then a USB dongle on the computer/m1 side ?23:53
wpwrak(rii) yup23:54
wpwrak(update) you need something that has my patches posted on nov 30. so a nov 29 build is either too old or the time machine malfunctioned :)23:55
--- Thu Jan 12 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!