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
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
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
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
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
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
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
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
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
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
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@members.fsf.orgwrote:
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
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@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@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@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
Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
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@members.fsf.orgwrote:
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@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@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@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
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
On 21/12/10 19:03, Felipe Sanches 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?
I am also interested in seeing the code. Especially the simulator part. I also wanted to do a rewrite - introduce one abstract class and its 3 implementations - Local, Remote and Simulator. Also always using client-server architecture is not very good, because there is visible difference in remote/local when drawing more complex scenes.
Well, you can always use the LaserDisplay directly (without the server).
Cestmir
On Tue, Dec 21, 2010 at 7:14 PM, Pavol Rusnak stick@gk2.sk wrote:
On 21/12/10 19:03, Felipe Sanches 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?
I am also interested in seeing the code. Especially the simulator part. I also wanted to do a rewrite - introduce one abstract class and its 3 implementations - Local, Remote and Simulator. Also always using client-server architecture is not very good, because there is visible difference in remote/local when drawing more complex scenes.
-- Best Regards / S pozdravom,
Pavol Rusnak stick@gk2.sk
Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
On 21/12/10 19:13, Cestmir Houska wrote:
Well, you can always use the LaserDisplay directly (without the server).
Cool, that's what I was hoping for!
Btw, if you are both proficient with git we can move the source code to gitorious.org/brmlab and we can use separate branches for development (SVN sucks big time when it comes to branches). If you are interested, just let me now, i will import the project and give you the access rights ...
I'm ok with that!
On Tue, Dec 21, 2010 at 4:31 PM, Pavol Rusnak stick@gk2.sk wrote:
On 21/12/10 19:13, Cestmir Houska wrote:
Well, you can always use the LaserDisplay directly (without the server).
Cool, that's what I was hoping for!
Btw, if you are both proficient with git we can move the source code to gitorious.org/brmlab and we can use separate branches for development (SVN sucks big time when it comes to branches). If you are interested, just let me now, i will import the project and give you the access rights ...
-- Best Regards / S pozdravom,
Pavol Rusnak stick@gk2.sk _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
it seems to be an issue with your keyring...
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
One more thing on this subject:
We should try to check out datasheets of the target chip to find out what is protocol overhead and what is the firmware code block...
OR
I don't remember the chip's part number, but it should be revealed from inside of the box - right from the chip/Windows driver VEN_/DEV_ ID. I remember I found some other fw for this chip on the internet. We should try to upload that "other" firmware to the chip. It would not work for the ILDA decoder, but it should show us the way...
;-)
Blackhead
-----Original Message----- From: brmlab-bounces@brmlab.cz [mailto:brmlab-bounces@brmlab.cz]On Behalf Of Felipe Sanches Sent: Wednesday, December 15, 2010 6:02 AM To: Brmlab: Hackerspace Prague (main discussion) Subject: Re: [Brmlab] Laser Hacking #3
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
as far as i my browser tabs can remember: stc89c52rc
ruza
On 12/15/2010 08:57 PM, George Blackhead wrote:
One more thing on this subject:
We should try to check out datasheets of the target chip to find out what is protocol overhead and what is the firmware code block...
OR
I don't remember the chip's part number, but it should be revealed from inside of the box - right from the chip/Windows driver VEN_/DEV_ ID. I remember I found some other fw for this chip on the internet. We should try to upload that "other" firmware to the chip. It would not work for the ILDA decoder, but it should show us the way...
;-)
Blackhead
-----Original Message----- From: brmlab-bounces@brmlab.cz [mailto:brmlab-bounces@brmlab.cz]On Behalf Of Felipe Sanches Sent: Wednesday, December 15, 2010 6:02 AM To: Brmlab: Hackerspace Prague (main discussion) Subject: Re: [Brmlab] Laser Hacking #3
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
Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
bad thing is that the pdf was not really corrupter or incompatible with evince. The issue was that the pdf was written in japanese, for which I did nont have fonts installed. I coudnt find any english version of the datasheets. The only useful information I gathered from looking at the pictures in the datasheet is that it contains a 8051 MCU and seems to have SPI and RS232 interfaces.
On Wed, Dec 15, 2010 at 6:16 PM, Pavel Ruzicka ruza@ruza.eu wrote:
as far as i my browser tabs can remember: stc89c52rc
ruza
On 12/15/2010 08:57 PM, George Blackhead wrote:
One more thing on this subject:
We should try to check out datasheets of the target chip to find out what is protocol overhead and what is the firmware code block...
OR
I don't remember the chip's part number, but it should be revealed from inside of the box - right from the chip/Windows driver VEN_/DEV_ ID. I remember I found some other fw for this chip on the internet. We should try to upload that "other" firmware to the chip. It would not work for the ILDA decoder, but it should show us the way...
;-)
Blackhead
-----Original Message----- From: brmlab-bounces@brmlab.cz [mailto:brmlab-bounces@brmlab.cz]On Behalf Of Felipe Sanches Sent: Wednesday, December 15, 2010 6:02 AM To: Brmlab: Hackerspace Prague (main discussion) Subject: Re: [Brmlab] Laser Hacking #3
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
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
On Wed, Dec 15, 2010 at 09:23:23PM -0200, Felipe Sanches wrote:
bad thing is that the pdf was not really corrupter or incompatible with evince. The issue was that the pdf was written in japanese, for which I did nont have fonts installed.
Install poppler-data if on Debian/Ubuntu.
I coudnt find any english version of the datasheets. The only useful information I gathered from looking at the pictures in the datasheet is that it contains a 8051 MCU and seems to have SPI and RS232 interfaces.
poppler-0.15.3 + bug 27290 fix + pdftohtml -c -zoom + google translate can do a pretty neat job:
http://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=htt...
Sure, it's not perfect, but hope it helps a bit anyway. (With the whole datasheet on single page, Google refuses to translate more than just the first few pages.)
PS: BTW, if someone is interested, offering such "brm-show me chinese datasheet" web service would be a pretty neat hack - dealing with them is pain for a lot of people now I guess. If someone is willing to do the coding, I can explain exactly how to do the conversion and have a server to run it on.
Petr "Pasky" Baudis
I have already found the english version of the datasheet!
actually, you should check out my latest blogpost: http://jucablues.blogspot.com/2010/12/coordinating-efforts-towards-free.html
On Wed, Dec 22, 2010 at 12:51 AM, Felipe Sanches juca@members.fsf.org wrote:
I have already found the english version of the datasheet!
Tak to je hodne husty... Vono to fakt prelozi...
:-)
-----Original Message----- From: brmlab-bounces@brmlab.cz [mailto:brmlab-bounces@brmlab.cz]On Behalf Of Petr Baudis Sent: Wednesday, December 22, 2010 3:44 AM To: Brmlab: Hackerspace Prague (main discussion) Subject: Re: [Brmlab] Laser Hacking #3
On Wed, Dec 15, 2010 at 09:23:23PM -0200, Felipe Sanches wrote:
bad thing is that the pdf was not really corrupter or incompatible with evince. The issue was that the pdf was written in japanese, for which I did nont have fonts installed.
Install poppler-data if on Debian/Ubuntu.
I coudnt find any english version of the datasheets. The only useful information I gathered from looking at the pictures in the datasheet is that it contains a 8051 MCU and seems to have SPI and RS232 interfaces.
poppler-0.15.3 + bug 27290 fix + pdftohtml -c -zoom + google translate can do a pretty neat job:
http://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=htt... sky.or.cz%2F~pasky%2Fcp%2Fjunk%2Fstc%2Fstc89c52rc.html
Sure, it's not perfect, but hope it helps a bit anyway. (With the whole datasheet on single page, Google refuses to translate more than just the first few pages.)
PS: BTW, if someone is interested, offering such "brm-show me chinese datasheet" web service would be a pretty neat hack - dealing with them is pain for a lot of people now I guess. If someone is willing to do the coding, I can explain exactly how to do the conversion and have a server to run it on.
Petr "Pasky" Baudis _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz http://rover.ms.mff.cuni.cz/mailman/listinfo/brmlab
On Wed, Dec 22, 2010 at 03:44:11AM +0100, Petr Baudis wrote:
poppler-0.15.3 + bug 27290 fix + pdftohtml -c -zoom + google translate can do a pretty neat job:
http://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=htt...
Sure, it's not perfect, but hope it helps a bit anyway. (With the whole datasheet on single page, Google refuses to translate more than just the first few pages.)
PS: BTW, if someone is interested, offering such "brm-show me chinese datasheet" web service would be a pretty neat hack - dealing with them is pain for a lot of people now I guess. If someone is willing to do the coding, I can explain exactly how to do the conversion and have a server to run it on.
I couldn't sleep tonight so here is something very rudimental:
Example:
Hope someone finds it useful. (You can also advertise it on 27C3 a bit too, if you want! :-) (You can link to http://log.or.cz/?p=110.)
Nite,
-
Ax -
Cestmir Houska -
Felipe Sanches -
George Blackhead -
niekt0 -
Pavel Ruzicka -
Pavol Rusnak -
Petr Baudis