<wolfspraul>
lekernel: I'd say it's as usual: 1) trade secrets 2) patents 3) copyrights 4) trademarks
<wolfspraul>
we can easily work without using their trademarks, that's an easy exercise
<wolfspraul>
trade secrets are only trade secrets as long as they are a secret, so if you find specs somewhere, it's not a secret anymore
<wolfspraul>
copyrights - well, we all know how this works, and of course we cannot use copyrighted material
<wolfspraul>
patents - that's an open ended one, we can safely assume in our case it should be mostly FUD, but you never know it would require a bit more investigation
<wolfspraul>
it's definitely a difficult subject. Best might be to even approach them openly about our clean-room implementation...
<wolfspraul>
if you get the feeling they are super aggressive, you may not want to go there even if you think the law is on your side
<mwalle>
larsc: whats your busybox config?
<wolfspraul>
I know very little about HDMI though, maybe we should research a bit.
<lekernel>
wolfspraul: the same protocol is used for DVI
<wolfspraul>
'HDMI' is definitely a trademark already, I would think.
<lekernel>
and the standard (for DVI) is publicly accessible
<wolfspraul>
they will not help you understand which of their generous services you do not need :-)
<wolfspraul>
that work you have to do yourself...
<wolfspraul>
we need to stay away from trademarks
<lekernel>
which has enough information to make a FPGA core able to display pictures on HDMI displays
<wolfspraul>
and from copyrighted material that we have no license for
<wolfspraul>
and we should not do anything illegal to break into a trade secret
<wolfspraul>
and we should respect/work around patents as much as that is possible
<wolfspraul>
all obvious of course...
<wolfspraul>
no news
<wolfspraul>
well great then, seems you have a start already
<lekernel>
and regarding hardware it's merely adding the connector and wiring it up to the FPGA pins (the spartan6 has built in compatible transceivers already)
<wolfspraul>
just stay away from their trademarks, this time from the beginning
<larsc>
mwalle: the same here
<wolfspraul>
they may very well not add much more than their trademark to an otherwise open spec, but if they do that it is still their trademark
<wolfspraul>
if they managed to create some value (recognition) with this trademark, then so be it
<wolfspraul>
we cannot use it
<lekernel>
but well, later. I don't even have an HDMI display to test with
<lekernel>
but if at some point we want to add it, it shouldn't be a big problem
<lekernel>
we can call it "HD connector" or something like that
<wolfspraul>
HD = high definition?
<wolfspraul>
why 'definition'?
<lekernel>
we'd rather not spend those 10k annual license fees plus per-device royalties... better use that money elsewhere
<wolfspraul>
what's the difference between VGA and HDMI? HDMI is digital, right?
<lekernel>
yes
<wolfspraul>
'digital video output'
<wolfspraul>
dvo
<wolfspraul>
:-)
<lekernel>
yeah :)
<lekernel>
could work
<lekernel>
I'm not sure about the trademark status of "HD"
<wolfspraul>
but I would err on the safe side
<lekernel>
there is this "HD ready" logo which is definitely trademarked - and the license, on top of being expensive, requires that you implement DRM
<wolfspraul>
stay away from 'HD', sounds like
<wolfspraul>
same as 'SD'
<wolfspraul>
guess the 'D' is attractive :-)
<wolfspraul>
we really should not piggypack on a trademark, it will backfire, for sure
<wolfspraul>
if they created value/recognition with this 'thing', whatever it is, then it's theirs
<wolfspraul>
I'm in China where people trample over trademarks all over and I know that is no fun.
<wolfspraul>
Nokic, Nckia, Samsnug, Smasung, Sumsung, and so on
<mwalle>
is DVI a trademark too?
<mwalle>
lekernel: my dm800 has a dvi connector with a dvi-to-hdmi cable
<wolfspraul>
Wikipedia says "DisplayPort has an advantage over HDMI in that it is royalty-free, while the HDMI royalty is $0.04 USD per device and has an annual fee of $10,000 for high-volume manufacturers."
<lekernel>
the DVI connector is rather big
<lekernel>
btw this "HD ready" logo thing is rather evil. make the consumers want "HD ready" products, then require DRM to be implemented to license the trademark
<mwalle>
minidvi? :)
<mwalle>
well apple crap
<lekernel>
now I can troll the random geek who wants HD by pointing out that they also mean they want DRM
<wolfspraul>
lekernel: yes sure, but remember they think they create 'value' for all sides
<wolfspraul>
a way to pay is a way to create value, create a product
<lekernel>
I think the HDMI connector is quite good... small and compatible with many devices
<wolfspraul>
so that's a good thing in their thinking, understandably imho
<lekernel>
there are also HDMI->DVI adapters
<lekernel>
(it's the same signaling)
<lekernel>
if we can use that connector without too much legal trouble, good
<wolfspraul>
at first I would say we can.
<wolfspraul>
unless they have some really evil patents on mechanical hooks in the connector.
<tuxbrain>
I wanna see if it has any server side scripting capabilities like php/phython/perl...
<lekernel>
hahaha, most probably not
<lekernel>
it's probably a big hacky FSM
<tuxbrain>
Flying spaguetti monster???
<lekernel>
finite state machine
<tuxbrain>
ok :P
<tuxbrain>
dreams on dinamic webservers on a chip
<tuxbrain>
imagin that to integrate along wpan on tinny low power modules
<tuxbrain>
all devices in a home from the ringbell to the alarm clock can be setup and consulted using a web interface wiresly, even yous cloths can be part of the network ....
<mwalle>
so use some low power uC :)
<roh>
uc isnt the issue. the rf eats 100 times more
<wpwrak>
roh: depends on your transmit power :)
<roh>
tuxbrain: if you need a 'cpu and transciever board' .. check out the chibiduino
<roh>
33$/piece is quite cheap. i dont think one can easily beat that
<tuxbrain>
roh I have an eye on chibiduino, I think once NN has also wpan could be a great companion to interact wiresly with the real wold :), also I hope MM would have an driver for atusb soon to interact with chibi or NN :)
<wpwrak>
tuxbrain: just install linux on the MM ;-)
<tuxbrain>
he :), wpwrak you know I will love to see a full trootle linux on it I know some people are improving the actual port, or at least willing to do in short, but I would like to see atusb running on the "official" rterms version
<tuxbrain>
out of the box MM NN interaction :)
<Fallenou>
lekernel: already seen this video :)
<Fallenou>
nice but useless :p
<tuxbrain>
maybe an app with a front end on NN to change patches/edit/create patches on MM wiresly
<tuxbrain>
wiresly->wirelessly
<lekernel>
roh: when you see the price of that hot wheels gun, *duino looks expensive
<lekernel>
but yeah, for small batches, $33 is cheap
<roh>
lekernel: it was also 20E or so last time i checked
<lekernel>
sure, but it has case, mechanics, waveguide, AVR, LCD, batteries, and that microwave module which are typically in the 200E range instead of 20
<roh>
naaah
<roh>
microwave stuff isnt expensive. its just some metal anyhow
<roh>
a lnb is more complex and also <10E
<lekernel>
yeah. see the power of mass production
<lekernel>
if you tried to build a LNB yourself (with regular PCB and chips), you'd pay a LOT more
<roh>
sure. but because of development, not material cost
<lekernel>
no, for MW it's often material cost
<roh>
its mostly a combination of modern semiconductors and quite simple rf circuits with extreme focus on mechanical layout
<lekernel>
#!@§ rtems filesystem bugs (?)
<lekernel>
seriously the rtems filesystem is the shittiest piece of code i've discovered in the past 6 months (autocrap doesn't count, I knew it before)
<lekernel>
there's that utterly retarded eval_path system, and open file then delete file from another task = crash
<lekernel>
now it seems that the shell commands (rm/mv/cp) fail intermittently when run from the app and not the shell. and my guess is this might be related to eval_path bugs ... :(
<lekernel>
wow, I even managed to create an undeletable + unreadable directory on the ramdisk using cp alone
<Fallenou>
yes eval_path is a shitty thing
<Fallenou>
it's not even using some sort of vfs, is it ?
<Fallenou>
they really should be using a vfs kind of thing
<lekernel>
haha, no, eval_path replaces the vfs
<lekernel>
it's kind of a VFS name resolution function split across every registered filesystem. it's a bit as if Salomon carried on with his idea of splitting the baby, with blood spilling everywhere