kicad-developers team mailing list archive

["�vind Aabling" <Oyvind.Aabling@xxxxxxxx>]

A few more components at http://www.uni-c.dtu.dk/~univind/kicad/

This time, I've added the diode bridges (named BR-*), and
I think a few others, but as it's been a while since my
last announcement, I can't really remember which ones :-(

I know that I've been a bit quiet lately (been busy with other
stuff :-), will try and find some more time for KiCad ...


There is an issue with the pin numbering on the diode bridges:

I've turned the square and circular bridges (BR-GBPC*, BR-KBPC*, BR-WOB
and BR-WOG), so that the pin numbers matches the eeschema BRIDGE device
(1=minus, 3=plus, 2+4=AC), but on all the others (the SIL bridges),
the pins are currently numbered in order, which doesn't match eeschema.

The long-term solution is to provide a mapping from pin function
to number, as has been discussed before (and lots of components
will benefit from that), but what should I do now ?

I can either keep the numbering as is (which could cause some
confusion and some blown components, I think), or I could change
the pin numbers to match eeschema - the question is: Are bridge
devices special enough to warrant an out-of-order pin numbering ?

I would vote yes, as these components (in contrast to lost of other
component houses) are used for bridges only, but what do you guys think ?


I _have_ gotten a few other things done for KiCad, and one of
them is adding an annotated 3D outline for each component.

These aren't really useful for KiCad as such, but they're great for
checking corner indices when doing complicated shapes, and when
looking for strange faces (out-of-order corners) during devel :-)

As they're only useful for devel, I haven't added the outlines to the
tarball, but they're available from the URL, in the outline subdir.

The KiCad 3D viewer can't do VRML IndexedLineSet or text, so
the outlines must be viewed in some other VRML browser/editor.

I use whitedune, but it needs a simple patch (available under the URL
as whitedune.patch), otherwise the corner and face index texts won't
be shown (but you'll get lots of nice "Font not found" messages).


On another note, I've also been looking further into
the problem that I've had with the KiCad 3D viewer on
the new (3D-not-yet-supported) ATI gfx card at home.

It looks like the code path in the X client (and thus in the X server)
is totally different when using the GL Software Rasterizer -
there are lots (thousands) of calls to XGetImage on the 3D window.
Apparantly, the're used for syncing instead of using XFlush or XSync.

With H/W accelerated GL, there isn't a
single XGetImage call (on the 3D window).

I've looked at the X server / ATI driver code and the output from xtrace:
The 3D window appears to be of the correct type (input-output), and all
the XGetImage calls have X,Y coords within the window and width=height=1,
so why the X server returns a BadMatch is (still) a mystery to me.

Adding a (single) call to gdk_error_trap_push got rid of the annoying
crash, but the 3D window still looked weird - objects looked as if turned
inside-out, or surfaces in front got hidden by surfaces behind ...

I don't know which universe behaves like
that, but it certainly isn't this one ;-)

That was the bad news, but the good news is, that one of the things that
has taken up my time lately is a switch from 32-bit to 64-bit Debian.

That change has removed the problem, both in the bzr release
(latest fetched: 2403 on 20/6) and the Debian compiled kicad !-)

The switch to 64-bit also caused a minor version update of the
X server (and drivers), so either that's the reason, or there's
a subtle bug in the X server code (32-bit vs. 64-bit issue ?).
I don't know which, but I'm not going to bother finding out now -
better get on with some more parts, now that I can see what I'm doing :-)


Now at 908 parts, 6729 lines of code.

Øyvind.