<CIA-48>
flickernoise: Xiangfu Liu master * rf89125c / src/input.c : make US layout full working - http://bit.ly/l5Dc28
<xiangfu>
lekernel: my French keyboard is on the way. I will finish the french layout when I got the keyboard. (a little bit hard to buy the french keyboard)
<xiangfu>
lekernel: I think I will first make the french layout working in current mtk.git code structure.
<lekernel>
why?
<lekernel>
you'll need to redo everything after
<xiangfu>
lekernel: when you have time you can give me a little tips about how to finish all this 'input.c'
<lekernel>
well easy
<xiangfu>
lekernel: for now I don't look into the 'modifier' keys.
<lekernel>
strip out most of the lib/kepmap.c, just turn it into a dumb get_ascii function that returns 'a' for MTK_KEY_A, etc.
<xiangfu>
then using the 'keyb_translation_table' to get the MTK_KEY_A right?
<lekernel>
and define new keyb_translation_table arrays in flickernoise/src/input.c, one for each keymap, that turn the hardware keyboard scancodes into MTK_KEY_* values
<lekernel>
it doesn't make sense to add more stuff that depends on the semi-translated (i.e. keymap independent) MTK_KEY_* values, because those will go
<lekernel>
there's a lot of stuff in input.c, most of which you do not need to understand to get the keymaps to work
<xiangfu>
what about the SHIFT and AltGr?
<lekernel>
the only thing you need to understand is the handle_keybd_event() function
<lekernel>
static int handle_keybd_event(mtk_event *e, unsigned char *msg)
<lekernel>
1) e -> array of mtk_event structures, written by the function with the decoded events
<lekernel>
2) msg -> raw USB message from the keyboard, read by the function
<lekernel>
3) return value -> number of events written by the function in the 'e' array
<lekernel>
you need to send MTK_KEY_* events when shift and altgr are pressed and released
<lekernel>
the status of those keys is indicated by a bitmask in the first byte of the USB message
<lekernel>
it is handled with the calls to the check_modifier() function
<lekernel>
afaik all keymaps would send the same codes for those keys, but if not, just change the values passed to check_modifier() depending on the keymap
<xiangfu>
so we have to add the like : 'ä' --> MTD_KEY_AE to the keycode.h
<lekernel>
'normal' keys are handled with the keyb_translation_table lookup table
<lekernel>
in the next bytes of the USB message, the keyboard will send one or multiple codes between 0 and 255, each identifying a key being pressed
<lekernel>
the handle_keybd_event() function goes through those bytes, and looks them up in keyb_translation_table (which has 256 entries)
<lekernel>
the keyb_translation_table value is a MTK_KEY_* value - right now for the QWERTY keyboard, which gets later translated by MTK to another keymap
<lekernel>
what I want you to do, is remove the second translation by MTK
<lekernel>
and make keyb_translation_table return directly the correct MTK_KEY_* value for the correct keymap
<lekernel>
so you basically need one keyb_translation_table per keymap, and switch between them
<lekernel>
understood?
<xiangfu>
yes. for now we are like  Scancode --> MTK --(three keymap here) --> ASCII
<xiangfu>
let me write my thinking. see if it correct.
<xiangfu>
1. I will re-write keycodes.h for easy convert MTK to ASCII. add all 256 ascii to the keycodes.h
<xiangfu>
2. add three 'keyb_translation_table' to input.c
<lekernel>
yes
<lekernel>
keycodes.h already has all the ASCII keys
<scrts`>
hm.. are the rx_clk and tx_clk on ethernet phy are always working or just when the data is sent?
<xiangfu>
lekernel: hmm... there is no 'ü' ...., in keycodes.h
<lekernel>
aw: "we got the protection goal with regression" what do you mean?
<aw>
sorry that typed too fast ...should be "without"
<lekernel>
xiangfu: keycodes.h is inspired by the Linux keycodes... so
<lekernel>
either 1) the ü is somewhere in it with some weird name but we didn't find it
<lekernel>
2) since keycodes.h contains a lot of cruft because of this Linux legacy (examples: MTK_KEY_TV2, MTK_KEY_VCR, ...) we can also break whatever little Linux compatibility it has, strip out this useless stuff, and add useful codes (ü, ö, ...) instead
<lekernel>
btw, I'm not sure ü/ö/ä are in ASCII
<lekernel>
but those aren't super important either
<lekernel>
so there's also 3) we don't care about those keys for now
<xiangfu>
lekernel: ok.
<lekernel>
having those keys means we also need to support them in the fonts etc. so...
<xiangfu>
my last commit in mtk.git make those keys working. and it's display correct in 'patch editor'
<lekernel>
ok, good
<lekernel>
but the patch language doesn't need them :-)
<xiangfu>
(I don't know how MTK display them for now :(
<lekernel>
neither does URLs and most other user inputs
<xiangfu>
sure.
<lekernel>
Genode fx (which MTK is a fork of) was written by German guys, so I'd bet they used some ASCII variant which has them
<lekernel>
they're in that ... probably what they used
<lekernel>
so maybe clean up keycodes.h: remove useless keys and add those we need
<lekernel>
and support ä/ö/ü
<xiangfu>
ok
<xiangfu>
direct map MTK to ASCII :)
<xiangfu>
s/MTK/MTK_KEY_*
<lekernel>
well, MTK_KEY_* will have more than ASCII codes
<lekernel>
you need to put F1, F2, ..., Alt Gr, Shift, ... in that
<xiangfu>
then those should be bigger then 256
<lekernel>
yes but it's not a problem
<lekernel>
it's an int type
<lekernel>
but yeah, for simplicity you can put the ASCII codes at the beginning
<lekernel>
so all MTK_KEY_* values which are less than 256 somewhat directly map to ASCII (but you'll have to handle modifiers as well)
<lekernel>
btw modifiers will be a bit of a pain
<lekernel>
because it's not always the same characters (selected with a modifier) which are grouped together
<lekernel>
so I'd guess you'll need a MTK_KEY_* value for each group of characters... which in the end pretty much compromises this idea of direct ASCII map
<xiangfu>
sorry what you mean about 'because it's not always the same characters ... grouped together' ?
<xiangfu>
what group?
<lekernel>
for example the French keyboard has a key with @, Ã and 0 on it
<lekernel>
while the German one has Q and @
<lekernel>
so you need two MTK_KEY_Q_AROBASE and MTK_KEY_AROBARE_AGRAVE_ZERO
<xiangfu>
lekernel: we have to move the SHIFT table and AltGr table to input.c right? if we have the SHIFT and AltGr working in input.c, we don't needs those group defines
<lekernel>
how would you handle key combinations like Alt-F1, then?
<xiangfu>
hmm...  I will look into more detail. if I still question. I will ask you :)
<xiangfu>
one small question. is that easy to add 'REMOTE POWER ON' in standby bitstream? like IR remote controller turn on the TV
<lekernel>
yeah
<lekernel>
not too hard
<lekernel>
but not a very useful/high priority feature, as far as I can tell
<roh>
Thread safety (when enabled with --enable-threads) requires a POSIX threads implementation with support for recursive mutexes.
<roh>
does the current libc do that?
<lekernel>
roh: well, I need to get internet access to work fine on M1, and RTEMS uses the BSD network stack
<lekernel>
and tbh BSD code isn't always that bad
<roh>
its funny. learn how not do do stuff in 2010 and behind
<lekernel>
heh
<lekernel>
have you read GNU code, in comparison?
<lekernel>
it's not brilliant either
<lekernel>
probably worse than BSD, I would say
<roh>
sure.
<wpwrak>
lekernel: at least the gnu indentation style serves as a clear early warning ;-)
<roh>
but atleast its not the fucking 6s.
<roh>
eh 60s.
<roh>
in my eyes we can drop the whole fucking socket config interface in linux. its shit. its broken. it may be posix, but it cannot do half the stuff.
<roh>
netlink is the way (for years) to config an ipstack.
<lekernel>
code being bad because written in the 60s doesn't look like a sound technical argument to me
<lekernel>
or, rather, I guess you mean in 60's style
<roh>
well.. it also cannot handly things we learnt about ip later... e.g. ecn, ip aliasing, vlans.. proper routing... all the stuff which is a hack in the oldstyle ifconfig thinking.. which IS how the bsd stacks work afaik.
<lekernel>
well, for the M1 it's going to be fine without that :)
<roh>
lekernel: sure. just dont wonder if stuff doesnt work.
<lekernel>
that piece of code was from RTEMS btw. not BSD.
<roh>
e.g. ecn is actively used in the internet. bsd4.4 code doesnt handle it properly (former reserved bits in the ip header) and drops em.
<lekernel>
to give you more to rant about, there is no ipv6 on m1 :-)
<kristianpaul>
;)
<roh>
lekernel: as long as you can fix that later...
<wpwrak>
lekernel: i suppose you have really nice cobol and fortran then ? ;-)
<lekernel>
oh sure... just sw upgrade
<lekernel>
actually, if (uC)Linux works someday, there will be ipv6
<roh>
or somebody fixes rtems
<roh>
its not that hard. there is ipv6 stacks running on 8bit mcus
<wpwrak>
yeah. the tcp/ip stack is one of the reasons why it became difficult for proprietary unix variants to exist alongside the free ones.
<lekernel>
some rtems people are discussing that, and they find it "hard". which I disagree with, but I don't feel motivated either to do it.
<roh>
bwhjahaha
<wpwrak>
networking is tricker than you may think :)
<roh>
kids with their grannys metal-model-train discussing why the lego people are so much faster on development...
<lekernel>
ipv4 is still going to be around for at least a decade or so, until then we have plenty of other stuff to do in milkymist
<lekernel>
even major german isps don't have ipv6
<roh>
lekernel: be around yes. majorly used. no
<wpwrak>
"let's call the smith to forge us that piece" ;-)
<roh>
lekernel: its over. this year. we will all have v6 addresses at our home dsl by end of the year.
<wpwrak>
i kinda doubt this
<roh>
the last olympic games already used v6 as major network.
<wolfspraul>
roh: we will leave the dmx push button as-is
<wolfspraul>
so that one is settled :-)
<roh>
wpwrak: nope. the only other possobility is nat. which doesnt work properly
<roh>
wolfspraul: ok.
<lekernel>
I was sure ipv6 was a hot subject with roh :-)
<wpwrak>
roh: has "not working properly" ever prevented something from being deployed in the real world ? ;-)
<roh>
wpwrak: yes. if working is making payment possible, it does.
<roh>
lekernel: dont get me wrong. i dont 'like' some things on v6 either. but there is no fsckin way around or ignoring it. its be compatible or bust this year.
<roh>
my laserprinter speaks v6. just as an example.
<roh>
some used lexmark office device
<wpwrak>
i remember the ietf meeting in san jose 1994. my first. there, everybody seemed to agree that ipv6 was ready now and that wide deployment was imminent. people were also very excited about doing it.
<wpwrak>
then they figured they needed a few little design changes. poof, the hype blew away.
<roh>
wpwrak: well.. we used it some years now and have native access in hosting centers too. this year is the one where we NEED to mass-deploy.
<roh>
the last /8 blocks are gone. its 'till the tank is dry' now.
<wpwrak>
now we have an installed base that's several orders of magnitudes larger. everything that looked difficult back then is a nightmare nowadays.
<wpwrak>
roh: what's happening now is that people are selling unused ipv4 addresses. there's a lot of these. of course, this will mess up the routing horribly ...
<roh>
wpwrak: not a problem. most of the infrastructure is replaced periodically anyhow.
<roh>
e.g. the cores in amsix are usually 'the freshest shit alive' ... simply because they cannot use last years interfaces (they are using 100gbit fibre links now) the first ones on the planet in production use
<roh>
wpwrak: selling is bs.
<roh>
wpwrak: only pi is transferabble at all.. and also only in blocks >/23.
<roh>
/24 is already filtered at a lot of places to keep the tables small enough for ram
<wpwrak>
roh: eventually, everything gets replaced, true. yet there were places in the late 1980es that still used pdp-11 for critical tasks ... :)
<roh>
so yes.. there will be some grey market. but that will dry up, since you cannot sell a pa.
<roh>
wpwrak: these dont use ip usually.
<wpwrak>
don't underestimate the pdp-11 ;-)
<roh>
wpwrak: there is x25 in missioncritivcal use also.. for banking...
<roh>
wpwrak: also its a bad argument to say 'there is old stuff belonging into a museum still being used' .. well.. yes.. do you want to belong to it?
<roh>
ofcourse not.
<roh>
my point is: selling something with no v6 will be hard in <1 year. every plastic applicance will be compatible
<roh>
bbl
<aw>
lekernel, i think that now we are safe on 2A fuse and 5.6V Zener. :-)
<lekernel>
ok, the only two points that I care about is 1. no current consumed between 4.75V and 5.25V 2. acceptable voltage drop
<lekernel>
reading your table #1 is OK
<lekernel>
#2 => what's the difference between "Zener Voltage" and "Voltage of symbol 5V marked on M1 RC2"? the two are supposed to be connected, no?
<aw>
first "Zener Voltage" is measured by its two terminal by Agilent 34401A.
<aw>
"Voltage of symbol 5V marked on M1 RC2" is the measured results by probing C138's two pads.
<lekernel>
ok well
<lekernel>
weird
<lekernel>
but go ahead
<lekernel>
the protection circuit won't be hard to rework out if we get problems with it
<aw>
your care about current consumed between 4.75 ~ 5.25V is okay on table 1(NO LOAD), there's only 0.74A when works on LOADs. :-)
<lekernel>
yes
<aw>
yes
<wolfspraul>
btw xiangfu mentioned to me today he thinks the ftdi 2232h gets very hot when being used
<lekernel>
are you done with the schematics?
<wolfspraul>
maybe not too hot, don't know. but hot :-)
<lekernel>
wolfspraul: I don't have such a problem ...
<lekernel>
actually mine has been continuously connected on USB for a few days now and it still works and cold
<lekernel>
aw: how are the schematics going?
<aw>
lekernel, yes, done. but I wait for house's reply. should next week I'll send to list and even started to route some.
<lekernel>
ok, please send them now for review
<wolfspraul>
so our USB 5V is not actually 5V now? it's more like 4.7-4.8 or so?
<aw>
lekernel, sorry that I've uploaded the schematic.
<aw>
have not uploaded...
<aw>
wolfspraul, correct...a little bit lower.
<wolfspraul>
4.65 in the table
<wolfspraul>
and that is OK?
<aw>
works on my keyboard and two mousers.
<wolfspraul>
I'm a bit worried that you say you tested your 2-3 keyboards and mice and they work so we are fine :-)
<wolfspraul>
sounds like a small sample
<wolfspraul>
well there are thousands of USB devices
<aw>
yes, that's why I told you that send me some keyboards when you surveyed done.
<lekernel>
wolfspraul: the value does not make sense. at 0.73A, the voltage drop from the fuse should be only 0.73*0.07 = .0511V
<aw>
yeah...very little now though.
<lekernel>
so how come you get 4.413V (i.e. 0.337V drop)?
<wolfspraul>
no wait. we cannot randomly plug in a few keyboards and then conclude that it's fine. I'm sure there is a USB spec.
<aw>
when facing PTC fuse, you can not just deduct the drop voltage.
<wolfspraul>
what does the spec require?
<lekernel>
aw: it says 0.07 ohm, no?
<aw>
lekernel, yes
<lekernel>
wolfspraul: 4.75 to 5.25V
<lekernel>
aw: so? when you multiply the current by 0.07, you get the dropped voltage
<kristianpaul>
hot yes
<lekernel>
no?
<aw>
lekernel, you needs to read PTC curve firstly.
<kristianpaul>
i tought it was heat coming from board been disipated..
<kristianpaul>
but dint tested or measure further
<aw>
when huge current goes through PTC fuse firstly, the material starts to get bigger resistance more gradually.
<aw>
not you only calculate always 0.07. :-)
<lekernel>
of course 0.07 is an approximation. now what matters is under what conditions it is valid.
<lekernel>
I was assuming that in a normal temperature range, say, under 50 degrees, the approximation was valid
<lekernel>
but I might be wrong, in that case those PTC fuses are crap
<aw>
wait....let me measured some chips's temparatures,, so everyone can imagine though :-)
<wolfspraul>
I think we need to get USB 5V up a little, 4.65 sounds not good
<lekernel>
aw: fuse datasheet says resistance is between 0.02 ohm and 0.07 ohm at 20 degrees, so it's a bit weird you get almost 10 times that
<lekernel>
even at 30 degrees or so
<aw>
lekernel, becuase we have Zener's body temperature with close to fuse's body. so its surrounding area temperature is a fewer high.
<aw>
that's the reasons that I got higher temperatures.
<aw>
i always have two column temperatures. ( fuse and Zener )
<lekernel>
aw: reminder: between 4.75V and 5.25V the current through the zener is zero. therefore the dissipated power is zero as well, and the temperature increase also zero
<lekernel>
if the zener heats with those voltages, either the heat comes from somewhere else or you're doing something wrong
<aw>
reasonable on your theoretically assumption
<aw>
but from table one, it indeeds.
<aw>
table two is the two parts I soldered them on board nearby U13 and L10. so this is practical.
<aw>
so now my 2A DC power supply: PTC fuse (33.4), Zener (36.9), U13 (35.2), FPGA (35.2), U10 (39.6)
<lekernel>
aw: let's have a look at this _after_ the rc3, ok?
<lekernel>
I propose we don't implement the protection circuit now
<aw>
with this real DC adapter which won't be act as my laboratory power supply on strong output driven current out.
<lekernel>
aw: do you agree we should not implement the protection circuit in the rc3 boards and we have a calm look at it later?
<aw>
lekernel, wolfspraul well  seems that you don't want this patch, actually me either. I'd rather to use NS LNZ12002.
<aw>
but this is really tough situation if we can determine now.
<lekernel>
huh, what's NS LNZ12002?
<wolfspraul>
aw: why do you not want it?
<wolfspraul>
the voltage drop that cannot be explained right now?
<aw>
the real reality is existed there that I did indeed really not test many keyboards, and mouser, although there's only 4.413 V on mine, but others I don't know and this's not meet USB spec.
<lekernel>
4.413 V is _WRONG_. period
<lekernel>
no matter if it works with your USB devices
<aw>
lekernel, surely
<lekernel>
it's too much voltage drop, which is what wolfspraul was saying
<lekernel>
so, do you agree to leave that protection circuit for later?
<aw>
if both of you said that can't accept this, I'd say 5.6V breakdown is also over USB spec.
<lekernel>
....
<aw>
i don't think that I have time to do such things though, I agreed that not to do this in rc3.
<lekernel>
I told you already that we don't really care about what the board does when run with inappropriate voltage
<lekernel>
but it's extremely important that it works well with the specified voltage
<lekernel>
ok, so we don't do it. case closed.
<wolfspraul>
:-)
<wolfspraul>
wait too fast for me
<wolfspraul>
aw: what do you want to do now?
<aw>
in h/w, there's too linear case not only logically think though.
<wolfspraul>
you mean with the 5.6v zeners we have a (currently unexplained) voltage drop that brings the USB voltage out-of-spec
<wolfspraul>
I think we all agree USB voltage < 4.75 is not acceptable. that's easy.
<wolfspraul>
so like lekernel said - do we want to investigate the voltage drop, or just go back to rc2 altogether? :-)
<aw>
I was thought that I'd like to use regulator to do all protections, if we WANT to only 5V +/-5% DC adapter, then NOW I decide that let don't implement protection in rc3.
<lekernel>
wolfspraul: keep in mind that adding this circuit also paves the way for layout nightmares
<lekernel>
if the layout gets this messy, the rc3 will be in duke nukem forever mode
<wpwrak>
(usb spec) there is ;-) usb_20_081810.zip, file usb_20.pdf, page 175
<aw>
h/w tasks:Â Â you guys thinking are also strange though.
<wolfspraul>
difficult decision. I can only say USB spec is important.
<wolfspraul>
if the voltage drop cannot be explained now, and Adam feels good about his numbers, then sure maybe the best idea is to not do the new circuit at all
<wolfspraul>
I have no problem with that, we surely tried...
<aw>
wait...
<wolfspraul>
maybe Adam wants to sleep over it, confirm the numbers tomorrow or Monday, and if everything stays the same he makes the final call.
<aw>
let's see good stuffs on wpwrak 's link
<aw>
wpwrak, thanks a lot, i am reading "usb_20.pdf" file,
<aw>
let's open it all together.
<lekernel>
aw: I sum up the important parts of that link for you: USB voltage has to be between 4.75 and 5.25 volts, and a USB device can draw up to 500mA current. all the rest you can skip for our purposes.
<aw>
see page 175,
<wpwrak>
lekernel: correct (that is, for a "high-powered" port)
<aw>
wpwrak, for a "high-powered" port
<wpwrak>
lekernel: if all you care about are mice and keyboards, you need less
<aw>
but how about "worse case"
<wolfspraul>
no no. we want a full usb host ports here.
<wolfspraul>
two rather
<wolfspraul>
there is no need to talk ourselves into 'crappy usb is enough for us' mode
<wpwrak>
aw: figure 7-47 shows: highh-powered hub/port, then a bus-powered hub, and finally a low-powered device
<aw>
wpwrak, yes, go on.
<wolfspraul>
the voltages as measured in Adam's last round are too low
<wpwrak>
aw: e.g., pc -- cheap bus-powered hub -- mouse
<aw>
wpwrak, listening..
<lekernel>
we want full featured USB ports, which means a voltage between 4.75 and 5.25 and a capability for currents up to 500mA.
<lekernel>
</noise>
<wpwrak>
aw: so this shows what lekernel said: you need a minimum of 4.75 V for a high-powered port
<wolfspraul>
I'll read the backlog, hopefully it's not too long :-) n8 everybody...
<lekernel>
gn8
<wpwrak>
the real problem seems to be the reliance on a "perfect" external power supply and magically lossless conductors. would it be so hard to just add a regulator for 5 V and supply the system with a higher voltage ?
<lekernel>
yes
<aw>
wpwrak, lekernel hm..okay..so then I can't gather even fine tune fuse with Zener to meet this 4.75V which if we want to use a DC adapter with minimum 4.75V out from adapter.
<wpwrak>
(and the protection circuit is just another "magically lossless" conductor :)
<lekernel>
wpwrak: it's not, but small voltage drops are acceptable
<aw>
there's quite hard to get there to have no drop and also take dissipation.
<lekernel>
no, it shouldn't be. if the fuse is only 0.02 ohm to 0.07 it should work without much fuss.
<lekernel>
but let's have a look at this later
<aw>
lekernel, yes...the fine tune is really needs time and need to have real soldering together on board to have that test.
<wpwrak>
how many rc3 do you plan to make ? just a few ?
<lekernel>
aw: i'll reproduce your experiments on my side and then we talk
<aw>
so now I agreed that we don't implement this protection on rc3.
<lekernel>
ok, good
<lekernel>
wpwrak: 80
<lekernel>
aw: can you send me the schematics?
<lekernel>
i'll review the other stuff: audio, etc.
<wpwrak>
okay, not that many. won't kill anyone to deal with the ones that get fried
<aw>
yes, i can send you now.
<lekernel>
wpwrak: exactly zero board has been fried in our run of 40
<aw>
but don't check their footprints then...
<wpwrak>
btw, are the schematics still in some proprietary format ?
<lekernel>
yes
<lekernel>
aw: understood, I just want to verify the schematics now
<aw>
lekernel, okay. :-)
<lekernel>
do we have any footprint modification anyway?
<wpwrak>
lekernel: (zero fried so far) yes, but as you said, something like 80% are safely in a drawer and the rest are in the hands of people who know enough about electronics to be careful. that luck won't last forever (i hope ;-)
<aw>
lekernel, footprint have not all linked together though on added or modified parts.
<aw>
lekernel, pre-rc3 sch sent. :-)
<lekernel>
ok, thanks!
<aw>
first forget about fuse & zener in power though.
<lekernel>
ok I got something
<lekernel>
100mV voltage drop between input and USB port on RC2 but not on RC1
<lekernel>
actually I only tested that on the RC1 before
<aw>
at the "5V" net?
<lekernel>
yes
<lekernel>
did you use a different source for ferrite beads between rc1 and rc2?
<aw>
no, bead is the same I used in both.
<lekernel>
wtf ...
<aw>
but you can just to swap them to confirm that if this is for 100mV
<lekernel>
sure
<lekernel>
or just measure the voltage across. easier...
<aw>
i'll also confirm here.
<aw>
if really discover an extrusion of 100mV, it would be good news.
<lekernel>
there is definitely such a voltage drop
<lekernel>
it's clearly measurable
<lekernel>
and increases with current consumption
<aw>
yeah...constantly we needs at least 0.74A minimum.
<lekernel>
so there's a parasitic resistance somewhere in rc2 we don't have on rc1
<aw>
the more use the more drops.
<aw>
hmm...interesting.
<lekernel>
which fully explains your incorrect voltage measurements
<aw>
we have only two kinds bead on board
<aw>
1206 and 0402 footprints i remembered.
<lekernel>
yeah yeah we're talking about the 1206 ones here
<lekernel>
ok it's those fucking beads
<lekernel>
aw: just measure the voltage across them. you'll see.
<wpwrak>
lekernel: (round traces) there are some layout programs that do this sort of shortest trace routing. looks weird but may actually be better than the usual 45 deg pattern
<wpwrak>
lekernel: (schhist) there are many steps. it's kicad .sch -> ps -> ppm -> diff
<wpwrak>
lekernel: plus there's all the version tracking and stuff
<wpwrak>
lekernel: if you want just the graphical diff, you could take a ps or pdf, convert it with ghostscript to ppm, and then use eda-tools/schhist/ppmdiff/
<wpwrak>
lekernel: eda-tools/schhist/schps2ppm would be an example for how to convert from ps to ppm