[Brmlab] Laser Hacking #3

Cestmir Houska czestmyr at gmail.com
Tue Dec 21 19:01:43 CET 2010


Ah, sorry then :-) But why were you avoiding it? I don't see the problem
with this approach...

Plus, this way, we can have multiple devices connected to the server, which
means that you can draw onto a simulator AND the real device simultaneously.
(BTW, I also implemented the simulator ;-) )

Cestmir

On Tue, Dec 21, 2010 at 6:59 PM, Felipe Sanches <juca at members.fsf.org>wrote:

> Cestmir,
>
> I'm afraid you did exactly what I was avoiding...
> I had on purpose the same code running both on the server and on the
> client.
>
> 2010/12/21 Cestmir Houska <czestmyr at gmail.com>:
> > I rewrote the architecture of the whole system to be client-server based.
> > But I cannot commit my changes (see commandline dump below). Can someone
> > help me?
> >
> > czestmyr at czestmyr:~/prog/python-gst/ld-commit$ svn ci -m "[...]"
> > Password for '(null)' GNOME keyring:
> > svn: Commit failed (details follow):
> > svn: MKACTIVITY of '/svn/!svn/act/067e82eb-5442-4ae2-91b1-386acc666ee4':
> > authorization failed: Could not authenticate to server: rejected Basic
> > challenge (https://felipesanches.googlecode.com)
> >
> > Cestmir
> >
> > On Thu, Dec 16, 2010 at 7:45 PM, Pavel Ruzicka <ruza at ruza.eu> wrote:
> >>
> >> Ive just tried revision 261. Few things:
> >>
> >> * laser-server.py line 53 delete ":" character
> >>
> >> * instead of rewriting LD call in each script, it would be great to have
> >> config file like
> >>
> >> LOCAL_DEVICE=true  # or SRV_* for tcp
> >> SRV_HOST=localhost
> >> SRV_PORT=5000
> >>
> >> and "library would" make connection directly to the device or via tcp
> >> based on that variables.
> >>
> >> * code should automaticaly detect if the device is initializsed or not
> >> (based on VendorID) and make that initialisation if its needed and draw.
> >> For example example1.py fails on comunicating with vendorID 3333 when
> >> device is directly connected and card is already initialised.
> >>
> >> * security (optional)
> >>  - device probably shouldnt accept something like "draw a single dot for
> >> a long time". There is a chance somebody would stare to the lasaer
> >> instantly.
> >>  - device shouldnt shine for a long time without intervention. It should
> >> stop drawing if nobody is sending "new things to draw", it shorten
> >> lifetime of the laser device otherwise. TIMEOUT=30min could be default
> >> for example.
> >>
> >> ruza
> >>
> >>
> >> On 12/15/2010 11:03 AM, Felipe Sanches wrote:
> >> > I have commited new code without testing because I do not have access
> >> > to the device. Please test svn revision 260 and report me any bugs
> >> > introduced by this commit.
> >> >
> >> > On Wed, Dec 15, 2010 at 3:23 AM, Felipe Sanches <juca at members.fsf.org
> >
> >> > wrote:
> >> >> can you please send me an image of the contents of the instalation
> CD?
> >> >> I mean, the Windows drivers.
> >> >>
> >> >> On Wed, Dec 15, 2010 at 3:01 AM, Felipe Sanches <
> juca at members.fsf.org>
> >> >> wrote:
> >> >>> Awesome!!! Congratulations!
> >> >>>
> >> >>> Now, we have to figure out the meaning of the usbinit log. Because
> >> >>> simply using it without understanding it is similar to our previous
> >> >>> condition of using proprietary software.
> >> >>>
> >> >>> Actually, if our theory that this usbinit performs a firmware upload
> >> >>> is correct, then it is precisely proprietary software that we are
> >> >>> still relying on and that must be fixed.
> >> >>>
> >> >>> The benefits of understanding the firmware upload protocol is that
> we
> >> >>> can create our own free firmware for the device, which opens up
> >> >>> several interesting possibilities for improving the laser display.
> >> >>>
> >> >>> Well... I've been dealing a lot recently with this issue of devices
> >> >>> that require non-free firmware in order to work properly. That means
> I
> >> >>> already have some ideas of strategies that we can try:
> >> >>>
> >> >>> Strategy 1:
> >> >>>
> >> >>> Inspect the windows driver trying to find blocks of data that are
> >> >>> similar to the usbinit log. This can be useful to give us a clearer
> >> >>> idea of which bytes in the log are firmware code and which ones are
> >> >>> just part of the fw upload protocol.
> >> >>>
> >> >>> Strategy 2:
> >> >>>
> >> >>> try to disassembly some portions of the usbinit log using a 8051
> >> >>> disassembler. Try to identify something that looks like valid code.
> >> >>> Use that information to thing again about the structure of the
> >> >>> firmware upload protocol.
> >> >>>
> >> >>>
> >> >>> Lets do it?
> >> >>>
> >> >>> cheers,
> >> >>> Felipe Sanches
> >> >>>
> >> >>> On Wed, Dec 15, 2010 at 1:41 AM, niekt0 <niekt0 at hysteria.sk> wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>> we spent night in brmlab and
> >> >>>> laser initialization from linux is finally working.
> >> >>>> Also we fixed some bugs. (everything is in svn)
> >> >>>>
> >> >>>> We just pust a simple video on our youtube,
> >> >>>> check soup.brmlab.cz.
> >> >>>>
> >> >>>> enjoy;)
> >> >>>>
> >> >>>> n.
> >> >>>> On 12/14/10, Felipe Sanches <juca at members.fsf.org> wrote:
> >> >>>>> I am writting a blogpost about the laser projector project and I
> >> >>>>> need
> >> >>>>> some videos. Is it possible for you to shoot short videos (around
> 30
> >> >>>>> seconds or a minute) of these things, please?
> >> >>>>>
> >> >>>>> * the simple vector drawing tool (run bedit.py and draw a bit)
> >> >>>>> * the wallburner (scerensaver) with bezier curves - it is
> >> >>>>> example3.py
> >> >>>>>
> >> >>>>> thanks,
> >> >>>>> Felipe Sanches
> >> >>>>>
> >> >>>>> On Mon, Dec 13, 2010 at 8:17 AM, Pavel Ruzicka <ruza at ruza.eu>
> wrote:
> >> >>>>>> if you need some advice regarding chaosvpn/agoralink let me know.
> >> >>>>>> ive
> >> >>>>>> connected brmlab to that vpn
> >> >>>>>>
> >> >>>>>> ruza
> >> >>>>>>
> >> >>>>>> On 12/12/2010 07:59 PM, Ax wrote:
> >> >>>>>>> Laser was moved to other room and connected to server there.
> >> >>>>>>> Results
> >> >>>>>>> are quite impressive:
> >> >>>>>>> http://picasaweb.google.com/axtheb/Brmlab
> >> >>>>>>> Hopefully we can arrange working webcam and some vpn soon...
> >> >>>>>>> Felippe,
> >> >>>>>>> do you have access to agoralink/chaosvpn? Using that we can get
> >> >>>>>>> you
> >> >>>>>>> link quickly [http://brmlab.cz/project/chaosvpn]
> >> >>>>>>> And, please, give me commit rights to the repo so I can put my
> >> >>>>>>> util
> >> >>>>>>> lib and the rocket game there.
> >> >>>>>>>
> >> >>>>>>> Ax
> >> >>>>>>> _______________________________________________
> >> >>>>>>> Brmlab mailing list
> >> >>>>>>> Brmlab at brmlab.cz
> >> >>>>>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> e-mail:  ruza at ruza.eu
> >> >>>>>> www:   http://ruza.eu
> >> >>>>>>     http://brmlab.cz
> >> >>>>>>
> >> >>>>> _______________________________________________
> >> >>>>> Brmlab mailing list
> >> >>>>> Brmlab at brmlab.cz
> >> >>>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >> >>>>>
> >> >>>> _______________________________________________
> >> >>>> Brmlab mailing list
> >> >>>> Brmlab at brmlab.cz
> >> >>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >> >>>>
> >> >>>
> >> >>
> >> > _______________________________________________
> >> > Brmlab mailing list
> >> > Brmlab at brmlab.cz
> >> > http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >>
> >>
> >> --
> >> e-mail:  ruza at ruza.eu
> >> www:   http://ruza.eu
> >>     http://brmlab.cz
> >> _______________________________________________
> >> Brmlab mailing list
> >> Brmlab at brmlab.cz
> >> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >
> >
> > _______________________________________________
> > Brmlab mailing list
> > Brmlab at brmlab.cz
> > http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
> >
> >
> _______________________________________________
> Brmlab mailing list
> Brmlab at brmlab.cz
> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brmlab.cz/pipermail/brmlab/attachments/20101221/3bed04c8/attachment.html>


More information about the Brmlab mailing list