[Brmlab] Laser Hacking #3

Cestmir Houska czestmyr at gmail.com
Tue Dec 21 19:10:31 CET 2010


Here's a diff. I split the original LaserDisplay file into LaserDisplay,
LaserClient and LaserDevice. That way, all the code is neatly organized.
Also, when I added the LasersimDevice, I realized that now we would have to
include the same code twice, but three times! That's probably the main
reason for the reorganization.

Now, you just start the laser-server, which creates a LaserDisplay (that can
have one or more devices attached to it). All the transformation stuff,
noise, etc. should be in the Display class and the bare drawing stuff will
be in the devices.

Also, I added a proxy mechanism that prints info into the console when a
non-existent method in the device is called, so that the server doesn't end,
but just informs you about the unavailable stuff in one of the devices (for
example the configuration cannot be set for the laser simulator).

Cestmir

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

> well... let me see the code. Perhaps I'm just confused. I guess you
> may have done a good job anyway.
> Can you generate a patch and send it to me?
>
> 2010/12/21 Cestmir Houska <czestmyr at gmail.com>:
> > 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
> >
> >
> > _______________________________________________
> > 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/f56aaf9f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laser.diff
Type: text/x-diff
Size: 32856 bytes
Desc: not available
URL: <http://brmlab.cz/pipermail/brmlab/attachments/20101221/f56aaf9f/attachment.diff>


More information about the Brmlab mailing list