Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<mirko>
and they will only work when the xburst kernel patches are applied (implies the xburst target is selected)
<mirko>
so it doesn't make sense to put them into package/kernel/modules/ but should go into own packages which depend on the xburst target
<wolfspraul>
mirko: that's the wpan stuff - ben specific?
<wolfspraul>
where do you want to have it in the tree?
<wolfspraul>
the 802.15.4 stuff is meant to go into kernel.org, not ben-specific I think
<wolfspraul>
you could plug an atusb into any router with usb...
<wolfspraul>
ok I think you want this as an individual package, same as the other apps
<wolfspraul>
can it still be compiled into the kernel statically then? as long as that's the case of course we can move it over to the qi packages
<wolfspraul>
so your choice: kernel module or qi package. I think kernel module makes more sense, especially given what the wpan project aims for and is working on.
<wolfspraul>
lindi-: do you have a feeling/guess/knowledge who is using it?
kristianpaul has joined #qi-hardware
MabYwen has joined #qi-hardware
MabYwen has quit [#qi-hardware]
<lindi->
wpwrak: I am :)
<cladamw>
wpwrak, i just manually fixed *.lib :-)
<cladamw>
wpwrak, it lost one line. :-)
<lindi->
wolfspraul: I just got sick of having wiki.debian.org point people to random websites to download bootloader binaries
<wolfspraul>
sure, it's good
<cladamw>
wpwrak, I created two empty but only have rectangle multi-parts and then compared two multi-parts library http://dpaste.com/726195/ the line "S -1150 2700 1250 -2800 1 1 0 N" was lost. :-)
<wolfspraul>
I'm a little worn out with Debian packages, although I very much recognize the enormously important work happening there
<wolfspraul>
it took 1.5 years or so to get xburst-tools in, and I think it will be removed again due to cross-compilation issues
<wolfspraul>
:-)
<wolfspraul>
well then
<wolfspraul>
the one thing I looked for recently and could not find was a debian package for openscad
<cladamw>
wpwrak, it makes me remembered that deleted the rectangle block in FIRST sub-part. then eeschema confuses/or can't handle such deleted act in FIRST sub-part, then no matter whatever I tried to draw new rectangle in which sub-part will ALWAYS add into all else sub-part. It's a BUG in eechema. ;-)
<kristianpaul>
too early, but at least there is now a opencsg
<kristianpaul>
about openscad
<mirko>
wolfspraul: well, the wpan-stuff depends on TARGET_xburst - at elast what xiangfu sent me
<mirko>
spi_atben definitely is ben specific
<mirko>
WHEN it is not xburst-specific, the kernel patches need to go into the 'generic patches' directory
<mirko>
otherwise they only get applied, when the xburst target is selected
<mirko>
this way they won't be available for other platforms than xburst
<mirko>
so, either it's xburst-specific: patches need to be target-specific, packages should be usual packages (not package/kernel/modules)
<mirko>
or the patches are generic (applied for all targets) and do not depend on a particular target/architecture, then they could go into package/kernel/modules
<mirko>
right now - looking at the patch - it's mixed up
<mirko>
i've no problem committing the wpan-stuff for all targets
<mirko>
which implies generic WPAN stuff needs to be extracted from the xburst-specific patches and converted into generic ones (referring to drivers/ieee802154/* in particular)
DocScrutinizer2 has joined #qi-hardware
<larsc>
mirko: pong
<wolfspraul>
mirko: perfect, I got it. so mostly you care that the builds and dependencies are consistent
<wolfspraul>
I will find out whether we see wpan more ben-specific or more kernel-generic, and then you should get an updated patchset tomorrow
<wolfspraul>
thanks for feedback!
<wpwrak>
the atben drivers are definitely ben-specific. atusb and the rest of the stack (from linux-zigbee) aren't.
<wpwrak>
well, driver(s). one variant replaced the other.
Martix has joined #qi-hardware
pabs3 has joined #qi-hardware
cladamw has joined #qi-hardware
<wpwrak>
cladamw: (lines in the wrong part) are you sure the part/body switch was set correctly ? i think, when you restart the component editor, it'll reset
<wpwrak>
cladamw: (wm9707scf rename) is that the only part wolfson produce ? :)
<cladamw>
wpwrak, yes, i was sure 'locked' switch was checked. ;-)
<cladamw>
wpwrak, once you deleted FIRST rectangle in first sub-part, you run into this problem.
<wpwrak>
(locked) i mean "Edit pins per part"
<cladamw>
wpwrak, i'd prefer to use wolfson. ;-)
<cladamw>
yes, it's locked.
<cladamw>
you can use Editor to delete it first then try it. ;-)
<cladamw>
wpwrak, i can easily reproduce the bug now. ;-)
jekhor has joined #qi-hardware
<wpwrak>
(wolfson) what i mean is that things get messy if more wolfson chips get added since git can't track changes inside a .lib file. so all the changes to one part will appear to affect all the wolfson chips
<cladamw>
once you deleted rectangle in first sub-part.
<cladamw>
no, i noticed that git can track changed codes inside *.lib , are you sure ?
<wpwrak>
(rectangle) seems that the flag doens't affect drawings
<mirko>
wolfspraul: welcome :)
<wpwrak>
(.lib) what i mean is that you can't search for changes of, say, only the wm9707scft in a .lib if there are other things in there
<cladamw>
yes, flag doesn't affect it. but if you switch to else sub-part, you can see your all changes go to else sub-part. :-)
<wpwrak>
cladamw: if you keep one component per lib, then you can git log wm9707scft.lib and see the revision history of that part
<cladamw>
okay. have not used git log though. i try it. :)
<wpwrak>
(git) similar with other commands
<wpwrak>
(rectangle) if you double-click on it, you get a pop-up with a "Shared by all parts in component" checkbox. that one seems to do the trick.
<cladamw>
oah..yeah...that one i knew. :-)
<wpwrak>
so this solves the problem ? or do deletes still affect other parts if you un-check "Shared ..." ?
<cladamw>
but i meant once you deleted rectangle in first sub-part, then draw a new rectangle still in first sub-part, then switch to else sub-part, you will see the new rectangle is all existed there, which is not the need we want. no matter what you checked "Edit pins per part" or not. :-)
<cladamw>
yes, i added one line after comparing those two empty *.lib, then try a while, now it's okay.
<cladamw>
inserted one line in lib.
<wpwrak>
i'm confused :)
<wpwrak>
does the "one line" refer to the rectangle problem ? or are you talking about something else ?
<cladamw>
let me git push the new spartan-6 then later you can follow my steps above, you will see. :-)
<wpwrak>
you have "Shared by all parts in component" set
<cladamw>
wpwrak, 1 - make you that's checked 2 - delete rectagnle in part A 3 - re-draw a new rectangle 4 - switch to other part [B:F], see there's a new rectangle on there. It's wrong 5. added one line as i posted earlier then fixed.
<wpwrak>
move the mouse over the edge of the rectangle, then press E
<wpwrak>
then you'll get a dialog with a checkbox "Shared by all parts in component"
<wpwrak>
if there's an [X], the rectangle will appear in all parts. if you click to change it to [ ], it won't be shared (as far as i can tell)
<cladamw>
you meant that "Apply changes to all parts in components" ?
<wpwrak>
which verion of kicad are you using ?
<wpwrak>
verSion
<cladamw>
arh ? your dialog msg isn't same as mine ?
<wpwrak>
i don't know :)
<cladamw>
Build: (2010-08-11 BZR 2448)-unstable
<wpwrak>
i have 2012-03-20 BZR 3482
<wpwrak>
okay, so some things may be different
<cladamw>
oah...man!
<cladamw>
nice ! yours are super new though. :-)
<wpwrak>
ah, ignore the date. that's just when i compiled it
<cladamw>
well...nevermind now on my problems. let's ignore it now.
<cladamw>
well....so how do i install yours ?
<wpwrak>
or wait .. no, that's actually from then. hmm
<wpwrak>
lemme clean up my stuff :)
<wpwrak>
it should be BZR 3378. but that's still newer than what you have
<cladamw>
yeah...but it's safe on my site now. since I'll super carefully on editing multi-part. but no more such part needed to create now. haha...
<wpwrak>
seem that kicad's build process uses the information from the latest commit not from the one checked out.
<cladamw>
(electrical type of pin properties) wpwrak btw, although I git pushed lib, but may few of those pins are not set well though. It's quite a lot of check works. I think in DRC stage I'll meet err then. :-)
<whitequark>
mth: the problem with compression is, you can't compress screen contents fast and efficiently
<whitequark>
you need a good hardware encoder, a good hardware decoder and it still will lag on some patterns
<mth>
if you don't care about efficiency too much, you can compress it quickly though
<whitequark>
but you need to fit hd to 480mbit
<whitequark>
through it probably does not do 60hz
<mth>
compress every frame as JPEG image?
<whitequark>
ffuuuu~~~
<whitequark>
not to mention that jpeg is surprisingly costly for such a crappy algorithm
<whitequark>
and the hw I have definitely does not do jpeg
<whitequark>
nor it does any other kind of lossy compression
<mth>
since the PC side is USB, the compression has to be done by the driver, so it's likely not hardware accelerated, or at least not accelerated by this adapter (it could use the GPU)
<whitequark>
larsc: huh, interesting, thanks for the link
<larsc>
GNUtoo: try to ping the maintainer again
<larsc>
patches sometimes get overlooked
<GNUtoo>
ok
<GNUtoo>
thanks
<whitequark>
DocScrutinizer2: (qualcomm-atheros)
<whitequark>
UPDATE: I have been contacted by Qualcomm PR regarding this expected presentation next week. The content of the Qualcomm Atheros developers was not approved by Qualcomm's legal department and the views to be expressed will be of their own personal beliefs.
<DocScrutinizer>
hmm?
<DocScrutinizer>
aah
<DocScrutinizer>
what presentation though?
<DocScrutinizer>
larsc: actually the 5th pin just indicates whether this is an A or a B plug
<DocScrutinizer>
which arguably implies some general indication what the other end of cable might look like, and this which remote device
<DocScrutinizer>
short to GND = A, open = B, some resistor indicates fastcharger, or charging Y-cable setup for charging A-OTG host
<DocScrutinizer>
some ultraweird "standard" is using ID pin as *output* to control chargers
<DocScrutinizer>
or somesuch
<whitequark>
DocScrutinizer: they [Atheros guys] presented their thoughts in a form of a presentation
<whitequark>
maybe want to speak at some conf
<DocScrutinizer>
and some very tricky battery dongles seem to use ID pin as anohter power-in or -out
<DocScrutinizer>
ooh, those "nuke all proprietary drivers zealots?"
<whitequark>
yeah
<DocScrutinizer>
hahaha
<whitequark>
but maybe it's the same as some Samsung employees giving away a lot of internal docs without any NDAs or similar shit
<DocScrutinizer>
now either they get twice the wages, or they are already fired
<whitequark>
just because they couldn't do it officially
<whitequark>
hehe
<DocScrutinizer>
whitequark: are those dudes relatives of me? ;-D
<whitequark>
DocScrutinizer: no idea, I didn't talk to them, just heard on #replicant
<whitequark>
Ingenic folks tend to do the same
<whitequark>
e.g. they sent us a full minios source tree
<DocScrutinizer>
OM folks too ;-)
<whitequark>
well
<whitequark>
are they supposed to be proprietary?..
<DocScrutinizer>
hough there's not much closed stuff inside OM
<DocScrutinizer>
some crappy calypso GSM stack, 90% binary libs, already 'leaked' by somebody else
<DocScrutinizer>
some glamo docs that meanswhile are semi-public
<DocScrutinizer>
dunno shit about atheros wl6001 or whatever WLAN firmware
<DocScrutinizer>
but that's no APE land blob anyway (neither is modem)
jekhor has joined #qi-hardware
<whitequark>
well, given that some pre-android motorola actually had a probe in the wlan firmware...
<whitequark>
I would care about this stuff
<DocScrutinizer>
and I think there actually were some accidentally publicly accessable schematics where the calypso modem pages didn't lack
<DocScrutinizer>
probe?
<whitequark>
like you cannot sandpaper the board and reverse-engineer that layout anyway
<whitequark>
hm
<whitequark>
you could ICMP it
<whitequark>
and it would happily relay all traffic to whoever had sent the secret ICMP
<DocScrutinizer>
ooh
<DocScrutinizer>
nice
<whitequark>
no "verifiable" (in terms of wikipedia) source, but I pretty much sure that there was
<Aylax->
Somebody highlighted me here?
<DocScrutinizer>
would show immediately on my monitored and logged WLAN AP
<whitequark>
DocScrutinizer: and now you're saying you are not paranoid ;)
<DocScrutinizer>
I am just laughing at paranoids, they always are so helpless
<whitequark>
maybe paranoidness should be measured on a logarithmic scale
<whitequark>
most people are at -1
<whitequark>
I'm, dunno, maybe at 3
<whitequark>
then you are at 8.
<whitequark>
or measure it in decibels
<whitequark>
80 dBp!
<DocScrutinizer>
look, the diff between me and a paranoid is: I'm enjoying it
<DocScrutinizer>
I'm eager to see some attack
<DocScrutinizer>
so I got something to laugh and to fight and to investigate
<whitequark>
oh, I understand it
<whitequark>
but all this should eat a lot of time, no?
<DocScrutinizer>
and damn, if the dude is really really *really* good, he might take my browser history and I'm not scared at all, just respectful for a really great hacker
<DocScrutinizer>
and all that takes just as much time as I can spend on it
<DocScrutinizer>
often less
<whitequark>
that's sole reason I'm not doing similar things. I do things which don't require constant attention from you, or require you to understand loads of bullshit you'll forget anyway and then screw up something important
<DocScrutinizer>
hehe
<DocScrutinizer>
well, probably you got a life
<DocScrutinizer>
i'm not that sure about me in that regard
<whitequark>
so I have SSH and passphrases on _really_ important things (other ones just go in KeePassX), and even an encrypted VM for _really really_ important things
<whitequark>
but heck, to monitor AP logs?! no no no
<whitequark>
daily logwatch from 2+ servers is more than enough
<DocScrutinizer>
apropos, have to check my own box' munin
<whitequark>
(got a life) probably not. as I recently understood, I wake up, stare at the screen, go to screen.
<whitequark>
sometimes even eat.
<whitequark>
*go to sleep.
<DocScrutinizer>
go to work, return to screen, switch screen, go to sleep
<DocScrutinizer>
not that "work" means anything but "stare atyet another screen"
<DocScrutinizer>
WITH WIN-XP!!!!!!
<whitequark>
nah, I can work at home
<DocScrutinizer>
*BLAERGH!!*
<whitequark>
(winxp) interestingly, I'm way more irritated by win7 or gnome3 or osx than winxp
<DocScrutinizer>
VISTA
<DocScrutinizer>
and now that new shit
<DocScrutinizer>
coming up
<whitequark>
win8, yes
<DocScrutinizer>
the embedded desktop for desktops
<whitequark>
far worse than anything which happened before
<whitequark>
I tried beta
<DocScrutinizer>
indeed
<DocScrutinizer>
hope it will kill them
<whitequark>
apart from the fact that it BSODs endlessly in VMs
<whitequark>
it has a REALLY SHITTY interface
<DocScrutinizer>
definitely
<whitequark>
orders of magnitude more shitty than vista
<DocScrutinizer>
magnitudes shittier than even wind2.0
<DocScrutinizer>
-d
<whitequark>
like if someone at MS thought "tablets are cool, let's pretend desktops are tablets"
<DocScrutinizer>
exactly
<whitequark>
and put all those GIANT BUTTONS
<whitequark>
and removed all the compat
<whitequark>
fuck him
<DocScrutinizer>
monster idiots
<whitequark>
and fuck tablets. there's no device humanity created that is less useful than a tablet
<DocScrutinizer>
well, a good reason to refuse ever again touching that stuff, even for earning a living
<whitequark>
(touching) you have to touch it to toss it to garbage
kilae_ has joined #qi-hardware
<whitequark>
or maybe you could use a hazmat suit
<DocScrutinizer>
figure a tablet on desk of boss' secretary ;-P
<whitequark>
you need: 1 (one) hammer, 1 (one) nail (optional)
<DocScrutinizer>
"Ms Jones, could you please write that letter til 2'o?"
<DocScrutinizer>
BWAHAHA
<whitequark>
lol
<whitequark>
how much hours did it take?
<whitequark>
is she done yet?
<DocScrutinizer>
with win8 M$ abandoned office usecase
<whitequark>
well I don't really understand
shevek has joined #qi-hardware
<whitequark>
is win8 "the next windows"?
<DocScrutinizer>
the ONLY market niche they were relevant in
<whitequark>
are they pretending that everyone should now use that? no, seriously?
<DocScrutinizer>
well, it's their next windows
<whitequark>
is it even compatible with old apps at all?
<DocScrutinizer>
there's no other next M$-OS
<DocScrutinizer>
dunno
<DocScrutinizer>
are ribbons in M$-office any compatible to anybody used to menus?
<whitequark>
oh
<DocScrutinizer>
I curse it every single day, at work
<whitequark>
they put MORE RIBBONS to it
<whitequark>
to Explorer
<whitequark>
did they accidentally hire someone to destroy them from inside?..
<DocScrutinizer>
honestly since ribbons even excel shit takes 5 min for the real work, plus 2h for searching how to do that work
<whitequark>
2. No more digging around for options through menus and submenus – There are approximately 200 commands on the new Windows 8 Explorer UI, even hidden features that would otherwise sit unused.
<whitequark>
does he understand what he says _at all_?
<DocScrutinizer>
nah, the first picture already made my eyes bleed
<whitequark>
I should have pixelized it
<whitequark>
you know, like in porn
<whitequark>
or maybe the other way around. anyway, you got the idea
<DocScrutinizer>
sure
<DocScrutinizer>
a few days ago I wondered how T major F you do conditional formatting in excel2007. Found out there's a way to add a "menu" to window bar, via "system"-"preferences"
<DocScrutinizer>
DIE!!! M$ DIE!!!
<larsc>
we should get you a bill gates voodoo doll ;)
<whitequark>
so much hate :D
<larsc>
GNUtoo: btw. you should send the patch to the maintainer with the list in cc
<GNUtoo>
that's what I did
<GNUtoo>
I guess it just doesn't show up in the list
<GNUtoo>
*gmane
<GNUtoo>
I sent TO Ben Dooks
<larsc>
ok. i only had one mail from you in my inbox which only had the mailinglist not the maintainer
<GNUtoo>
and CC the list
<GNUtoo>
+ other people
<GNUtoo>
yes that's why I [RESENT] it
<GNUtoo>
It was early the morning
<GNUtoo>
and I wasn't awake
<larsc>
ben dooks has been quite quiet over the last few weeks
<GNUtoo>
and I forgott to do ./script/get-maintainer.pl
<larsc>
s/weeks/years/
<qi-bot>
larsc meant: "ben dooks has been quite quiet over the last few years"
<GNUtoo>
so I resent
<GNUtoo>
ouch
<GNUtoo>
so who should I send to?
<larsc>
try to ping Kukjin Kim
<larsc>
he is usually responsive
<GNUtoo>
ok thanks a lot!!!!
<GNUtoo>
altough there is a problem in get-maintainer.pl or MAINTAINERS...since it always give me ben dooks
<whitequark>
>Qualcomm Atheros, Inc. have also provided source code and documentation under an NDA which allows for contribution back to an open source project.
<larsc>
it's always good when development overrules PR ;)
<GNUtoo>
whitequark, what about the firmwares (ath9k_htc)
paroneayea has joined #qi-hardware
Aylax has joined #qi-hardware
capiscuas has joined #qi-hardware
capiscuas has joined #qi-hardware
capiscuas has joined #qi-hardware
<whitequark>
GNUtoo: no idea
<GNUtoo>
ok
<GNUtoo>
because the status of free firmwares is even worse than the free drivers
<GNUtoo>
for wifi we have openfwwf for old b43 cards and carl something for an atheros card
<GNUtoo>
and I think that's all
<GNUtoo>
so no free firmwares for embedded devices
<GNUtoo>
(and for graphic card I think nouveau also does the firmwares so it's free for nouveau if I remember well)
<GNUtoo>
I hope lima comes up with something
<GNUtoo>
for embedded devices
emeb has joined #qi-hardware
<GNUtoo>
sigh
<GNUtoo>
alsa.....
<wpwrak>
hmm, we really ought to have some pre-built toolchains for the ben. the setup process is rather nightmareish. and jlime only has an i386 version which doesn't work on ubuntu onerous
<shevek>
Doesn't the one from emdebian work?
<GNUtoo>
oops wrong channel about alsa
<wpwrak>
shevek: with the target system running openwrt or jlime ?
<whitequark>
wpwrak: crosstool-ng sets up some pretty statically built toolchains
<whitequark>
they're filesystem relocatable
<whitequark>
that is, do not depend on LD_LIBRARY_PATH being set correctly or other shit
<wpwrak>
but they still need to match the target system's libc
<viric>
nixpkgs toolchains... nanonixos...
<wpwrak>
i knew you'd say that ;-)
* kristianpaul
going to Ecuador to give talk about Copyleft Hardware
<viric>
salute Correa :)
<viric>
wpwrak: bwahahaha ;)
<viric>
wpwrak: I bet I could crossbuilt for the ben in a mips.
<kristianpaul>
i insisted for workshop... but they said no?
<kristianpaul>
i'll confirm again
<whitequark>
wpwrak: how often do you change libcs?
<viric>
how often change libc?
<viric>
there is one new every half a year
<viric>
(for glibc)
<viric>
I use to change once a year
<viric>
well, by change, I mean *start using the newer*. I still use some old glibc for programs I have not updated
<wpwrak>
whitequark: on the ben ? almost never. on the desktop, it depends on what ubuntu does.
<viric>
wpwrak: what one you use now?
<viric>
did ubuntu start using 2.14?
<viric>
they made that mess about RPC...
<wpwrak>
GNU C Library (Ubuntu EGLIBC 2.13-20ubuntu5.1) stable release version 2.13
<viric>
ah even eglibc. ok
<wpwrak>
hmm, ftp://ftp.belnet.be/mirror/ftp.gnu.org/gnu/gcc/gcc-4.6-linaro/ (et al.) no longer exists
<wpwrak>
this breaks owrt toolchain compilation
<wpwrak>
phew. found an old owrt toolchain in my backups. and it doesn't even mind the new ubuntu :)
dvdk has joined #qi-hardware
<whitequark>
wpwrak: ah, the host libc
<whitequark>
well, it theoretically requires the same libc
<whitequark>
practically you can build it once on debian stable and forget about it for ~3 yrs
<wpwrak>
yeah, host libc usually isn't a big issue. luckily :)
shevek has quit [#qi-hardware]
<mth>
we're distributing the OpenDingux toolchain as i386 binary and I haven't heard of any problems running it
<mth>
it is not relocatable though
<mth>
and if you enable LTO on GCC 4.5, you get a dependency on libelf, which is not installed everywhere
<mth>
and is hard or impossible to install on 64-bit Debian
<mth>
but with 4.6 and 4.7 that dependency is gone
<mth>
it is also gone if you don't enable LTO
<mth>
we haven't had much success with LTO anyway, so that's not a big sacrifice
<wpwrak>
mth: ubuntu onerous doesn't install i386 support on amd64 by default. ia32-libs and ia32-libs-multiarch both have unresolved dependencies. aptitude flat out refuses to install them. apt-get valiantly tries but hits a problem later on.
<wpwrak>
on any case, the gcc support libs (libmfpr or whatever it's called) don't seem to get included
<wpwrak>
trying to install the i386 version manually results in apt-get and aptitude happily announcing that they going to uninstall pretty much all of the rest of the system. i was too chicken to try and see what would actually happen if i let it.
Jay7x has joined #qi-hardware
<dvdk>
latest mplayer in openwrt-packages is broken!?
<qi-bot>
[commit] David K
<qi-bot>
[commit] David K
<qi-bot>
[commit] David K
<wolfspraul>
dvdk: really? haven't tried yet but will notice right when I upgrade
<dvdk>
wolfspraul: didn't work due to some library depenency problem (libfaad.so not present), but if i recompile myself, i only get a black picture, not even sound. maybe the video driver deadlocks
<wolfspraul>
ouch, got it
<dvdk>
so, just nobody realized till now, as masked by the dependency problem.
<dvdk>
or maybe my local compilation just has problems, who knows.