Re: ip4-address buddy property - still needed?
On Nov 2, 2007, at 9:17 PM, Marco Pesenti Gritti wrote: > Also I think integrating and properly supporting Pascal's log > collector would go a long way in facilitating testing. Working on this bit. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 11/3/07, Walter Bender <[EMAIL PROTECTED]> wrote: > Did this ticket every get opened? I think a lot of problems would be solved > if you could open the various consoles on someone else's XO... I haven't seen tickets yet. Opening Log and Analyze remotely should be relatively easy. Also I think integrating and properly supporting Pascal's log collector would go a long way in facilitating testing. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Michail Bletsas <[EMAIL PROTECTED]> wrote: > Yes, we need a relatively user-friendly way to query for that information. > I don't reall care what it is called as long as I can instruct somebody to > bring it up with a minimum number of clicks. I think key bindings for both Log and Analyze could be useful for developers and maybe they could also be a quick way to instruct people. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
Did this ticket every get opened? I think a lot of problems would be solved if you could open the various consoles on someone else's XO... -walter On 10/30/07, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > > On 10/30/07, Erik Blankinship <[EMAIL PROTECTED]> wrote: > > While I welcome the new activities and think it is great to integrate > them > > into sugar, can we reconsider completely doing away with the dev > console? > > It is /very/ useful to have the console open on an xo while the activity > you > > are debugging is running behind it. > > > > Can't you have both the old console and the new activities? > > Once the new activities are in, please give them a try a report the > usability issues you are finding with them on a ticket. We can > rediscuss this with Eben and see how can we best solve the problems. > > Thanks, > Marco > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Retry frame transmission when libertas driver is busy.
Andres, On 11/2/07, Andres Salomon <[EMAIL PROTECTED]> wrote: > On Fri, 02 Nov 2007 12:54:35 -0700 (PDT) > Ashish Shukla <[EMAIL PROTECTED]> wrote: > > So, uh.. This patch is from Javier, but was originally written by > Ashish? Did I get the attribution right? :) It's from Ashish. I just verified it and forwarded it on his behalf. > Is this simply a workaround to make the driver more reliable with the > (broken) p0 firmware, or is it an actual fix (ie, is the proper > behavior to be returning NETDEV_TX_BUSY rather than dropping packets)? It's an actual fix: the driver should not drop frames in that situation. There is also a firmware fix that the QA team has tested together with this patch. Javier -- Javier Cardona cozybit Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] Retry frame transmission when libertas driver is busy.
The driver silently discards frames when some command is pending -- returns
NETDEV_TX_OK to kernel. The following patch fixes this problem. This
significantly improves file transfers while scanning (ticket #3341).
Signed-off-by: Javier Cardona <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 83d534b..f72ebe2 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -520,22 +520,25 @@ static int libertas_close(struct net_device *dev)
static int libertas_hard_start_xmit(struct sk_buff *skb, struct net_device
*dev)
{
- int ret = 0;
+ int ret = NETDEV_TX_OK;
wlan_private *priv = dev->priv;
lbs_deb_enter(LBS_DEB_NET);
- if (priv->dnld_sent || priv->adapter->TxLockFlag) {
- priv->stats.tx_dropped++;
- goto done;
- }
-
netif_stop_queue(priv->dev);
if (priv->mesh_dev)
netif_stop_queue(priv->mesh_dev);
- if (libertas_process_tx(priv, skb) == 0)
+ if (priv->dnld_sent || priv->adapter->TxLockFlag) {
+ ret = NETDEV_TX_BUSY;
+ goto done;
+ }
+
+ ret = libertas_process_tx(priv, skb);
+ if (ret == NETDEV_TX_OK)
dev->trans_start = jiffies;
+ else if (ret == -1)
+ ret = NETDEV_TX_OK;
done:
lbs_deb_leave_args(LBS_DEB_NET, "ret %d", ret);
return ret;
diff --git a/drivers/net/wireless/libertas/tx.c
b/drivers/net/wireless/libertas/tx.c
index bc9c2e1..1dc92ee 100644
--- a/drivers/net/wireless/libertas/tx.c
+++ b/drivers/net/wireless/libertas/tx.c
@@ -218,6 +218,7 @@ int libertas_process_tx(wlan_private * priv, struct sk_buff
*skb)
if (priv->dnld_sent) {
lbs_pr_alert( "TX error: dnld_sent = %d, not sending\n",
priv->dnld_sent);
+ ret = NETDEV_TX_BUSY;
goto done;
}
--
1.5.2.4
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Conversion to Gray Scale May Not Be Trivial how to make a grayscale image?
The context of the conversation is simply to display a temporary grayscale still frame from a video file during a compression step, which won't be saved and needn't have high contrast. This thread is certainly interesting, though, and may prove useful in other areas later. - Eben On 11/2/07, Seth Woodworth <[EMAIL PROTECTED]> wrote: > There are around four completely different methods for converting to > grayscale in photoshop or gimp. Averaging luminosoty values, aka, Convert > to grayscale, is by most accounts the least interesting method in most > circumstances. I've worked in pre-press in both color and grayscale > separations, so I've played with each of the versions at one time or > another. What exactly are we talking about here? Record activity or > backlight-off mode? > > > On 11/2/07, Ed Trager <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > On 11/2/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > > On Nov 2, 2007, at 3:16 , Albert Cahalan wrote: > > > > > > > Eben Eliason writes: > > > > > > > >> Roughly speaking, you can calculate a colored pixel's effective > > > >> luminance by: > > > >> > > > >> Y = 0.3*R+0.59*G+0.11*B > > > > I assume that this equation is taking into account the relative > > sensitivity of the human eye to the 3 primary colors, correct? > > > > But even if this does take into consideration the relative sensitivity > > of cones in the human retina, does this equation preserve contrast > > sufficiently well or not? > > > > When we take a colored photograph of something like American Holly > > (Ilex aquifolium) and convert it to grayscale, the contrast between > > the red berries and the green leaves often disappears. For example, > > you can try this in Gimp and you'll see that the result is often not > > very satisfying. As far as I know, Gimp only provides one option for > > converting from color to grayscale. > > > > I believe a lot of research has been done for many years in the area > > of how to convert colored images to black and white. Software like > > the Gimp ought actually to provide several methods of doing the > > conversion, but to the best of my knowledge only provides one. > > > > Having seen this topic arise on OLPC's mailing list, I am now > > wondering out of curiousity to what extent OLPC has researched and > > considered the possible solutions to this problem beyond the > > "standard" equations? > > > > Another thing very worth considering is the fact that nearly 8% of the > > male human population world wide is red-green color blind. Color > > schemes dominated by blues and yellows work best for such individuals. > > The reason for this should be apparent from examining the attached > > .png file comparing the appearance of 9 colors in (a) with how they > > appear approximately to someone with red-green color deficiency in > > (b). > > > > (FYI - I work at an Eye Center where I am often reminded by the > > scientists and doctors around here about such things) > > > > Best - Ed > > > > > > > > > > To be clear on why this is rough: it performs an operation > > > > on non-linear data which is only valid on linear data. > > > > That is, it ignores gamma. > > > > > > > > From best to worst: > > > > > > > > a. convert to linear, Y = 0.3*R+0.59*G+0.11*B, convert back > > > > b. square, Y = 0.3*R+0.59*G+0.11*B, square root > > > > c. Y = 0.3*R+0.59*G+0.11*B > > > > d. Y = (R+G+G+B)>>2 > > > > e. Y = G > > > > > > > > FYI, most interesting image operations are only valid on > > > > linear data. This includes scaling and alpha blending. > > > > Lots of programmers degrade images by screwing this up. > > > > We should all try to do better, especially when the image > > > > is something that might be important to the user. > > > > > > Right. For example, am I the only one who is bothered by the huge > > > change in perceived brightness of different colors when you switch > > > the DCON to grayscale mode? This switch from swizzling to the per- > > > pixel brightness calculation gives a huge difference. > > > > > > - Bert - > > > > > > > > > ___ > > > Devel mailing list > > > Devel@lists.laptop.org > > > http://lists.laptop.org/listinfo/devel > > > > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > > > > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Conversion to Gray Scale May Not Be Trivial how to make a grayscale image?
There are around four completely different methods for converting to grayscale in photoshop or gimp. Averaging luminosoty values, aka, Convert to grayscale, is by most accounts the least interesting method in most circumstances. I've worked in pre-press in both color and grayscale separations, so I've played with each of the versions at one time or another. What exactly are we talking about here? Record activity or backlight-off mode? On 11/2/07, Ed Trager <[EMAIL PROTECTED]> wrote: > > Hi, > > On 11/2/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > > On Nov 2, 2007, at 3:16 , Albert Cahalan wrote: > > > > > Eben Eliason writes: > > > > > >> Roughly speaking, you can calculate a colored pixel's effective > > >> luminance by: > > >> > > >> Y = 0.3*R+0.59*G+0.11*B > > I assume that this equation is taking into account the relative > sensitivity of the human eye to the 3 primary colors, correct? > > But even if this does take into consideration the relative sensitivity > of cones in the human retina, does this equation preserve contrast > sufficiently well or not? > > When we take a colored photograph of something like American Holly > (Ilex aquifolium) and convert it to grayscale, the contrast between > the red berries and the green leaves often disappears. For example, > you can try this in Gimp and you'll see that the result is often not > very satisfying. As far as I know, Gimp only provides one option for > converting from color to grayscale. > > I believe a lot of research has been done for many years in the area > of how to convert colored images to black and white. Software like > the Gimp ought actually to provide several methods of doing the > conversion, but to the best of my knowledge only provides one. > > Having seen this topic arise on OLPC's mailing list, I am now > wondering out of curiousity to what extent OLPC has researched and > considered the possible solutions to this problem beyond the > "standard" equations? > > Another thing very worth considering is the fact that nearly 8% of the > male human population world wide is red-green color blind. Color > schemes dominated by blues and yellows work best for such individuals. > The reason for this should be apparent from examining the attached > .png file comparing the appearance of 9 colors in (a) with how they > appear approximately to someone with red-green color deficiency in > (b). > > (FYI - I work at an Eye Center where I am often reminded by the > scientists and doctors around here about such things) > > Best - Ed > > > > > > > To be clear on why this is rough: it performs an operation > > > on non-linear data which is only valid on linear data. > > > That is, it ignores gamma. > > > > > > From best to worst: > > > > > > a. convert to linear, Y = 0.3*R+0.59*G+0.11*B, convert back > > > b. square, Y = 0.3*R+0.59*G+0.11*B, square root > > > c. Y = 0.3*R+0.59*G+0.11*B > > > d. Y = (R+G+G+B)>>2 > > > e. Y = G > > > > > > FYI, most interesting image operations are only valid on > > > linear data. This includes scaling and alpha blending. > > > Lots of programmers degrade images by screwing this up. > > > We should all try to do better, especially when the image > > > is something that might be important to the user. > > > > Right. For example, am I the only one who is bothered by the huge > > change in perceived brightness of different colors when you switch > > the DCON to grayscale mode? This switch from swizzling to the per- > > pixel brightness calculation gives a huge difference. > > > > - Bert - > > > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Hosting application for Creative Commons licensing information activity
1. Project name : cclicensing 2. Existing website, if any : [None] 3. One-line description : Activity to explain CC licensing 4. Longer description : A simple activity to show a cartoon : CC is developing to explain Creative : Commons licensing to XO users and their : parents. 5. URLs of similar projects : 6. Committer list Please list the maintainer (lead developer) as the first entry. Only list developers who need to be given accounts so that they can commit to your project's code repository, or push their own. There is no need to list non-committer developers. UsernameFull name SSH2 key URL E-mail - -- #1 paulproteus Asheesh Laroia [*][EMAIL PROTECTED] *. https://launchpad.net/%7Eubuntu-asheesh/+sshkeys If any developers don't have their SSH2 keys on the web, please attach them to the application e-mail. 7. Preferred development model [X] Central tree. Every developer can push his changes directly to the project's git tree. This is the standard model that will be familiar to CVS and Subversion users, and that tends to work well for most projects. [ ] Maintainer-owned tree. Every developer creates his own git tree, or multiple git trees. He periodically asks the maintainer to look at one or more of these trees, and merge changes into the maintainer-owned, "main" tree. This is the model used by the Linux kernel, and is well-suited to projects wishing to maintain a tighter control on code entering the main tree. If you choose the maintainer-owned tree model, but wish to set up some shared trees where all of your project's committers can commit directly, as might be the case with a "discussion" tree, or a tree for an individual feature, you may send us such a request by e-mail, and we will set up the tree for you. 8. Set up a project mailing list: [ ] Yes, named after our project name [ ] Yes, named __ [X] No When your project is just getting off the ground, we suggest you eschew a separate mailing list and instead keep discussion about your project on the main OLPC development list. This will give you more input and potentially attract more developers to your project; when the volume of messages related to your project reaches some critical mass, we can trivially create a separate mailing list for you. If you need multiple lists, let us know. We discourage having many mailing lists for smaller projects, as this tends to stunt the growth of your project community. You can always add more lists later. 9. Commit notifications [ ] Notification of commits to the main tree should be e-mailed to the list we chose to create above [ ] A separate mailing list, -git, should be created for commit notifications [X] No commit notifications, please 10. Shell accounts As a general rule, we don't provide shell accounts to developers unless there's a demonstrated need. If you have one, please explain here, and list the usernames of the committers above needing shell access. 11. Notes/comments: Thanks! -- Asheesh. -- Nirvana? That's the place where the powers that be and their friends hang out. -- Zonker Harris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Conversion to Gray Scale May Not Be Trivial how to make a grayscale image?
Hi, On 11/2/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > On Nov 2, 2007, at 3:16 , Albert Cahalan wrote: > > > Eben Eliason writes: > > > >> Roughly speaking, you can calculate a colored pixel's effective > >> luminance by: > >> > >> Y = 0.3*R+0.59*G+0.11*B I assume that this equation is taking into account the relative sensitivity of the human eye to the 3 primary colors, correct? But even if this does take into consideration the relative sensitivity of cones in the human retina, does this equation preserve contrast sufficiently well or not? When we take a colored photograph of something like American Holly (Ilex aquifolium) and convert it to grayscale, the contrast between the red berries and the green leaves often disappears. For example, you can try this in Gimp and you'll see that the result is often not very satisfying. As far as I know, Gimp only provides one option for converting from color to grayscale. I believe a lot of research has been done for many years in the area of how to convert colored images to black and white. Software like the Gimp ought actually to provide several methods of doing the conversion, but to the best of my knowledge only provides one. Having seen this topic arise on OLPC's mailing list, I am now wondering out of curiousity to what extent OLPC has researched and considered the possible solutions to this problem beyond the "standard" equations? Another thing very worth considering is the fact that nearly 8% of the male human population world wide is red-green color blind. Color schemes dominated by blues and yellows work best for such individuals. The reason for this should be apparent from examining the attached .png file comparing the appearance of 9 colors in (a) with how they appear approximately to someone with red-green color deficiency in (b). (FYI - I work at an Eye Center where I am often reminded by the scientists and doctors around here about such things) Best - Ed > > > > To be clear on why this is rough: it performs an operation > > on non-linear data which is only valid on linear data. > > That is, it ignores gamma. > > > > From best to worst: > > > > a. convert to linear, Y = 0.3*R+0.59*G+0.11*B, convert back > > b. square, Y = 0.3*R+0.59*G+0.11*B, square root > > c. Y = 0.3*R+0.59*G+0.11*B > > d. Y = (R+G+G+B)>>2 > > e. Y = G > > > > FYI, most interesting image operations are only valid on > > linear data. This includes scaling and alpha blending. > > Lots of programmers degrade images by screwing this up. > > We should all try to do better, especially when the image > > is something that might be important to the user. > > Right. For example, am I the only one who is bothered by the huge > change in perceived brightness of different colors when you switch > the DCON to grayscale mode? This switch from swizzling to the per- > pixel brightness calculation gives a huge difference. > > - Bert - > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > <>___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode
Bert Freudenberg wrote: > On Nov 2, 2007, at 1:39 , Brian Carnes wrote: > Short of rewriting, should simply recompiling with the better gcc > work? That is, even if the system did not yet switch to the geode- > specific libs, is it possible to recompile single apps with Rob's gcc > 4.3 and have them work with the rest? Yes. I do this with Gnash all the time. The GCC 4.3 I'm using is actually a SVN snapshot, so lately I've been using the same patch with the current GCC release of 4.2.1. GCC 4.1.x has some weird bugs on x86 platforms. - rob - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bitfrost compliance for Update.1
On Nov 2, 2007, at 3:28 , Walter Bender wrote: > 1. File-path compliance means that you must ensure your activity > does not write to any path outside of that contained in the > environment variable SUGAR_ACTIVITY_ROOT; specifically > subdirectories called 'data', 'conf' and 'tmp' within the > SUGAR_ACTIVITY_ROOT directory. (We are working with the Sugar team > to provide helper functions for easily getting those three > directory paths for those of you using Python. Until then, please > depend on the environment variable directly.) Guessing from the names, is this what these directories are for? $SUGAR_ACTIVITY_ROOT/data # contents preserved after exit, private to one activity instance $SUGAR_ACTIVITY_ROOT/conf # contents preserved after exit, shared with all activity instances $SUGAR_ACTIVITY_ROOT/tmp# contents deleted after exit, private to one activity instance I started documentation for this at http://wiki.laptop.org/go/Low-level_Activity_API#Security - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode
On 11/1/07, Brian Carnes <[EMAIL PROTECTED]> wrote: > 3. Measure how these improvements affect real-world responsiveness (pick > some easy-to-time metrics in common XO apps) I vote for page load metrics for the Web activity. SJ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: how to make a grayscale image?
On Nov 2, 2007, at 3:16 , Albert Cahalan wrote: > Eben Eliason writes: > >> Roughly speaking, you can calculate a colored pixel's effective >> luminance by: >> >> Y = 0.3*R+0.59*G+0.11*B > > To be clear on why this is rough: it performs an operation > on non-linear data which is only valid on linear data. > That is, it ignores gamma. > > From best to worst: > > a. convert to linear, Y = 0.3*R+0.59*G+0.11*B, convert back > b. square, Y = 0.3*R+0.59*G+0.11*B, square root > c. Y = 0.3*R+0.59*G+0.11*B > d. Y = (R+G+G+B)>>2 > e. Y = G > > FYI, most interesting image operations are only valid on > linear data. This includes scaling and alpha blending. > Lots of programmers degrade images by screwing this up. > We should all try to do better, especially when the image > is something that might be important to the user. Right. For example, am I the only one who is bothered by the huge change in perceived brightness of different colors when you switch the DCON to grayscale mode? This switch from swizzling to the per- pixel brightness calculation gives a huge difference. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode
On Nov 2, 2007, at 1:39 , Brian Carnes wrote: > I'm intentionally overlooking some of the suggestions from the list > to go > rewrite existing applications to run better on the Geode, mostly > because > the above gives us more bang for our development-time-buck. Short of rewriting, should simply recompiling with the better gcc work? That is, even if the system did not yet switch to the geode- specific libs, is it possible to recompile single apps with Rob's gcc 4.3 and have them work with the rest? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
