<wpwrak>
the LV3 can supposedly use 8 bit values for controls instead pf the usual 7. does it do this out of the box ?
<wolfspra1l>
wpwrak: did I understand that correctly with hhkb pro resetting your m1 now?
<wpwrak>
wolfspra1l: i still need to check the voltages. but it looks that way. perhaps oversized input caps.
<wpwrak>
wolfspra1l: btw, you wanna check the route of M1 on its way to faderfox ;-)
<wolfspra1l>
over the us?
<wpwrak>
much better ;-)
<wolfspra1l>
checking, but... I trust the fedex computer system to know how to best keep their 700+ airplanes filled all the time :-)
<wpwrak>
yes, that's the impression it get, too. keep the planes filled, no matter how ;-)
<wolfspra1l>
ah ok, asia route
<wolfspra1l>
well that's the shorter one
<wpwrak>
and a night in paris :)
<wolfspra1l>
guangzhou is becoming a huge hub for fedex
<wpwrak>
well, evening :)
<GitHub152>
[flickernoise] sbourdeauducq pushed 1 new commit to stable_1.0: http://git.io/rjSORA
<GitHub152>
[flickernoise/stable_1.0] filedialog: do not allow empty filenames - Sebastien Bourdeauducq
<GitHub132>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/R-nRXw
<GitHub132>
[flickernoise/master] filedialog: do not allow empty filenames - Sebastien Bourdeauducq
<wpwrak>
yeah, the asian part is funny but kinda makes sense. the detour, on the other hand ... ;-)
<wolfspra1l>
what detour?
<wolfspra1l>
it's almost direct now
<wpwrak>
koeln -> paris -> koeln
<wolfspra1l>
oh, interesting
<wolfspra1l>
maybe a packing reason?
<wpwrak>
isn't it ? ;-))
<wpwrak>
hmm. maybe.
<wolfspra1l>
it may be packed in a larger container and be such a minority that the first time it's at Koeln it's not worth to open the larger one
<wpwrak>
yeah, that could be the case. or they just put it on the wrong pile :)
<wolfspra1l>
unlikely, but ok
<wolfspra1l>
but yes, interesting case :-)
<wolfspra1l>
I've seen others where a package from the US to China first went to the Phillipines, then back up
<wolfspra1l>
that's a thousands of miles detour
<wolfspra1l>
some Taiwan notebook makers have explored sending notebooks (and other consumer electronics) to Europe by train
<wolfspra1l>
but I think except for a few test trains they haven't really started using that yet
<wpwrak>
phew
<wolfspra1l>
lots of problems, politically, geographically, tax-wise, delays, climate, many unknowns
<wpwrak>
indeed. by boat may be easier :)
<wolfspra1l>
I think this was about replacing air
<wolfspra1l>
train can make it in a week or so
<wolfspra1l>
of course boat is unbeatable in price
<wolfspra1l>
but 4-6 weeks, and needs some scheduling to catch a boat etc.
<wolfspra1l>
they thought they can establish a train route as an intermediate
<wpwrak>
yes, boats are slow
<wpwrak>
interesting idea
<wolfspra1l>
hey, this is something supportive for PIONEERS...
<wolfspra1l>
one sec :-)
<wolfspra1l>
here you go "The concept for what became Federal Express came to Fred Smith while he was studying at Yale University. For a class there, he submitted a paper which argued that in modern technological society time meant money more than ever before and with the advent of miniaturized electronic circuitry, very small components had become extremely valuable. He argued that the consumer society was becoming increasingly hungry for mass-produced electr
<wolfspra1l>
that must have been around 1970
<wolfspra1l>
now the interesting part :-) "He submitted the paper to the professor teaching the course, who gave the paper the grade of "C". Despite the professor's opinion, Smith held on to the idea."
<wpwrak>
i guess he got that right on all accounts :)
<wpwrak>
and the professor ... not quite so :)
<wpwrak>
kinda like "linux is obsolete" by a. tanenbaum ;-)
<wolfspra1l>
yes. so the story is... if you do something truly new, you cannot assume people will agree with you or support you, no matter how much you believe in your story and how good it may eventually be.
<wpwrak>
(train) i'd worry about theft. trains stop a lot. easy to open a container and lighten the load a bit. or just grab the entire wagon. with a ship or a plane, you can be pretty sure that what is aboard when they leave will still be there when they arrive.
<wpwrak>
(new things) yup. a lot of people simply refuse to think outside their box
<wpwrak>
lekernel: when i look in my crystal ball, i see that you
<wpwrak>
're using a mouse that has a wheel :)
<wolfspra1l>
no no, not much text [lots of pics]. this is about controllers imho
<wolfspra1l>
"Is that so bad, to dump the tactile for the visual? Try this: close your eyes and tie your shoelaces. No problem at all, right? Now, how well do you think you could tie your shoes if your arm was asleep? Or even if your fingers were numb? When working with our hands, touch does the driving, and vision helps out from the back seat."
<wpwrak>
yes, i skimmed over the pictures. i get the message that tactile feedback is good :)
<wpwrak>
whee. brownout ! but nothing crashed :)
<wpwrak>
heh, it seems a lot of fun could be had on the lm32 by loading a non-zero value into r0 :)
<roh>
re
<wpwrak>
had a peek at USB hubs ... alas, not so transparent. the host has to query port status and actively enable ports
<wpwrak>
and another interesting discovery: the USB host only does low-speed. that explains a few more compatibility issues ...
<wpwrak>
e.g., the HHKB is full speed
<wpwrak>
now let's see if i've done a good job at breaking USB ...
<wpwrak>
apparently yes
<roh>
heh.
<roh>
what are you trying to do? add usb-hub support?
<wpwrak>
no, support for my RF keyboard+mouse combo
<roh>
heh
<wpwrak>
now .. where did i make the stupid little mistake that breaks it ...
<wpwrak>
ah, found one ... let's see what still work ...
<wpwrak>
ah. the acme keyboard (non-RF) doesn't work because it has some weirdo 2nd interface the new code didn't like. fixing ...
<wpwrak>
solved
<wpwrak>
now ... seems that my RF kbd uses a funny report format. let's analyze it ...
<wpwrak>
whoa ! now there's a rich report descriptor
<wpwrak>
lekernel: (full-speed) okay, you'll need this for usb-midi :)
<mumptai>
re
<lekernel>
wpwrak: I'm also getting what looks like lost midi messages when I press many keys at once... we should perhaps add a bit of HW buffering and do the message separation in the driver
<GitHub16>
[linux-milkymist] larsclausen pushed 1421 new commits to master: http://git.io/9BoFUg
<GitHub16>
[linux-milkymist/master] rtc: ep93xx: Fix 'rtc' may be used uninitialized warning - Axel Lin
<GitHub16>
[linux-milkymist/master] rtc: rtc-twl: Switch to using threaded irq - Ilkka Koskinen
<wpwrak>
what would you think of going one step more radical and moving the message separation into the FPGA ? so that it would push out words, not bytes
<lekernel>
not sure this would really help
<lekernel>
and it would use resources, and we won't be able to share the code with the uart anymore
<GitHub14>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/j6ZX8A
<GitHub14>
[flickernoise/master] Patch mashup support - Sebastien Bourdeauducq
<wpwrak>
yes, i would get a bit more complicated. for the hw buffering, that would be a proper FIFO where you can loop until it's drained ?
<lekernel>
yes
<wpwrak>
(mashup) video ? :)
<wpwrak>
(fifo) okay, that should be almost as good as hw MIDI
<lekernel>
phew, I'm a terrible film maker
<wpwrak>
;-))
<lekernel>
also, this is a quite experimental option. many patch combinations look very shaky and/or sluggish
<lekernel>
a few are interesting though
<lekernel>
and you can also use the other patch as a temporary disturbance, by pressing the key for a short instant
<lekernel>
using this feature is simple: when you have a performance set up, just press multiple keys at the same time
<lekernel>
it works with MIDI and the USB keyboard
<stekern>
(hw MIDI) parsing MIDI in HW is a pita, going with FIFO and sw parsing is the "right thing", my 2 cents
<wpwrak>
sw MIDI is certainly easier to tweak. e.g., we also don't have the "running status" yet
<lekernel>
it's probably not worth it anyway, you don't need hardware acceleration to process a 31kbps stream
<lekernel>
anything that can be done in software should be done in software
<stekern>
I agree, I have done it, but the only reason was that I didn't have a cpu to do the processing
<GitHub3>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/k10Qew
<GitHub3>
[milkymist/master] tools: allow overriding the C compiler for distributions like Fedora who can't package clang correctly - Sebastien Bourdeauducq
<wpwrak>
in gcc we trust ;-)
<lekernel>
I don't
<lekernel>
gcc should die
<wpwrak>
why ? it never let me down
<lars_>
lekernel: $(CC)?
<wpwrak>
aye, $(CC)
<lekernel>
GNU make sets $CC
<wpwrak>
so you override it. CC=clang
<wpwrak>
if someone overrides it on the command line, you still get the overridden value
<stekern>
the problem with a fifo is that you don't know beforehand how long the message is going to be (IIRC), so you can't trigger an interrupt on a fifo level. one way to solve it would be to poll the fifo at an interval that gives decent latency.
<lekernel>
yes, but then you have to modify the script to run on distros who ship a broken clang
<wpwrak>
but that happens in your case anyway ?
<lekernel>
stekern: you just interrupt as long as you have > 0 bytes in the FIFO... then the ISR reads the FIFO until it's empty
<wpwrak>
i mean, if you override it, it will be overriden. if you don't, you default to clang. so that's the same, isn't it ? only that you're using a non-standard name
<stekern>
lekernel: sure, but that would be the same as not having a fifo at all (if your system isn't really slow)
<wpwrak>
stekern: maybe you could add a delay after exiting empty state. we don't care about RT anyway.
<lekernel>
nah, the purpose of the FIFO here is to solve the problem of multiple bytes arriving when the interrupts are disabled
<stekern>
ah, ok. in that case it'd help
<lekernel>
wpwrak: if I use CC=clang, you have to modify the script
<lekernel>
wpwrak: if I use CC?=clang, it won't work because gmake sets CC
<wpwrak>
so what would i do if i want non-clang ?
<wpwrak>
i still have to modify the script to set COMPILER=gcc, no ?
<lars_>
lekernel: if you want clang as default add a entry to your make.conf
<lekernel>
and it defaults to clang
<lars_>
btw CC defaults to cc
<lekernel>
yes, which is gcc on all distros
<lars_>
so?
<wpwrak>
lekernel: CC=whatever make  should still work
<mwalle>
nope
<lekernel>
I know, but I want it to default to clang.
<mwalle>
make CC=gcc
<mwalle>
not CC=gcc make
<wpwrak>
okay. make -e then :-)
<lars_>
lekernel: but why?
<lars_>
why not use the systems default
<lars_>
that will work for almost everybody
<lekernel>
because I don't like GCC
<lekernel>
period :)
<mwalle>
lekernel: so set CC=clang, override it with make CC=gcc
<mwalle>
lol ignoring arguments seems to be common practice on the uboot mailinglist
<lars_>
lekernel: so change your /usr/bin/cc
<lekernel>
lars_: no, but I also want to make people aware of GCC alternatives :)
<mwalle>
or ignoring the mail entirely, this is so frustrating :(
<lekernel>
the fact that fedora screwed up their package is just unfortunate
<lekernel>
ah, yes... that works
<GitHub17>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/BCTe0Q
<GitHub17>
[milkymist/master] tools: use the CC variable - Sebastien Bourdeauducq
<wpwrak>
btw, if you really want to do fancy things with variables, there's also the $(origin VAR) function in GNU make. but luckily, we don't even need that here :)
<wpwrak>
bug 46898: so C is okay, C++ isn't ?
<lekernel>
no, neither is
<lekernel>
C fails later on
<lekernel>
C++ is also broken on 4.5.x by the way, you have bugs like one method being called in place of one another
<wpwrak>
maybe you need to restart that bug report. it goes back and forth a lot. not sure the intended recipient can make sense of it this way.
<mwalle>
wpwrak: mh there is no lm32 maintainer anymore
<wpwrak>
you could have stopped the sentence after "broken" ;-)
<mwalle>
so i guess nobody cares :)
<mwalle>
well there is one but thats a lattice guy
<mwalle>
which wont even reply to mails
<wpwrak>
mwalle: now there's your chance to rise to fame :)
<mwalle>
pft :b
<lekernel>
the LM32 LLVM backend seems to have made some progress, been a while since I checked it out
<lekernel>
and such problems seem more unlikely to pop up in LLVM, which has a much clearer interface between the language frontend and the CPU backend
<lars_>
mwalle: hm, v3.1 broken again
<lars_>
mwalle: what were the symtons you had on 3.0 again?
<mwalle>
lars_: null pointer after scheduling, iirc
<lars_>
hm, yes looks like i have the problem now
<mwalle>
sorry dont remember the struct atm
<mwalle>
offset was 30 or sth like that
<mwalle>
should now generate a nice bus error ;)
<lars_>
i have offset 7et ffc
<lars_>
offset ffc
<mwalle>
ffc?
<lars_>
it looks a bit as if register get messed up during process switching
<lars_>
or maybe not. the corruption always happens after sys_newfstatat
<mwalle>
the fault i had, seemed to be non deteministic
<lars_>
one the other hand it seems to be r11 which is corrupted, which is a bit suspicious