Re: Serious side effect of #6299 (silencing salut so gabble can connect)

2008-02-17 Thread David Woodhouse

On Thu, 2008-02-14 at 17:56 -0200, Ricardo Carrano wrote:
 If you don't turn many XOs on at the same time, you won't have salut
 preventing gabble to work.
 My fear is that we are complicating things unnecessarily.

But we _do_ turn on many XOs at the same time. Hell, we've seen one
teacher putting the kids through what seemed like rifle drill, opening
them up by numbers at the start of the lesson...

-- 
dwmw2

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Serious side effect of #6299 (silencing salut so gabble can connect)

2008-02-17 Thread Ricardo Carrano
On Thu, 2008-02-14 at 17:56 -0200, Ricardo Carrano wrote:
  If you don't turn many XOs on at the same time, you won't have salut
  preventing gabble to work.
  My fear is that we are complicating things unnecessarily.

 But we _do_ turn on many XOs at the same time. Hell, we've seen one
 teacher putting the kids through what seemed like rifle drill, opening
 them up by numbers at the start of the lesson...


Thanks David, that's useful information.

Two premises (that need confirmation)
1 - It seems that running neither of two (salut and gabble) brings us some
serious troubles (for now, at least).
2 - The fall back mechanism (if gabble then shut salut down) seems an easy
fix.

So, my suggestion is that we just test the scenario where only  2  is
activated. It should be an easy test to make.

I agree that there is a chance of it not working, but It is worth testing
anyway, because:
1 - It is an  inexpensive test
2 - there is a chance (maybe small, I agree) it might save us a lot of work.

It is a shame we don't know the timings involved. I even think to myself
(and also write it down ;-) if gabble can handle the rifle drill, anyway.

A good thing we will have an opportunity to test this soon.

--
 dwmw2


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: using the browser as an activity platform : pyxpcom / hulahop / Gears

2008-02-17 Thread ffm
On Feb 16, 2008 6:21 PM, Samuel Klein [EMAIL PROTECTED] wrote:

 The core use here is being able to use the browser as activity
 platform -- letting web developers good at JS code and test on most
 any platform, and develop something that can be a first-class activity
 within Sugar.  One example is Dan's javascript spreadsheet, anothe ris
 a dynamic library (see for instance
 http://wiki.laptop.org/go/Dynamic_library), another is an existing web
 service online that one might want to run locally.

 In addition to pyxpcom, let me add Google Gears as a useful piece of
 this platform, especially when offering local use of popular online
 tools.  Off the top of my head, MediaWiki, MindMeister, I copy Ben
 Lisbakken, a gears maintainer, who reports that there is a Gears patch
 to make it work without extension support...


Is there any way that one could get involved with the google-gears-on-the-xo
spec drafting/implementation process? This is something I might be
interested in contributing to, but I cannot find anything about it on the
wiki.


-FFM
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Semi-successful Bayer-mode capture from internal camera

2008-02-17 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have created a stepwise procedure for experimenting with Bayer mode capture:

1. su -
2. yum install python-imaging
3. wget http://dev.laptop.org/~bemasc/bayertest.tar.gz
4. tar xzvf bayertest.tar.gz
5. cd bayertest
6. python bayertest.py

bayertest.py will produce a file output.png containing your picture, after
interpolation by dcraw.

Sample Raw bayer:
http://dev.laptop.org/~bemasc/storefront_input.png
Sample Interpolated:
http://dev.laptop.org/~bemasc/storefront_output.png

HUGE BUG:
1. After each reboot YOU MUST OPEN Record (or any other program that uses
gstreamer to access the camera) BEFORE RUNNING bayertest.py.  Otherwise, your
images will be squished into the left half of the field.  I have no idea why.
It's pretty weird.

Other bugs:
2. The included, patched version of dcraw assumes a bayer-grid orientation that
does not match the camera's.  Therefore, the temporary files are rotated by 180
degrees, and then rotated back afterwards.  This is only an annoyance if you
want to look at the raw data yourself.
3. The rightmost 4 pixels of each line are just repeats.  I have no idea why.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHuJl2UJT6e6HFtqQRAkvoAJ4qm4++SAic3QUZD+FQdK+rPmQ9aQCeLqQB
znVoSQZpGuP/OPt2UnJMHZc=
=yNK/
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Semi-successful Bayer-mode capture from internal camera

2008-02-17 Thread Carol Lerche
From this resource:
http://www.quickcamteam.net/documentation/how-to/how-to-enable-raw-streaming-on-logitech-webcams

If Bayer images are captured in any resolution lower than the maximum
resolution supported by the sensor, clipping occurs. For example, if
the sensor supports 1280x960 and a 960x720 image is recorded, the
frame will appear clipped at the right and lower borders.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: bar code scanners on the XO

2008-02-17 Thread Ivan Krstić
On Feb 15, 2008, at 4:35 PM, Benjamin M. Schwartz wrote:
 As you are probably aware, it is possible to read barcodes from the
 camera, using software analysis.

We have code in git that encodes arbitrary (but size-constrained) data  
as a redundant datamatrix barcode and shows it on the screen, and code  
that performs image analysis from a camera capture when one XO is  
pointed at another with such a barcode on the screen to decode the  
original data:

 http://dev.laptop.org/git?p=projects/barcode;a=tree

The original purpose was to facilitate a physical public key exchange  
(digital introduction) by holding two laptops up to one another.

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: bar code scanners on the XO

2008-02-17 Thread Ivan Krstić
On Feb 15, 2008, at 4:24 PM, Walter Bender wrote:
 Has anyone used a USB bar code scanner on the XO?


I've used several, both CCD- and laser-based. They register as normal  
keyboards, so no extra support is required; there's a CCD-based one in  
my office if you want to play with it. For reference, Uruguay is using  
these:

 http://www.nationalbarcode.com/datalogic/DataLogic-Firescan- 
D131.htm

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: bar code scanners on the XO

2008-02-17 Thread Ivan Krstić
On Feb 17, 2008, at 4:39 PM, Ivan Krstić wrote:
 For reference, Uruguay is using these:


Once more, with the link unmangled:

 http://www.nationalbarcode.com/datalogic/DataLogic-Firescan-D131.htm 
 

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Digital Introduction (was: bar code scanners on the XO)

2008-02-17 Thread ffm
On Feb 17, 2008 9:36 PM, Ivan Krstić [EMAIL PROTECTED]
wrote:

 On Feb 15, 2008, at 4:35 PM, Benjamin M. Schwartz wrote:
  As you are probably aware, it is possible to read barcodes from the
  camera, using software analysis.

 We have code in git that encodes arbitrary (but size-constrained) data
 as a redundant datamatrix barcode and shows it on the screen, and code
 that performs image analysis from a camera capture when one XO is
 pointed at another with such a barcode on the screen to decode the
 original data:

 http://dev.laptop.org/git?p=projects/barcode;a=tree

 The original purpose was to facilitate a physical public key exchange
 (digital introduction) by holding two laptops up to one another.


So what happened to the idea? I'd think it would be interesting.

Any reason it was scrapped?

-FFM
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Signal power level (eth0 and msh0)

2008-02-17 Thread Arjun Sarwal
* Why is the signal level indicated by iwconfig in eth0 and msh0
different ? There is one module which is tuned to one frequency, so I
can't understand why it should be different ?
* What does the noise power level indicate in physical terms ? The
module is tuned to one particular frequency, how does this relate to
noise power and/or how it this being calculated ?


thanks
Arjun
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Signal power level (eth0 and msh0)

2008-02-17 Thread James Cameron
On Sun, Feb 17, 2008 at 08:14:20PM -0500, Arjun Sarwal wrote:
 * Why is the signal level indicated by iwconfig in eth0 and msh0
 different ? There is one module which is tuned to one frequency, so I
 can't understand why it should be different ?

I don't know.  But the signal level for managed mode is the path from
the access point to the receiver, and for mesh mode will vary instant by
instant according to which mesh node is transmitting.  Perhaps the data
is averaged.  The snr for each mesh neighbour can also be found with
iwpriv.

I suspect that the Linux network interface simplication simply does not
hold true for this novel design.

 * What does the noise power level indicate in physical terms ? The
 module is tuned to one particular frequency, how does this relate to
 noise power and/or how it this being calculated ?

I don't know.  But in my tests noise level represents the expectation of
interference from other radio sources, therefore it goes up with
solar flux, temperature and proximity to population clusters.  There has
to be sufficient difference between the noise level and the signal level
before the signal can be used.

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Digital Introduction (was: bar code scanners on the XO)

2008-02-17 Thread Ivan Krstić
On Feb 17, 2008, at 7:47 PM, ffm wrote:
 Any reason it was scrapped?

It wasn't scrapped; it's on the backburner because higher-priority  
issues needed to be dealt with first, and the subsystems that would  
most benefit from an out-of-band public key exchange (like Telepathy)  
can't deal with KCM-style PKI yet.

--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Serious side effect of #6299 (silencing salut so gabble can connect)

2008-02-17 Thread Morgan Collett
Ricardo Carrano wrote:

 Two premises (that need confirmation)
 1 - It seems that running neither of two (salut and gabble) brings us
 some serious troubles (for now, at least).

In case you missed some of the mails, it turned out only Pippy needed
fixing in the short term, and that's now done as of Joyride-1701. We
should therefore be OK.

We need someone at 1cc to test whether that build does indeed notice the
schoolserver and keep salut off for 2 minutes while it tries to connect
to the jabber server. You would need some laptops on salut on the
appropriate mesh channel so you can see their absence running this
build, and you would need a schoolserver running the jabber server.
Also, try it with the jabber server disabled so you can verify the salut
buddies come back after 2 minutes (the time we disable salut).

 2 - The fall back mechanism (if gabble then shut salut down) seems an
 easy fix.
 
 So, my suggestion is that we just test the scenario where only  2  is
 activated. It should be an easy test to make.

Let me clarify how Presence Service runs the Telepathy Connection
Managers (CMs):

* Initially we had only gabble while salut was being developed.
* When we added salut, it was in such a way that the CMs could run
independently and simultaneously.
* However, with both CMs running there's nothing in the UI that shows
which connection a given buddy is on, or a given activity. So not all
the buddies in mesh view can be invited to a given shared activity, or
see a given shared activity.
* In the runup to Trial 2 (IIRC) we turned the simultaneous running of
CMs off, so that it would be clear that all buddies you can see at a
given time should be able to participate in a shared activity. You
therefore see either server buddies (gabble) or mesh buddies (salut).

The current algorithm, as it has been since then, is to start both
plugins (server_plugin talking to gabble, and linklocal_plugin to salut)
when Presence Service starts, and then whenever gabble succeeds in
connecting to the jabber server, stop salut (linklocal_plugin) and
whenever gabble disconnects from the server or otherwise goes away,
restart salut (linklocal_plugin).

This means that in practice, if you have a working jabber server
configured, Presence Service starts both, and salut succeeds in
connecting first. You then see mesh buddies for a short time, while
gabble is connecting to the jabber server.

Here's the key: *if* gabble succeeds in connecting to the jabber server,
*then* we stop salut. That is a problem in an overly busy mesh, because
we are not able to connect to the jabber server.

That's the meltdown scenario we are trying to avoid, by detecting the
evidence of a schoolserver on the mesh, and stopping salut for a short
while to give gabble a chance to connect.

This would only work if all the laptops did the same - so if a bunch of
laptops were fired up at the same time, they would all simultaneously
*not* run salut, succeed in connecting to the jabber server, and then
run using unicast, which should not overwhelm the mesh.

Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel