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
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@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@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@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@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@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@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@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@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@brmlab.cz
>> >>>>>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> e-mail: ruza@ruza.eu
>> >>>>>> www: http://ruza.eu
>> >>>>>> http://brmlab.cz
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> Brmlab mailing list
>> >>>>> Brmlab@brmlab.cz
>> >>>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>> >>>>>
>> >>>> _______________________________________________
>> >>>> Brmlab mailing list
>> >>>> Brmlab@brmlab.cz
>> >>>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>> >>>>
>> >>>
>> >>
>> > _______________________________________________
>> > Brmlab mailing list
>> > Brmlab@brmlab.cz
>> > http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>>
>>
>> --
>> e-mail: ruza@ruza.eu
>> www: http://ruza.eu
>> http://brmlab.cz
>> _______________________________________________
>> Brmlab mailing list
>> Brmlab@brmlab.cz
>> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>
>
> _______________________________________________
> Brmlab mailing list
> Brmlab@brmlab.cz
> http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
>
>
_______________________________________________
Brmlab mailing list
Brmlab@brmlab.cz
http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab