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
<abushcrafterforg>
I was thinking over simple cuts. For say voice recs.
<abushcrafterforg>
over = or
<abushcrafterforg>
or = of
abushcrafterforg has joined #qi-hardware
abushcrafterforg has joined #qi-hardware
<abushcrafterforg>
Is there a nice little GUI for simple cuts? is that possible or is that too much:D?
<kristianpaul>
no gui afaik
<kristianpaul>
but i bet some command line tools could help you
<abushcrafterforg>
ok. sox i guess
<kristianpaul>
yup :)
<abushcrafterforg>
mhwaveedit is a small gtk audio editor. does it need to suport framebuffer or does GTK do that for it?
<kristianpaul>
hmm you got me on that
<kristianpaul>
but gtk uses framebuffer, yes
<kristianpaul>
dunno how this is "GTK do that for it" works for the nanonote
<abushcrafterforg>
sorry bad english
<kristianpaul>
he mee to ;)
<abushcrafterforg>
GTK handles the frame-buff side of things. So mhWaveEdit does not need to know about frame-buffer.
<kristianpaul>
oh, cool !
<abushcrafterforg>
no I mean does it?
<kristianpaul>
dont know..
<kristianpaul>
wait some minutes, i think xiangfu knows
<abushcrafterforg>
and English is my native lang...
<abushcrafterforg>
ok
<kristianpaul>
ergh, sorry i'm not native so i gues i misundertood you in the first place
<abushcrafterforg>
sorry to put you though the suffering.
<abushcrafterforg>
any replays I will see in the logs.
rejon has joined #qi-hardware
lindi- has joined #qi-hardware
rex_fernando has joined #qi-hardware
<rex_fernando>
does anyone use the micro-sd wifi card mentioned in the wiki?
<rex_fernando>
I can't find it for sale anywhere; is it not offered anymore?
lindi- has joined #qi-hardware
<whitequark>
DocScrutinizer: very interesting
<whitequark>
phenolphtaleine might work
<whitequark>
and I actually thought of kirlian effect in the past, but I was uncertain if it would really work
jekhor has joined #qi-hardware
<whitequark>
(photos) if the chinese fab can only do photos, that's not worth 100USD
<whitequark>
but if they do actual tracing, then it indeed is
<whitequark>
DocScrutinizer: also, I think it is fairly easy to use matlab to do some image processing and vectorize the polygons from these photos
<whitequark>
I've seen a script like that on StackOverflow
<whitequark>
the vias are indeed the problem, but how chemical methods would help?
<whitequark>
I don't quite get it
<whitequark>
or do you mean ignoring the structure of inner layers and just tracing the connections between the actual pads?
<whitequark>
rex_fernando: as far as I know, there are 0 (zero) wifi sdio cards with good Linux support
<whitequark>
there's one or two for which you can find half-done drivers (I think eyefi kind of works), but these aren't good anyway
<rex_fernando>
ok, thanks
<whitequark>
they're also expensive
<wpwrak_>
i think the company that made one that's relatively popular on the ben stopped that product
<whitequark>
eyefi is $120-$150
<wpwrak_>
or maybe even went out of business completely
<whitequark>
there's no need in sdio wifi anymore
<whitequark>
even alarm clocks have integrated wifi
<wpwrak_>
yes, that's the problem. we're among the very few that don't have built-in wifi
<whitequark>
... due to the fact that it is non-free, and not cost or other concerns
<whitequark>
hm
lindi- has joined #qi-hardware
<whitequark>
wpwrak_: how wifi chipset differs from the cpu in terms of freeness?
<whitequark>
you don't have netlists for both
<whitequark>
and the standard is open, isn't it?
<wpwrak_>
openness is very bad for small devices. it seems that there are now reasonably open chips for laptop-sized devices.
<whitequark>
what's bad? firmwares? absence of specs?
<whitequark>
there's Atheros, isn't it?
<wpwrak_>
at least the earlier versions of the standard (.11b, .11g) are sufficiently open. they have been at least partially implemented with SDR.
LunaVorax has joined #qi-hardware
<wpwrak_>
firmware, access to chips or modules, no specs
<wpwrak_>
yes, there's atheros ...
<wpwrak_>
... that's where a lot of my bad experience comes from :)
<whitequark>
what's wrong with it?
<wpwrak_>
oh, binary-only firmware full of bugs that never gets fixed
<whitequark>
mhm
<wpwrak_>
then, you can't get chips, just modules. and these are also hard to find.
<whitequark>
they have open-sourced the fw for at least some chips
<whitequark>
(modules) oh yes, this is bad indeed
<wpwrak_>
which don't include the really small ones, e.g., the 6k series
<wpwrak_>
as things get bigger, laptop-sized, then you have better choices
<whitequark>
ok. I understand it now
<whitequark>
yay! my M1 has arrived to Moscow
<whitequark>
already passed customs
<whitequark>
which, according to the history, took 1 (one) minute
<wpwrak_>
wow
jekhor has joined #qi-hardware
rejon has joined #qi-hardware
rejon has joined #qi-hardware
rektide has joined #qi-hardware
wolfspraul has joined #qi-hardware
zumbi has joined #qi-hardware
wej_ has joined #qi-hardware
panda|x201 has joined #qi-hardware
rejon has joined #qi-hardware
rejon has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
LunaVorax has joined #qi-hardware
wolfspraul has joined #qi-hardware
fossrox has joined #qi-hardware
losinggeneration has joined #qi-hardware
antoniodariush has joined #qi-hardware
rejon has joined #qi-hardware
GNUtoo has joined #qi-hardware
antonio_ has joined #qi-hardware
rejon has joined #qi-hardware
<DocScrutinizer>
whitequark: yes, I mean ignoring the structure of inner layers and just tracing the connections between the actual pads
Ayla_ has joined #qi-hardware
kudkudyak has joined #qi-hardware
kudkudyak has joined #qi-hardware
antoniodariush has joined #qi-hardware
kilae has joined #qi-hardware
wolfspraul has joined #qi-hardware
wej has joined #qi-hardware
wej has joined #qi-hardware
mstevens has joined #qi-hardware
wej has joined #qi-hardware
urandom__ has joined #qi-hardware
panda|x201 has joined #qi-hardware
ChanServ has joined #qi-hardware
<whitequark>
DocScrutinizer: ok, I was not able to find the board
<whitequark>
even for (reasonable) sum of money
<whitequark>
so, unfortunately that's out of question atm
<DocScrutinizer51>
a pity
<whitequark>
repairmen say that the phone is quite popular, and as the most failing component is obviously screen, they just replace it
<whitequark>
there's nothing on ebay and I'm not spending $600 just to trace the board.
<DocScrutinizer51>
that's why I say not disclosing schematics is an offense to your customers, *only* - no sane reationale
<whitequark>
I agree.
<whitequark>
well. there was a precedent before
<DocScrutinizer51>
chinese copycat has no problems with missing schematics
<DocScrutinizer51>
customer has
* DocScrutinizer51
idly tries to pair his MX5500 cordless mouse via BT to N900
<DocScrutinizer51>
whitequark: look, even at OM our NDA pope Tony was afraid to even publish schematics that had circuit details similar to those in the application notes of the chip manuf
<DocScrutinizer51>
whitequark: you can see in OM GTA02 schematics that we asked uBlox for permission, and didn't dare to publish anything regarding calypso
<whitequark>
hm, yes, that's quite paranoid
<whitequark>
could he really get sued?
<DocScrutinizer51>
he for sure not, his concern was about OM Inc
<DocScrutinizer51>
and me ;-D
<DocScrutinizer51>
as finally I took the responsibility
<DocScrutinizer51>
at least my name is on first page
<whitequark>
that's pretty screwed up
<wpwrak_>
well, that's due diligence for you :)
<DocScrutinizer51>
yeah, idustry wide
<wpwrak_>
of course, it's understandable. if something does happen, then the poor little guy who boldly waves the thing through will be in hot water.
<DocScrutinizer51>
sure
<wpwrak_>
also a policy of openness doesn't really help. getting it authorized by someone higher up does, though.
* DocScrutinizer51
repacks that silly ridiculously expensive mouse
<DocScrutinizer51>
well, my auth been by wolfspraul
<DocScrutinizer51>
and finally ny z
<DocScrutinizer51>
by Sean
<wpwrak_>
ny z ?
<DocScrutinizer51>
typo
<DocScrutinizer51>
cold here
<wpwrak_>
ah :)
<wpwrak_>
a very pleasant 26 C here :)
<DocScrutinizer51>
also my adrenaline - just had to call the paramedics for an old lady that stumbled and hurt her face
<wpwrak_>
so you've been a good citizen
<whitequark>
why are you trying to pair your mouse with N900 in a cold place outside? :)
<DocScrutinizer51>
n900 is a *mobile* device
<DocScrutinizer51>
so my situation is changing frequently
<DocScrutinizer51>
actually when I tried to pair I was inside a cafe sipping some latte
<DocScrutinizer51>
now I'm outside for a cig
<DocScrutinizer51>
friggin smoker prohibition
<whitequark>
here in Russia we have some cafes when you're allowed to smoke. e.g. a dedicated floor
<whitequark>
quite convenient
<whitequark>
*where
<DocScrutinizer51>
had to swap the mouse, as the one bought a week ago was broken
<DocScrutinizer51>
whitequark: indeed
<whitequark>
MX5500 is Logitech
<whitequark>
I've been trying to make a Logitech mouse (albeit other one) nicely with bluez for a ~year
<whitequark>
then gave up and bought the cheapest Dell one I could find
<DocScrutinizer51>
at my company, a whole building with 7 floors they urge employees to leave building and smoke at entrance in the icy cold
<whitequark>
I'm happy ever since
<wpwrak_>
DocScrutinizer: at least they don't make you go to russia for it ;-))
<whitequark>
lol
<DocScrutinizer51>
indeed
wej has joined #qi-hardware
<whitequark>
do they understand you are likely to waste more time by doing so?
<whitequark>
(formally, in Russia smoking is also prohibited in e.g. my university. but you can estimate the actual force of this regulation by a simple example: right under the "no smoking" sign there's an ashtray)
<DocScrutinizer51>
they don't care how long I work, as long as my reults are ok
<wpwrak_>
read: the more you smoke, the later the evenings :)
<DocScrutinizer51>
and as an external consultant I am not allowed to cary any minute plus or minus of work time to next month, so the whole idea is moot
<DocScrutinizer51>
wpwrak_: kinda
* whitequark
has bought a butane-powered soldering iron, Dremel Versatip
<whitequark>
I wonder how useful would it actually be
<DocScrutinizer51>
meanhile my time accounting sheet looks rather uniform, 8:30-17;00 each day, in accordance with the 'boss'
<DocScrutinizer51>
whitequark: dang, I *loved* that one
<DocScrutinizer51>
used it for almost everything, everywhere
<whitequark>
it was one of the cheapest, and it was also Dremel, which I heard makes quite good tools
<DocScrutinizer51>
lightweight and cordless is a huuuge convenience
<whitequark>
what has happened with yours?
<DocScrutinizer51>
well, it vanished with all my other former life, as a indirect result of some fire in apartment
<DocScrutinizer51>
now all tools I got are about like a set of torx, a 5EUR DMM and a weller soldering station
<DocScrutinizer51>
stopped real hw work completely
<whitequark>
why?
<DocScrutinizer51>
ATM I got enough of nice tools like LeCroy scopes and R&S CMU200 etc, at work
GNUtoo has joined #qi-hardware
<DocScrutinizer51>
whitequark: it's just too expensive to get a new completely equipped good lab at home, for... what?
<DocScrutinizer51>
I'm recently not doing any HW development so getting tools for this was kinda nonsense
<DocScrutinizer51>
and when I had the tools I wasn't doing too much at 'home' either
<DocScrutinizer51>
in former times, when I was 'young', yeah
<DocScrutinizer51>
been fun to mod high class casette recorders and whatnot else
<DocScrutinizer51>
or build own little controllers etc
<lindi->
we formed a hackerspace here so that we don't need to keep HW tools at home :)
<DocScrutinizer51>
nowadays you buy that shit for 1.99 at china
<wpwrak_>
... on a weekly basis
<whitequark>
I've bought some tools in China recently. tweezers are nice, I like them. kind of cheap too
* DocScrutinizer51
walking ->home
<DocScrutinizer51>
bbl
<whitequark>
lindi-: how long does it take for hackerspace members to get to it?
<whitequark>
on a workday evening for example
<lindi->
whitequark: what do you mean how long?
<whitequark>
you're not living at the place, right? then you need to go to it from home/school/university
<lindi->
whitequark: that of course depends on where they live but around 30 minutes by bus for me
<lindi->
(bus takes 12 minutes but I'm including all the walking and waiting)
<lindi->
a new bicycle route will make this easier this summer too :)
<lindi->
whitequark: but yes, it'd of course be better to always have it closer :)
<whitequark>
it's just that we have one in Moscow, but it's quite far from my home, and I'm quite lazy
<DocScrutinizer>
Weller too expensive for the quality they offer
woakas has joined #qi-hardware
<qi-bot>
RTC Milkymist: RT @qihardware: Qi Hardware working in Fiber: Crocheted LG Phone Case With Soure Code http://t.co/lOOTRXUM ( 168411625177616384@milkymistvj - 28s ago via HootSuite )
<qi-bot>
Pete Ippel ‽: RT @qihardware: Qi Hardware working in Fiber: Crocheted LG Phone Case With Soure Code http://t.co/hltWj4VK ( 168411631192248320@hypermodern - 27s ago via Ping.fm )
* whitequark
has just converted his kitchen table to work table
<whitequark>
I still have to wait for Monday for M1
<whitequark>
and $RANDOM days to NN. tuxbrain doesn't seem very alive.
<whitequark>
*to be
<kyak>
no offense, but this is exactly what is thought when ordering atben/atusb from him
<kyak>
thinking about 10 bens/month he mentioned earlier is ML, makes me wonder... did he get a real job? :)
<larsc>
yes
<larsc>
whatever a 'real' job is
qwebirc33072 has joined #qi-hardware
<kyak>
something that is worth more than 80 bucks/months
<larsc>
wolfgang recently mentioned in here that he has a new fulltime job and also a small child
<qi-bot>
Ralph Dunmore: http://t.co/0Mcx9hnE @gaby1portilla @qihardware ( 168434581060583425@ralphep6 - 13s ago via web )
<Ayla>
I heard you did an optimized build of mplayer
<Ayla>
it does use the IPU? or the MXU instruction set maybe?
<dvdk>
sort of. what are you looking for
<dvdk>
yes only the IPU
<dvdk>
for yuv->rgb conversion plus scaling. mxu instruction set, not not sof far.
<dvdk>
(not really neccessary to do more tuning for the small 320x240 display resolution)
<dvdk>
and the mxu stuff is ugly. no gnu as support etc. :/
<Ayla>
well, it'd be a matter of adding the instruction set to buildroot
<Ayla>
anyway. If I'm right, your mplayer uses the IPU through /dev/mem,
<dvdk>
ayla: no, it's not supported by the binutls neither upstream nor downstream anywhere. there's only a awk script to patch assembler opcodes into hexcodes.
<dvdk>
yup.
<Ayla>
would you be ready to work on a kernel driver for it, that uses v4l2 for instance, or help me doing it?
<dvdk>
ayla: what's the need to put that into the kernel? Xorg drivers aren't (mostly) in the kernel, too.
<dvdk>
ayla: if you want to patch the kernel, than enabling dev/mem is easier than making a new driver :)
<Ayla>
I don't want to enable /dev/mem
<dvdk>
but you should :)
<Ayla>
we did disable it on purpose, we won't re-enable it again
<dvdk>
uh
<Ayla>
(to set the context, I do work with mth on OpenDingux, a linux distribution for the Dingoo A320 which uses the jz47xx kernel)
<dvdk>
figured that.
<dvdk>
well, then as a compromise, use Linux' user-space driver API and export memory access to the IPU regs only, plus a buffer via a device file.
<dvdk>
adapting the driver above would be trivial then.
<Ayla>
that's a possibility, yes
<viric>
dvdk: that driver still crashes quite a lot here
<viric>
well
<viric>
maybe not a lot
<viric>
I don't now if it's a deal with /dev/mem and in kernel it would work
<dvdk>
i think there's an example somewhere in the mplayer sources. for a minimalistic driver using linux kernel support. 'sh_veu_vid.c'. my driver is based on that.
<dvdk>
viric: try to upgrade to latest jz47xx version. i had some bugs.
<Ayla>
the other interest is that if we use a v4l2 driver, mplayer would just work without any change
<dvdk>
ayla: isn't v4l2 about input, not output?
<Ayla>
it's both
<dvdk>
hmm.
<viric>
ah both?
<viric>
I was about to say the same about input
<viric>
what example is there of v4l2 as output?
<Ayla>
I believe it's not really used a lot
<dvdk>
well, feel free to rip out any code from my sources you need. but as it works for NN i'm not currently motivated to rewrite anything. no time currently for such "non-productive" cosmetic work.
<viric>
dvdk: I was usin the latest tarball, some weeks ago
<dvdk>
also i hate in-kernel drivers. kernel is a moving target, not (internal) hard APIs. that's bad.
<Ayla>
that's fine, I was asking you just in case you were super-motivated to work on it
<viric>
dvdk: latest tarball on new year.
<dvdk>
viric: mayb mplayer crashes on you, not the driver?
<Ayla>
but I can do it, no problem
<viric>
dvdk: I don't know. I can't recover that fb on crash
<dvdk>
ayla: :)
<dvdk>
viric: launch mplayer from a remote ssh.
<Ayla>
I can do it => I can *try* :)
<viric>
dvdk: that does not fix anything
<dvdk>
viric: but you can see log output even if fb doesn't recover.
<viric>
dvdk: I mean, it shows on screen the video, but I can't recover the fb for text
LunaVorax has joined #qi-hardware
<viric>
ah yes
<Ayla>
viric, gmenu2x has some code to unlock that situation
<viric>
ah
<dvdk>
virc: also 'strace' may help to locate the problem.
<viric>
I never run gmenu2x
<dvdk>
maybe some mmap() crashes etc.
<viric>
it works for around 5 seconds
<viric>
then, crash
<viric>
but well, I agree I should write a better report thant hat ;)
<viric>
that
<dvdk>
ayla: ah, the correct term about coding in-kernel drivers is "technological debt". since you'll have to adapt to kernel changes for all the time in the future. think like "interest rate". i hate debts :)
<viric>
hehe
<viric>
dvdk: and if you don't do tat?
<viric>
that.
<dvdk>
so that's why i love user-space driver.
<dvdk>
with dev/mem
<viric>
Ayla: why you disabled /dev/mem?
<Ayla>
viric: because the old dingux programs were doing nasty things
<Ayla>
like messing with the clocks directly
<Ayla>
and the user space should not mess with the kernel space anyway
<viric>
ah, for a videogame device, I think all should be allowed :)
<viric>
it's not a multiuser mainframe :)
kuribas has joined #qi-hardware
<mth>
I met Hans de Goede at T-DOSE and explained the IPU and he said it would fit into v4l2
<mth>
I don't remember exactly though how it would fit in
mstevens has joined #qi-hardware
<mth>
there is some kind of API where you can pass buffers to be either converted to displayed
<mth>
from userspace to kernel and back
<mth>
worst abuse of /dev/mem we encountered was a program ported from GP2X that would access the GP2X hardware via /dev/mem
<mth>
note that GP2X has an ARM SoC
<mth>
and the port still had that code active
<mth>
but mostly the problem is user space code accessing the hardware directly while that same hardware is handled by kernel drivers as well
<mth>
if that happens, there is no way to debug it
<viric>
sure
<mth>
another issue with user space drivers is that they don't react properly to systemwide events like suspend
<viric>
there could be /dev/mem in the kernel, and lack the device file
<viric>
just as a 'warning'
<viric>
or maybe it can be set as a module
<viric>
ah yes, the suspend thing...
<mth>
the device files are auto-created in a ramdisk, but probably it can be configured to not create them
<mth>
still, if someone has a genuine need to use /dev/mem, it's not that hard to build a kernel that has it
<viric>
but still, it's the situation of "a quickly written driver" vs "a well maintained driver", regardless of user or kernel mode
<mth>
I made it an option; all the code is still there, it's just disabled in our config
<viric>
I think that there should be a place for "quickly written driver"
<viric>
but users should know what they run, yes.
<viric>
then there are the people like dvdk, that make a driver of value using /dev/mem, and then the NN people get forced to provide it ;)
<mth>
that's why we're looking to move his driver into the kernel, or at least away from /dev/mem
<viric>
clear
<viric>
I understand.
<viric>
move from "quickly written driver" to "well maintained driver"
<mth>
yes
<viric>
as for me, I lack the skills to do that with short dedication
<mth>
we have our share of hacky in-kernel drivers too though, we're still several steps away from a clean solution
<viric>
aha
<viric>
mth: otherwise all would be at linus' linux
<mth>
skills can be developed; I did very little kernel programming before this and I still have a lot to learn
<mth>
indeed
<viric>
yes, me too...
<viric>
I recently did some hacks on the fuloong to fix its boot
<viric>
but nothing beyond that
<viric>
(something in the NN too)
<viric>
and I read carefully the driver from dvdk :)