Two comments inline - this looks good to me, but i'll need to apply it
to see whats up with GX. Next step is to toss it into the playground,
I guess to get some miles on it before Andres pulls it in.
On 19/09/07 18:59 -0400, Bernardo Innocenti wrote:
> diff --git a/drivers/video/fbmem.c b/driver
Jim Gettys wrote:
> I agree we'll want to do the DRM work, but it's not finished yet. That
> is probably X server 1.5 or 1.6 (February or next summer) as far as I
> can tell.
Yeah, airlied warned me about it :-(
--
// Bernardo Innocenti - http://www.codewiz.org/
\X/ One Laptop Per Child -
Here's a proposed patch for the green icons bug. I'm afraid it came
up a bit long and somewhat invasive.
Tested on B4: OK!
Tested on B2: KO (does not unfreeze the screen when Sugar comes up)
I must have broken something in the GX part when I merged the two powerup()
and powerdown() functions, bu
I was having some problemns with hight memory leak when working with pixbufs
in pygtk.
The problem and its solution are very well detailed in:
http://osdir.com/ml/gnome.gtk+.python/2003-12/msg00053.html
Cheers
--
Rafael Barbolo Lopes
http://rafaelbarbolo.blogspot.com/
___
> - Seeing if we can get the blitter to read source data directly from system
>memory. I'd be very surprised if there was no way to make it work
>with virtual memory enabled, because, without such a mechanism, the
>blitter would be less than fully useful.
>
>
>
Could somebody shed
On 9/16/07, Mike C. Fletcher <[EMAIL PROTECTED]> wrote:
> > Don't worry too much about upgrading -- as long as your developer
> > tools are in /home/olpc they will be preserved across updates by the
> > upgrade magic which is going to land on Monday.
> Is that magic already in-place? If so, how is
I agree we'll want to do the DRM work, but it's not finished yet. That
is probably X server 1.5 or 1.6 (February or next summer) as far as I
can tell.
- Jim
On Wed, 2007-09-19 at 08:14 -0400, Bernardo Innocenti wrote:
> Jordan Crouse wrote:
>
> >> Is it ok to commit,
Sorry I seem to be dense this morning... I just reassigned 3112 to myself;
please go ahead and update it with more details (hom much disk space you
will probably need etc) however.
On 9/19/07, Danny Clark <[EMAIL PROTECTED]> wrote:
>
> Hi Mike,
>
> I'm Danny, the new OLPC sys admin. We should def
On 19/09/07 08:14 -0400, Bernardo Innocenti wrote:
> Jordan Crouse wrote:
>
> An interesting project for the near future would be adding DRM support
> to the amd driver.
Yes it would be. I'm not sure how much we would gain overall - but
having the interrupt support and better memory handling wo
Hi Mike,
I'm Danny, the new OLPC sys admin. We should def be able to get you
space somewhere to do this, although it won't happen immediatly due to
my current load. Could you open a ticket on http://dev.laptop.org with
details (approx resource requirements, etc) and assign it to me
(djbclark)?
Th
Note that this problem has exactly the symptoms seen by Carla, and that
I've seen over last weekend, and Dan has seen.
I think we should accept this patch.
- Jim
On Wed, 2007-09-19 at 07:58 -0400, Kim Quirk wrote:
> Dan,
> Please move this out to FRS and we can
Jim Gettys wrote:
> Ah, X's guilt is no more (in this instance): at the time you wrote that
> amusing tirade, there was no way to find out the memory consumption in
> the X server due to stupid clients: now there is (XRes)
It would be nice if we could integrate an xrestop-like utility in th
Ivan Krstić wrote:
> It's how memory is normally managed for Python modules that's
> problematic; security has little to do with it. There are some
> efforts around making Python's memory management more friendly to
> embedded(ish) platforms, and we need to see if we stand to benefit
> fro
Jim Gettys wrote:
> Don't confuse virtual address space used with RAM consumed: most of that
> is shared memory (glibc, pango, gtk+).
>
> That's why memphis was written and is in our build: ps gives very
> misleading memory usage statistics, unless you really understand what it
> is reportin
Jordan Crouse wrote:
>> Is it ok to commit, for now?
>
> For always. It *is* the permanent fix for the problem.
I see you've committed it already, and Dan pushed an updated amd driver
in the latest build. Thus, closing #3352 as fixed.
Yesterday I also went to #xorg-devel and asked Keith Packa
Dan,
Please move this out to FRS and we can continue some testing and discussion
as to whether the default should be channel 1.
If two laptops under a tree come up about the same time I think it is
conceivable (maybe it will be the normal case) that they each start a mesh
on different channels and
On Wed, 2007-09-19 at 07:50 -0400, Dan Williams wrote:
> On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
> > I would recommend not making the patch; I think I found it confusing
> > only because I didn't know that random impacted link-local. But do we
> > still default to channel 1 if no sc
On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
> I would recommend not making the patch; I think I found it confusing
> only because I didn't know that random impacted link-local. But do we
> still default to channel 1 if no school server is found?
No, I'm not confident that we do.
Dan
http://wiki.laptop.org/go/OLPC_Firmware_q2c27
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
I would recommend not making the patch; I think I found it confusing
only because I didn't know that random impacted link-local. But do we
still default to channel 1 if no school server is found?
-walter
On 9/18/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> #3593: Mesh channel randomizat
20 matches
Mail list logo
