Deployment Team Meeting Reminder (2008-11-26 14:00 UTC)
Hello We will be having our Deployment team meeting this wednesday (today) at 14:00 UTC (irc.freenode.net - channel: #sugar-meeting ) Here is the proposed agenda. http://sugarlabs.org/go/DeploymentTeam/Meetings#2008-11-19_meeting Everyone is invited to come ;). See you there. -- Sebastian Silva Iniciativa FuenteLibre http://blog.sebastiansilva.com/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running a motherboard without a keyboard
Hello It works [ 4300.811798] drivers/input/serio/i8042.c: 69 <- i8042 (interrupt, 0, 1) [427524] [ 4300.812015] drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [427524] [ 4300.937465] drivers/input/serio/i8042.c: fc <- i8042 (interrupt, 0, 1) [427537] [ 4301.011188] drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [427544] [ 4301.107998] drivers/input/serio/i8042.c: e9 <- i8042 (interrupt, 0, 1) [427554] [ 4301.134320] drivers/input/serio/i8042.c: fc <- i8042 (interrupt, 0, 1) [42755 The IRQ1 counts are also progressing. Only /dev/input/event3 is not bound to anything, and setkeycode logically fails On Tue, Nov 25, 2008 at 8:23 PM, Richard A. Smith <[EMAIL PROTECTED]> wrote: > Offhand I don't know what the kernel does > when you boot and nothing responds to the keyboard reset. Maybe it requires a tweak in i8042 module to give key even even if keyboard resent doesn't respond? Something like a module parameter ? Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
Note that the Embedded Controller firmware version is also important. I suppose there are still very many XOs out in the field with the original firmware. Since Q2E18(?) there was a change causing many more mouse packets to be delivered to the CPU. Also there was a change in mouse mode between ship.2 and update.1. Do not know what is out in the field. On a side note, I still have the touchpad jumpiness on my recently received G1G1-2008 XOs. I will get some debug logs and send them. Should I attach them to my original ticket (#7788)? Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New touchpad still has some jumpyness
On Tue, 2008-11-25 at 18:54 -0500, Richard A. Smith wrote: > During SJ's demo meeting today at 1cc I used my test machine with the > new touchpad. > The touchpad on my laptop is much deeper inset than > I still experienced jumpyness. However, a much different jumpyness > than what happens with the alps device. In my case it appears to happen > if the tip of my thumb gets up into the active area. (Creepage from > using it to click thThe touchpad on my laptop is much deeper inset than > e X button) What I saw was the cursor would leap to the edge of the > screen which is similar to what happens with the current pad, but unlike > the current pad its does not continue to leap around. It a one shot and > then returns to normal movement. This happened to me several times. > > So then I played with my HP laptop which also has a synaptics touchpad > and I'm able to duplicate the same behavior. It's worth a gander at the upstream synaptics driver; I've seen some patches go by recently. > > So even with the new touchpad we still may have to have some sort of > criteria for discarding packets with large deltas for the movement. > > By default in mouse mode the values reported by the device are relative. > So some sort of edge effect must confuse the controller. I need to > enable some logging and see what data the device actually sent. > > I've also noticed that the acceleration of the new touchpad is much less > than the alps device. When you switch from new to old the you can > really tell. We should reduce the acceleration of the cursor for the > alps device. Its not necessary to be that fast. > Yeah, the acceleration stuff in X sucks. Fixed in next release, IIRC (after something like 20 years...) > Is that something we can set defaults for in the X config or do we have > to detect what touchpad we are running? > Unfortunately, we'll have to detect it. This whole are of X is being reworked as we speak Upstream, everything is hot plug, and you can then set things on a per detected device basis. - Jim -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wacom Bamboo with XO?
I imagine if we could get it working and if the driver isn't too
large, the OLPC guys would be willing to include the module in 9.1.
Has anyone gotten it compiled and tried the gtk.gdk.Device test yet?
-Wade
On Fri, Nov 21, 2008 at 11:34 PM, Chris Marshall
<[EMAIL PROTECTED]> wrote:
> Wade Brainerd wrote:
>>
>> For someone with a tablet, it would be nice to see the results of a
>> simple PyGTK program which reports X, Y and Pressure from the
>> gtk.gdk.SOURCE_PEN device, using the gtk.gdk.Device API.
>>
>> http://www.pygtk.org/docs/pygtk/class-gdkdevice.html
>>
>> If this works, it would be quite easy to integrate Wacom support into
>> Colors! and other Sugar activities.
>
> Well, I'm going to try to get follow the Wacom
> instructions for installing the tablet drivers.
> I haven't built or installed a linux kernel or
> drivers so we'll see how that learning curve
> goes...then there are the special idiosyncracies
> of the XO. :-)
>
> Once the driver and kernel modules are built for
> the 8.2 os kernel, how would we go about distributing
> the drivers in a usable fashion. Following kernel
> compile and link instructions won't work. We need
> something like a signed update. Is there any way
> to have a signed update by a developer rather than
> the OLPC? Otherwise, is there a way to make the
> tablet driver available for an Activity?
>
> --Chris
>
>> -Wade
>>
>> On Tue, Nov 18, 2008 at 8:26 AM, <[EMAIL PROTECTED]> wrote:
>>>
>>> robert --
>>>
>>> [EMAIL PROTECTED] wrote:
>>> > Paul,
>>> >
>>> > Are you using the driver code from http://linuxwacom.sourceforge.net/
>>> ?
>>>
>>> no -- i just built the driver that's in the kernel tree.
>>>
>>> paul
>>>
>>> > I had intended on trying this but have been too busy to get the time
>>> > set up the correct environment or follow all the steps involved for
>>> > the initial setup
>>> > http://linuxwacom.sourceforge.net/index.php/doc
>>> >
>>> > If you get something you think is workable let me know and I can test
>>> > it with one of my Wacom Intuos 2 tablets.
>>> >
>>> > Note there is also a mouse as well as a pen with this tablet so the
>>> > mouse code needs to be compiled as well.
>>> >
>>> > thanks for all the good work!!
>>> > /Robert
>>> >
>>> > On Nov 17, 2008, at 8:37 AM, [EMAIL PROTECTED] wrote:
>>> >
>>> > > building and insmod'ing wacom.ko lets the Sapphire tablet move
>>> > > the mouse cursor. i confess i've never used a tablet, so i don't
>>> > > know whether the button on the stylus doesn't behave as a mouse
>>> > > button is expected or not. also, the motion i get when moving
>>> > > the stylus on the pad is relative, not absolute. there are no
>>> > > module parameters, so any tuning must be via some other
>>> > > mechanism. i can supply the driver module to anyone who would
>>> > > like to try it.
>>> > >
>>> > > i'm probably not the right guy to pursue this further, but i've
>>> > > added a mention of tablet support to #7326, which is a tracker
>>> > > for requested modules.
>>> > >
>>> > > paul
>>> > >
>>> > > wade wrote:
>>> > >> If you guys can get a driver working and expose the API, I'll add
>>> > >> support to Colors!. It already has support for pressure
>>> sensitivity
>>> > >> (variable brush size and/or opacity) in the painting engine.
>>> > >>
>>> > >> -Wade
>>> > >>
>>> > >> On Mon, Nov 17, 2008 at 8:04 AM, <[EMAIL PROTECTED]> wrote:
>>> > >>> chris wrote:
>>> > Has anyone had any success getting a
>>> > Wacom USB tablet working with the XO?
>>> >
>>> > The new Bamboo series is affordable
>>> > ($79 US), about the same size active
>>> > area as the XO display, and could be
>>> > a substitute for the deprecated/soon
>>> > to be abandoned pressure sensitive
>>> > touchpad on the original XOs.
>>> > >>>
>>> > >>> we have a wacom tablet ("Sapphire", whatever that represents)
>>> > >>> here at 1cc, which we can test. the XO doesn't include the
>>> > >>> wacom.ko module which it seems to want. i can try building the
>>> > >>> module to see if it works. i'll leave it to you to figure out
>>> > >>> whether the same driver support will work for the Bamboo series.
>>> > >>>
>>> > >>> paul
>>> > >>> =-
>>> > >>> paul fox, [EMAIL PROTECTED]
>>> > >>> give one laptop, get one laptop --- http://www.amazon.com/xo
>>> > >>> ___
>>> > >>> Devel mailing list
>>> > >>> Devel@lists.laptop.org
>>> > >>> http://lists.laptop.org/listinfo/devel
>>> > >>>
>>> > >
>>> > > =-
>>> > > paul fox, [EMAIL PROTECTED]
>>> > > give one laptop, get one laptop --- http://www.amazon.com/xo
>>> > > ___
>>> > > Devel mailing list
>>> > > Devel@lists.laptop.org
>>> > > http://lists.laptop.org/listinfo/devel
>>>
>>> =-
>>> paul fox, [EMAIL PROTECTED]
>>> give one laptop, get one laptop --- ht
RE: Touch pads
It does seem to be the case there are some especially bad ones. I am getting the serial numbers and will post them here in a few days. However, to duplicate the situation, all I can suggest is that we have seen this in all our Pacific Islands deployments but the hotter and more humid, the worse the effect. David Leeming OLPC Coordinator, SPC and Technical Advisor, People First Network Honiara, Solomon Islands -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Drake Sent: Wednesday, 26 November 2008 10:39 a.m. To: Ties Stuij Cc: [EMAIL PROTECTED]; David Leeming PFnet; Bryan Berry; OLPC Developer's List Subject: Re: Touch pads On Tue, Nov 25, 2008 at 9:34 PM, Ties Stuij <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 2:40 AM, Richard A. Smith <[EMAIL PROTECTED]> wrote: >> Bryan Berry wrote: >> Here at 1cc we still don't have many units that have chronic symptoms to >> test with. > > Oh really? I've seen trouble with almost any machine I touched around > here in Nepal. Not that it happens every time, but it's so common to > perform the 4-finger salute, that I don't even think about it anymore. It's strange. I was working with XOs at OLPC in Camrbdige for months, never having seen a problem (with 8.1) and wondering what the fuss was about. But per my experience in Ethiopia, this was a really common problem. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
I'm here in Guatemala, and I see it to the point where it is a serious problem. This is an interesting data point, because it is more humid than hot here - average temperature around 21C but average humidity in the 70s or so - http://www.bbc.co.uk/weather/world/city_guides/results.shtml?tt=TT001860 . It seems to have gotten worse over the life of my machine. The machine is usable, but I am sure that if it were this bad in Boston it would be fixed by now. My daughter basically hands the mouse over to me half the time unless my optical mouse is free, and drawing programs are not worth it. I also think that improved keyboard navegability would be really worth it, because even if this is significantly improved, there will probably be thousands of units in the field getting bitten noticeably. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Tue, Nov 25, 2008 at 9:34 PM, Ties Stuij <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 2:40 AM, Richard A. Smith <[EMAIL PROTECTED]> wrote: >> Bryan Berry wrote: >> Here at 1cc we still don't have many units that have chronic symptoms to >> test with. > > Oh really? I've seen trouble with almost any machine I touched around > here in Nepal. Not that it happens every time, but it's so common to > perform the 4-finger salute, that I don't even think about it anymore. It's strange. I was working with XOs at OLPC in Camrbdige for months, never having seen a problem (with 8.1) and wondering what the fuss was about. But per my experience in Ethiopia, this was a really common problem. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: running a motherboard without a keyboard
Guylhem Aznar wrote: > I'm thinking about getting a USB-serial cable to connect to J1 ; > meanwhile, I figured out I could use the gamepad, rotation button and > the 4 game keys, along with blinking the leds, but looks like they are > not working, while the power button is working fine. > > Is it due to the missing keyboard part? Is there a quick way to fix it? The gamepad and gamebuttons are read by the EC and inserted into the keyboard stream as special keys. Offhand I don't know what the kernel does when you boot and nothing responds to the keyboard reset. The physical keyboard is not necessary for the EC to send up keyboard events but if nothing kernel side is servicing the keyboard IRQ then you won't get any data. You can see if interrupts are getting serviced by: echo 1 > /sys/module/i8042/parameters/debug and look at the kern.* debug stream. You can also look at /proc/interrupts and see if the count for IRQ 1 is increasing after you press the buttons. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
Jordan Crouse a écrit : > Bert Freudenberg wrote: >> >> On 25.11.2008, at 17:37, Jordan Crouse wrote: >> >>> Bert Freudenberg wrote: On 25.11.2008, at 11:57, Strider wrote: > Hi, > I have a XO Laptop which is a nice machine machine with a high > res display of 1200x900 pixels. The problem with this is that the > laptop isn't powerful enugh to handle fullscreen applications at > this resolution. If only the display could switch to a lower > resolution things would be much better but it seems that this > laptop only supports a single resolution. > > So I was wondering if it would be possible of simulating lower > res at a low level, that is the xf86-video-geode driver. > I'm not an expert in video drivers but i imagine that there are > functions to request a pixel to be drawn on screen based on > what's in the video ram. > Now let's say that it's not one pixel but two that we put on > screen, and that we draw each lines two times. That would result > in a 600x450 resolution. > If we do the same thing but repating the operations three times , > we would have a 400x300 resolution. > Some emulators have a scale option to do such a thing and manage > it quite well, but if we had such an option in the video driver, > the result would be even faster ! > > So what do you think about this? Is it possible ? The Geode actually can do real upscaling (that is, scale multiple graphics resolutions to the panel resolution), it works fine on other machines and LCDs. But latest word is that this somehow interacts badly with our DCON, so no-one has gotten it to work correctly on the XO yet. >>> >>> Indeed. I think there is a DCON interaction happening, because the >>> mouse gets "corrupted" during upscaling as well - and that implies >>> that the issue is happening after the screen is constructed. The >>> upscaling works fine on a CRT and on a "standard" TFT panel, so that >>> is what leads me back to the DCON. Its also a long shot that the >>> 1200x900 resolution is confusing the scaler, but I doubt it since >>> the aspect ratio is still 4:3. I would love for other people to try >>> the driver (it is in the latest debxo, I think); perhaps you can see >>> the pattern that I can't. >>> There still may be hope, because the video upscaler can take RGB 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be upscaled on-the-fly (and the upscaler does 30 fps easily). But I guess getting this to work would require a very determined X hacker ... >>> >>> The RGB video overlay should just work (TM). So it would take less >>> of a determined X hacker, and more of a determined application >>> hacker to put all the pieces together. >> >> >> Well, I meant that this could be used to actually provide, say, an >> 800x600x16 mode in the driver, without having to hack applications. >> While adapting a single app may be comparatively easy, it's still a >> major hassle to patch each and every app. Having it in the driver >> would make things just work (TM). But that would be a major hack, >> don't you agree? > > So if I understand what you are getting at - you want to set up a > single overlay over the whole screen, and render everything on that? > Thats probably doable - you could set up a shadow framebuffer like we > do for rotation, and hook the damage code into the video overlay. It > might work out well, but it would preclude using the video overlay for > anything else (such as, video). It would probably also preclude > rotation - maybe not. > > But rather then invent fanciful ways to handle this, the efforts would > be better spent figuring out how to fix the current driver. Mitch > reports that the Windows driver works just fine, so clearly the bug is > on our side. > > We need developers to start understanding how the driver works. > Everybody with a professional interest in the X driver has moved on to > other pastures, and OLPC desperately needs community members to pick > up the slack. > > Jordan > Knowing that changing resolution on Windows XP sure brings hope to solve this problem :) I have installed the latest DebXO on a SD Card and xrandr shows several choices where Ubuntu and Fedora showed only the native 1200x900. I tried the other modes but they're all messed up. It's clearly a problem about timings. Here's a photo of what it looks like when I try run run Scummvm in fullscreen mode : http://img155.imageshack.us/img155/5589/img0700qg4.jpg I had a similar "out of sync" problem on my other laptop back when the radeon driver had problems on my display. Windows XP had no problems and I had a tool which allowed me to find the correct timing to add valid ModeLines to xorg.conf. Later versions of Ubuntu corrected this problem and I could switch resolutions without any problems. I hope the same t
Re: Touch pads
Deepak Saxena wrote: > Can we get some of the new touchpad laptops out to locations that > have reported issues due to heat/moisture to see how they respond? > It would good to get some data and fix any issues before we roll these > out en masse. Perhaps. I'll have to check with wad and see if we have some left over. The ones we have do not have a textured surface for the plastic so they are a bit sticky to the finger. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
Ben Wiley Sittler wrote: > > i just tried to simulate this. > > as a test i used an eyedropper to put 0.5ml of tapwater onto the > touchpad. suddenly the entire vertical strip of trackpad containing Foreign material on all non multi-touch pads causes problems. Drops of liquid break every single touch touchpad type I've messed with. Its not something we can fix on a single touch device. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New touchpad still has some jumpyness
During SJ's demo meeting today at 1cc I used my test machine with the new touchpad. The touchpad on my laptop is much deeper inset than I still experienced jumpyness. However, a much different jumpyness than what happens with the alps device. In my case it appears to happen if the tip of my thumb gets up into the active area. (Creepage from using it to click thThe touchpad on my laptop is much deeper inset than e X button) What I saw was the cursor would leap to the edge of the screen which is similar to what happens with the current pad, but unlike the current pad its does not continue to leap around. It a one shot and then returns to normal movement. This happened to me several times. So then I played with my HP laptop which also has a synaptics touchpad and I'm able to duplicate the same behavior. So even with the new touchpad we still may have to have some sort of criteria for discarding packets with large deltas for the movement. By default in mouse mode the values reported by the device are relative. So some sort of edge effect must confuse the controller. I need to enable some logging and see what data the device actually sent. I've also noticed that the acceleration of the new touchpad is much less than the alps device. When you switch from new to old the you can really tell. We should reduce the acceleration of the cursor for the alps device. Its not necessary to be that fast. Is that something we can set defaults for in the X config or do we have to detect what touchpad we are running? -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Nov 25 2008, at 18:13, Richard A. Smith was caught saying: > Touchpad problems are listed in many deployments. Our biggest hurdle to > fixing it having reliable way to duplicate the problem. It seems to > happen lots out in the wild its very hard to reproduce on demand and its > pretty rare here at 1cc. > > The 8.2 kernel has a bunch of stuff to try to help but without solid > test cases its a bit of guess work to see what difference the new > changes have. > > We have a new touchpad that queued up for production. That will hit > sometime next year when the current supply is out. Initial reports are > that its much better than the current model. However see my next, post. > That may not solve it 100% Can we get some of the new touchpad laptops out to locations that have reported issues due to heat/moisture to see how they respond? It would good to get some data and fix any issues before we roll these out en masse. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
Ties Stuij wrote: >> If you do do have laptops that have the problem consistently we might >> want to try and do some sort of swap. > > I wouldn't go there... > Sorry, not to rub it in,.. but.. yea, well a bit actually. This is a > very, VERY big and very known (hardware) bug. And if it's still not > resolved, it needs to be addressed asap. Is what I think... I'm not talking about a large scale swap. I mean exchanging a few machines that have chronic jumpyness. So that the developers have machines that they can test on. Yes its a known bug... but whats not know is the exact cause or how to fix it. Touchpad problems are listed in many deployments. Our biggest hurdle to fixing it having reliable way to duplicate the problem. It seems to happen lots out in the wild its very hard to reproduce on demand and its pretty rare here at 1cc. The 8.2 kernel has a bunch of stuff to try to help but without solid test cases its a bit of guess work to see what difference the new changes have. We have a new touchpad that queued up for production. That will hit sometime next year when the current supply is out. Initial reports are that its much better than the current model. However see my next, post. That may not solve it 100% I still want to fix the issues with the current pad but I'll need outside help. If you can help here's what I need: 1) Serial number ranges for laptops that have have jumpy problems. 2) Laptops that are unlocked and people willing to run kernels with driver changes in areas where the problem is common. 3) As much data as possible on the conditions surrounding the laptop when the jumpyness happens. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sorting out the status of lease serving - and client side
On Tue, Nov 25, 2008 at 8:51 PM, John Gilmore <[EMAIL PROTECTED]> wrote: > And "Permanently activated" (developer key obtained). Actually, I think we also have a "permanently activated with a '0' timestamp in the lease" -- so I missed 2 states. But then that XO stops listening to the school server...so I'll say that once it's in any of those states, I don't care about it anymore ;-) Jokes aside, I think you suggested in a private email that if the XS could also store the devkey in case it's lost. Not sure if the plumbing is ready to handle that case, but I think it's a good idea -- with the caveat that it'll only work if the XS has a chance to know that the XO has gotten a devkey. The devkey may be brokered via other channels. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
not sure whether this is the same bug/limitation, but i have noticed the touchpad goes haywire when my daughter uses it with a bit of food on her fingers (obviously i try to avoid letting this happen, but sometimes it does anyhow...) i just tried to simulate this. as a test i used an eyedropper to put 0.5ml of tapwater onto the touchpad. suddenly the entire vertical strip of trackpad containing the droplet becomes nonresponsive, but the rest of the trackpad works still. when i drag my finger through the droplet to remove it from the trackpad, leving my finger a bit wet and "tacky", the trackpad subsequently feels very jumpy. once i dry off my finger, though, it works fine. i don't have instruments here, but a local weather site says: 59.8 °F / 15.4 °C Haze Humidity: 75% Dew Point: 52 °F / 11 °C On Tue, Nov 25, 2008 at 2:42 PM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 8:11 PM, <[EMAIL PROTECTED]> wrote: >> the problem is that if >> tqwheejkweey can't >> duplicate the problem they can't fix it >> (they can change things, but they have no way of knowing if it fixes the >> problem or not) > > Well, right now I'm in a rather hot and humid location (Buenos Aires, > Argentina), and will be here for 1 month, working. What things can I > do to replicate it? > > Let the machine get very warm? > Get very sweaty hands? > This place is not dusty - not sure what would help this > Are kids hands more likely to trigger it than adult hands? I have a 4 > year-old that can help us. > Does being grounded vs wearing rubber soled shoes make a difference? > > To Richard: > > What logs should I capture? Things to try? > >>> I somehow >>> got the notion that models from the future would be helped with this >>> defect somehow, but apparently that's not the case. > > Well, there *is* a new touchpad model in the works, I'm not sure > exactly when it enters production. > > cheers, > > > > m > -- > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > 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: Sorting out the status of lease serving - and client side
> If I understand things right, the possible interesting states are: > > - Never activated > - Activated recently (so not looking for a renewal) > - Activated looking for a renewal > - Expired lease - passive kill > - Found self in blacklist - active kill > And "Permanently activated" (developer key obtained). John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
I've seen this as an increasing problem on my personal XO, which gets quite a bit of heavy use, as evidenced by the some what polished area of the touchpad, ringed with brownish dirt. >> As we've reported before, it also seems to get worse when the machines >> get dusty, and fat/sweaty fingers don't seem to help either I seems that the build up of dirt on the touchpad areas maybe effecting the capacitance of the touchpad surface. For those unaware, generally, touchpads use capacitance to detect your finger. If you have ever tried to use a touch pad with droplets of water on your fingers hand, you may have seen similar behavior on an otherwise normal touchpad. Perhaps a careful cleaning of the touchpad area with mild soap and drying may help. The extra poor behavior in humid conditions could be due to an increase in the conductivity of the built up grime from water absorption. -Joachim -- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Tue, Nov 25, 2008 at 8:11 PM, <[EMAIL PROTECTED]> wrote: > the problem is that if they can't duplicate the problem they can't fix it > (they can change things, but they have no way of knowing if it fixes the > problem or not) Well, right now I'm in a rather hot and humid location (Buenos Aires, Argentina), and will be here for 1 month, working. What things can I do to replicate it? Let the machine get very warm? Get very sweaty hands? This place is not dusty - not sure what would help this Are kids hands more likely to trigger it than adult hands? I have a 4 year-old that can help us. Does being grounded vs wearing rubber soled shoes make a difference? To Richard: What logs should I capture? Things to try? >> I somehow >> got the notion that models from the future would be helped with this >> defect somehow, but apparently that's not the case. Well, there *is* a new touchpad model in the works, I'm not sure exactly when it enters production. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: Touch pads
On Wed, 26 Nov 2008, David Leeming wrote: > I am afraid that I have to agree, although not to distract from the > brilliance of the rest of itonly to raise the importance of this issue. > In our case one large (relative in our region) country is looking closely at > a big commitment and these things are not helpful. the problem is that if they can't duplicate the problem they can't fix it (they can change things, but they have no way of knowing if it fixes the problem or not) David Lang > David Leeming > OLPC Coordinator, SPC and Technical Advisor, People First Network > Honiara, Solomon Islands > > > -Original Message- > From: Ties Stuij [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 26 November 2008 7:34 a.m. > To: [EMAIL PROTECTED] > Cc: Bryan Berry; David Leeming PFnet; OLPC Developer's List > Subject: Re: Touch pads > > On Wed, Nov 26, 2008 at 2:40 AM, Richard A. Smith <[EMAIL PROTECTED]> > wrote: >> Bryan Berry wrote: >> Here at 1cc we still don't have many units that have chronic symptoms to >> test with. > > Oh really? I've seen trouble with almost any machine I touched around > here in Nepal. Not that it happens every time, but it's so common to > perform the 4-finger salute, that I don't even think about it anymore. > As we've reported before, it also seems to get worse when the machines > get dusty, and fat/sweaty fingers don't seem to help either. I somehow > got the notion that models from the future would be helped with this > defect somehow, but apparently that's not the case. > > And it's really to bad, since it's sort of the primary interface to > the machine, and it's not all that pretty to see children, or anybody, > struggling with it. > >> It will be helpful if people who see the problem a lot can provide a >> sampling of serial numbers for units that seem to be the worst. > > Well, we can at least give you the serial numbers of the machines that > we deployed. A range might help also I guess... > >> If you do do have laptops that have the problem consistently we might >> want to try and do some sort of swap. > > I wouldn't go there... > Sorry, not to rub it in,.. but.. yea, well a bit actually. This is a > very, VERY big and very known (hardware) bug. And if it's still not > resolved, it needs to be addressed asap. Is what I think... > > /Ties > > ___ > 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: Touch pads
Ties, I am afraid that I have to agree, although not to distract from the brilliance of the rest of itonly to raise the importance of this issue. In our case one large (relative in our region) country is looking closely at a big commitment and these things are not helpful. David Leeming OLPC Coordinator, SPC and Technical Advisor, People First Network Honiara, Solomon Islands -Original Message- From: Ties Stuij [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 November 2008 7:34 a.m. To: [EMAIL PROTECTED] Cc: Bryan Berry; David Leeming PFnet; OLPC Developer's List Subject: Re: Touch pads On Wed, Nov 26, 2008 at 2:40 AM, Richard A. Smith <[EMAIL PROTECTED]> wrote: > Bryan Berry wrote: > Here at 1cc we still don't have many units that have chronic symptoms to > test with. Oh really? I've seen trouble with almost any machine I touched around here in Nepal. Not that it happens every time, but it's so common to perform the 4-finger salute, that I don't even think about it anymore. As we've reported before, it also seems to get worse when the machines get dusty, and fat/sweaty fingers don't seem to help either. I somehow got the notion that models from the future would be helped with this defect somehow, but apparently that's not the case. And it's really to bad, since it's sort of the primary interface to the machine, and it's not all that pretty to see children, or anybody, struggling with it. > It will be helpful if people who see the problem a lot can provide a > sampling of serial numbers for units that seem to be the worst. Well, we can at least give you the serial numbers of the machines that we deployed. A range might help also I guess... > If you do do have laptops that have the problem consistently we might > want to try and do some sort of swap. I wouldn't go there... Sorry, not to rub it in,.. but.. yea, well a bit actually. This is a very, VERY big and very known (hardware) bug. And if it's still not resolved, it needs to be addressed asap. Is what I think... /Ties ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Wed, Nov 26, 2008 at 2:40 AM, Richard A. Smith <[EMAIL PROTECTED]> wrote: > Bryan Berry wrote: > Here at 1cc we still don't have many units that have chronic symptoms to > test with. Oh really? I've seen trouble with almost any machine I touched around here in Nepal. Not that it happens every time, but it's so common to perform the 4-finger salute, that I don't even think about it anymore. As we've reported before, it also seems to get worse when the machines get dusty, and fat/sweaty fingers don't seem to help either. I somehow got the notion that models from the future would be helped with this defect somehow, but apparently that's not the case. And it's really to bad, since it's sort of the primary interface to the machine, and it's not all that pretty to see children, or anybody, struggling with it. > It will be helpful if people who see the problem a lot can provide a > sampling of serial numbers for units that seem to be the worst. Well, we can at least give you the serial numbers of the machines that we deployed. A range might help also I guess... > If you do do have laptops that have the problem consistently we might > want to try and do some sort of swap. I wouldn't go there... Sorry, not to rub it in,.. but.. yea, well a bit actually. This is a very, VERY big and very known (hardware) bug. And if it's still not resolved, it needs to be addressed asap. Is what I think... /Ties ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Installing XS on server for School District need some help
2008/11/25 Josh Totoro <[EMAIL PROTECTED]>: > Hello, I am a Tech Specialist for a school district in PA. There are 2 of Welcome to the list! Even if there's a bit of developer chatter, this is the place to be. A couple of initial ideas that might help: - Are you using the XS 0.5 installer? If not... do! I's done and released, but I haven't sent out the release announcement formally. This page has all the rght links: http://wiki.laptop.org/go/XS_Release_Notes - The Dell server you have looks plenty! Two things could be going amiss... - One is that the installer has a preset indicating how it will format the drives, and it defaults to overwriting existing Linux partitions, but preserving existing Windows partitions. So when it offers the "how to partition the drive" dialogue, go in and tell it to nuke Windows. - Second - some hardware raid cards don't have drivers built in into Linux. That can be a bit of a pain -- if that's the case, the installer won't find any disk to list. If you think that that's the problem, the fix is to figure out what the exact model of card it is (if possible drill down to exact chipset), and how to get it going with Fedora 9. If the issue is with the RAID card, it might be a better idea to play with the desktop machines in the meantime. Or plug a simple PCI SCSI card, or even a SATA card in there (you'll need SATA disks...) > We plan to have 1500+ XO's on our schools network in the coming year, what > specs would you recommend for the servers? We were planning to have 1 > server on each campus, and about 1100+ XO's on the West and 400 on the > East. Can 1 server handle 1100+ XO's if it has top of the line specs? Cool - we're starting to use (and tune) the XS in scenarios with many laptops. In fact, this development cycle (from now to new year) is focused on exactly that, so discussion in the last few weeks has been on scalability. Some notes (more detail in recent discussions in the archive): - RAM is the main concern - ejabberd (one of the key services) grows significantly iwth large numbers of _connected_ users. 1MB per user is what we are seeing (we're working on this). That is the main memory hog but there are other services too, so with 4GB RAM you should be ok. - Budget 2GB of disk space per user for backups. - You will _really_ want to use the next release (0.6), planned for early January which will have various fixes for scaling issues. > Would you advise us to set up 2 servers on the West and 1 on the East, and > if so what specs should we have on those machines? One machine should be enough, and setting up and maintaining a 2-machine installation is a tricky thing. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Touch pads
Bryan Berry wrote: >> >> David Leeming >> >> Solomon Islands, South Pacific > > We have consistently had similar problems in Nepal. I think it is a > hardware problem. > The core of the problem has yet to be identified but it certainly has hardware aspects. Here at 1cc we still don't have many units that have chronic symptoms to test with. It will be helpful if people who see the problem a lot can provide a sampling of serial numbers for units that seem to be the worst. If you do do have laptops that have the problem consistently we might want to try and do some sort of swap. Also if you can continue to correlate cool mornings with working and hot humid afternoons with not working that sort of data is useful. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On 25.11.2008, at 20:13, Jordan Crouse wrote: > Thanks to Mitch, I fixed the scaling problem. Based on > conversations on > IRC, I am afraid that you will be very disappointed [...] > > xrandr --output default --mode Why should we be disappointed? That's what we wanted all along, no? Great! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
Thanks to Mitch, I fixed the scaling problem. Based on conversations on IRC, I am afraid that you will be very disappointed, so I am going to try to explain in great detail how this all works. First of all, you are going to need either build a new driver on your own, or convince your favorite maintainer to build one for you. The fix is checked into the xf86-video-geode GIT tree HEAD. Secondly, a bit of background on how this all works. Unlike most modern GPUs, the Geode does not support scaling transforms - in simple terms, we cannot use the hardware to automatically scale a given rectangle on the screen, which is how scaling would normally work in a modern 3D compositor. However, we do have the ability to scale the entire screen at once. Again in simple terms, this means you can scale an effective display of say, 800x600 to 1200x900. But this also means that the entire display needs to be put into a 800x600 mode. This means you need to execute a mode switch, and your underlying display manager and window manager need to be able to grok the switch. If you want to switch back to 1200x900 mode, then again, you'll have to take a mode switch. So, assuming you are still with me, lets discuss how to actually pull this off. The method depends on which X server you are using. To easily tell, type 'xrandr' in a terminal - if you see a single 1200x900 mode, then you are using X 1.4. If you see multiple modes, then you are using X 1.5. ** X 1.4 instructions ** For X 1.4, you need to add the mode that you want scale to 1200x900. For this example, lets use 800x600. Add the mode to the xrandr database: xrandr --newmode 800x600 0 800 0 0 0 600 0 0 0 You don't need to worry about setting accurate timings, since the driver is going to scale the mode to 1200x900 anyway. Next, add the mode to the default output: xrandr --addmode default 800x600 Now, if you type 'xrandr' you will see your new mode in the list. Skip ahead to the X 1.5 instructions. ** X 1.5 instructions ** Type 'xrandr' in a terminal. You will see a list of possible modes. Any mode not equal to 1200x900 will be scaled on the XO. To set a mode, type the following: xrandr --output default --mode The modename can be anything in the list. If you want to add something not in the list, refer to the X 1.4 instructions for how to do that. The screen should immediately scale. To return to "normal" mode, set the 1200x900 mode. That should be enough to get you started. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Write Plug in posts to Blogs (was Re: Greg Smith Weekly Report Week Ending November 14 )
Hi Greg and Zeke, I would be glad to help to see if there are ways to integrate videos in your blog posts, as I'm the developer of olpc.dailymotion.com, where all the videos are ogg, Theora + Vorbis encoded. Thanks. Sebastien On Tue, Nov 25, 2008 at 8:03 PM, Greg Smith <[EMAIL PROTECTED]> wrote: > Hi Zeke, > > That's great! > > I think a lot of people will use it, if we can test it and make it > available to XO users. > > As you may know we debated whether to implement the EduBlog tool > (http://wiki.laptop.org/go/Educational_Blogger_Project) as part of Write > or as a server side implementation. > > I pushed for server side (as opposed to Sugar or Write) because it was > faster to market and I didn't see a good answer for the Teacher <-> > Student interaction requirements without it. Just FYI on the history. > > In short, many people would love to see Blogging directly from Write as > an activity on the XO. > > Have you been able to make your customized Write w/blogging in to a .XO > file? > > If so, post that somewhere (our wiki is OK) and I'll ask people to try > it out ASAP. > > If you need help making a .XO file, let us know and we'll get you > support on that. > > Also, you should synch up with the Write maintainers (Marc and Martin > copied). Write is a derivative of AbiWord. If they can review the code > and they like the idea, this could become part of the official AbiWord. > They are about to release a new AbiWord so it may be too late for this > round but get the details to the lead guys and we can go from there. > > I hope that helps. Let me know if you have any questions or need any > more info, help or collaborators. > > Optionally, I'm interested to hear more about your experience with the > XO or any more info you have on yourself, your skills and your work. > > One Blog per Child! > > 500K kids writing Blogs / 1K developers reading blogs and writing code > with those kids = one turbo charged project :-) > > Thanks, > > Greg S > > *** > > From: meticulo <[EMAIL PROTECTED]> > Subject: Re: Greg Smith Weekly Report Week Ending November 14 > To: devel@lists.laptop.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Hello my name is Zeke Dean, I have been developing a bloging client for > the past couple of months for the olpc based on the write activity. It > is a solid bloging client that supports many different blogs and I > believe it has a decent user interface. I would like to discuss if we > can work together as we are both trying to promote the benefits of > bloging for educational purposes. > ___ > 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: Write Plug in posts to Blogs (was Re: Greg Smith Weekly Report Week Ending November 14 )
Hi Zeke, That's great! I think a lot of people will use it, if we can test it and make it available to XO users. As you may know we debated whether to implement the EduBlog tool (http://wiki.laptop.org/go/Educational_Blogger_Project) as part of Write or as a server side implementation. I pushed for server side (as opposed to Sugar or Write) because it was faster to market and I didn't see a good answer for the Teacher <-> Student interaction requirements without it. Just FYI on the history. In short, many people would love to see Blogging directly from Write as an activity on the XO. Have you been able to make your customized Write w/blogging in to a .XO file? If so, post that somewhere (our wiki is OK) and I'll ask people to try it out ASAP. If you need help making a .XO file, let us know and we'll get you support on that. Also, you should synch up with the Write maintainers (Marc and Martin copied). Write is a derivative of AbiWord. If they can review the code and they like the idea, this could become part of the official AbiWord. They are about to release a new AbiWord so it may be too late for this round but get the details to the lead guys and we can go from there. I hope that helps. Let me know if you have any questions or need any more info, help or collaborators. Optionally, I'm interested to hear more about your experience with the XO or any more info you have on yourself, your skills and your work. One Blog per Child! 500K kids writing Blogs / 1K developers reading blogs and writing code with those kids = one turbo charged project :-) Thanks, Greg S *** From: meticulo <[EMAIL PROTECTED]> Subject: Re: Greg Smith Weekly Report Week Ending November 14 To: devel@lists.laptop.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii Hello my name is Zeke Dean, I have been developing a bloging client for the past couple of months for the olpc based on the write activity. It is a solid bloging client that supports many different blogs and I believe it has a decent user interface. I would like to discuss if we can work together as we are both trying to promote the benefits of bloging for educational purposes. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On 25.11.2008, at 18:37, Jordan Crouse wrote: > Bert Freudenberg wrote: >> On 25.11.2008, at 17:37, Jordan Crouse wrote: >>> Bert Freudenberg wrote: On 25.11.2008, at 11:57, Strider wrote: > Hi, > I have a XO Laptop which is a nice machine machine with a high > res display of 1200x900 pixels. The problem with this is that > the laptop isn't powerful enugh to handle fullscreen > applications at this resolution. If only the display could > switch to a lower resolution things would be much better but it > seems that this laptop only supports a single resolution. > > So I was wondering if it would be possible of simulating lower > res at a low level, that is the xf86-video-geode driver. > I'm not an expert in video drivers but i imagine that there are > functions to request a pixel to be drawn on screen based on > what's in the video ram. > Now let's say that it's not one pixel but two that we put on > screen, and that we draw each lines two times. That would > result in a 600x450 resolution. > If we do the same thing but repating the operations three > times , we would have a 400x300 resolution. > Some emulators have a scale option to do such a thing and manage > it quite well, but if we had such an option in the video > driver, the result would be even faster ! > > So what do you think about this? Is it possible ? The Geode actually can do real upscaling (that is, scale multiple graphics resolutions to the panel resolution), it works fine on other machines and LCDs. But latest word is that this somehow interacts badly with our DCON, so no-one has gotten it to work correctly on the XO yet. >>> >>> Indeed. I think there is a DCON interaction happening, because >>> the mouse gets "corrupted" during upscaling as well - and that >>> implies that the issue is happening after the screen is >>> constructed. The upscaling works fine on a CRT and on a >>> "standard" TFT panel, so that is what leads me back to the DCON. >>> Its also a long shot that the 1200x900 resolution is confusing the >>> scaler, but I doubt it since the aspect ratio is still 4:3. I >>> would love for other people to try the driver (it is in the latest >>> debxo, I think); perhaps you can see the pattern that I can't. >>> There still may be hope, because the video upscaler can take RGB 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be upscaled on-the-fly (and the upscaler does 30 fps easily). But I guess getting this to work would require a very determined X hacker ... >>> >>> The RGB video overlay should just work (TM). So it would take >>> less of a determined X hacker, and more of a determined >>> application hacker to put all the pieces together. >> Well, I meant that this could be used to actually provide, say, an >> 800x600x16 mode in the driver, without having to hack applications. >> While adapting a single app may be comparatively easy, it's still a >> major hassle to patch each and every app. Having it in the driver >> would make things just work (TM). But that would be a major hack, >> don't you agree? > > So if I understand what you are getting at - you want to set up a > single overlay over the whole screen, and render everything on > that? Thats probably doable - you could set up a shadow framebuffer > like we do for rotation, and hook the damage code into the video > overlay. It might work out well, but it would preclude using the > video overlay for anything else (such as, video). It would probably > also preclude rotation - maybe not. > > But rather then invent fanciful ways to handle this, the efforts > would be better spent figuring out how to fix the current driver. > Mitch reports that the Windows driver works just fine, so clearly > the bug is on our side. Ah, that's news to me. Which resolutions does it support? > We need developers to start understanding how the driver works. > Everybody with a professional interest in the X driver has moved on > to other pastures, and OLPC desperately needs community members to > pick up the slack. I thought we had a few X hackers on board. Bernie, you still there? ;) - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
Bert Freudenberg wrote: > > On 25.11.2008, at 17:37, Jordan Crouse wrote: > >> Bert Freudenberg wrote: >>> On 25.11.2008, at 11:57, Strider wrote: Hi, I have a XO Laptop which is a nice machine machine with a high res display of 1200x900 pixels. The problem with this is that the laptop isn't powerful enugh to handle fullscreen applications at this resolution. If only the display could switch to a lower resolution things would be much better but it seems that this laptop only supports a single resolution. So I was wondering if it would be possible of simulating lower res at a low level, that is the xf86-video-geode driver. I'm not an expert in video drivers but i imagine that there are functions to request a pixel to be drawn on screen based on what's in the video ram. Now let's say that it's not one pixel but two that we put on screen, and that we draw each lines two times. That would result in a 600x450 resolution. If we do the same thing but repating the operations three times , we would have a 400x300 resolution. Some emulators have a scale option to do such a thing and manage it quite well, but if we had such an option in the video driver, the result would be even faster ! So what do you think about this? Is it possible ? >>> The Geode actually can do real upscaling (that is, scale multiple >>> graphics resolutions to the panel resolution), it works fine on >>> other machines and LCDs. But latest word is that this somehow >>> interacts badly with our DCON, so no-one has gotten it to work >>> correctly on the XO yet. >> >> Indeed. I think there is a DCON interaction happening, because the >> mouse gets "corrupted" during upscaling as well - and that implies >> that the issue is happening after the screen is constructed. The >> upscaling works fine on a CRT and on a "standard" TFT panel, so that >> is what leads me back to the DCON. Its also a long shot that the >> 1200x900 resolution is confusing the scaler, but I doubt it since the >> aspect ratio is still 4:3. I would love for other people to try the >> driver (it is in the latest debxo, I think); perhaps you can see the >> pattern that I can't. >> >>> There still may be hope, because the video upscaler can take RGB >>> 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be >>> upscaled on-the-fly (and the upscaler does 30 fps easily). But I >>> guess getting this to work would require a very determined X hacker ... >> >> The RGB video overlay should just work (TM). So it would take less of >> a determined X hacker, and more of a determined application hacker to >> put all the pieces together. > > > Well, I meant that this could be used to actually provide, say, an > 800x600x16 mode in the driver, without having to hack applications. > While adapting a single app may be comparatively easy, it's still a > major hassle to patch each and every app. Having it in the driver would > make things just work (TM). But that would be a major hack, don't you > agree? So if I understand what you are getting at - you want to set up a single overlay over the whole screen, and render everything on that? Thats probably doable - you could set up a shadow framebuffer like we do for rotation, and hook the damage code into the video overlay. It might work out well, but it would preclude using the video overlay for anything else (such as, video). It would probably also preclude rotation - maybe not. But rather then invent fanciful ways to handle this, the efforts would be better spent figuring out how to fix the current driver. Mitch reports that the Windows driver works just fine, so clearly the bug is on our side. We need developers to start understanding how the driver works. Everybody with a professional interest in the X driver has moved on to other pastures, and OLPC desperately needs community members to pick up the slack. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Sorting out the status of lease serving - and client side
One of the high priorities for the next release cycles of the XS is to
get lease management sorted out. As much as possible, it must Just
Work in deployments (though the definition of what it means to Just
Work is a bit of a work in progress ;-) ).
As part of that, I need to understand a bit better all the different
modes in which a laptop can be, and how they attempt to get their
leases over wifi -- 802.11a/b/g ('abg' in the notes below) or via
802.11s ('mesh') .
If I understand things right, the possible interesting states are:
- Never activated
- Activated recently (so not looking for a renewal)
- Activated looking for a renewal
- Expired lease - passive kill
- Found self in blacklist - active kill
What I understand those states can do, and implementation notes:
= Never activated =
When booted with the gamepad keys pressed, it will attempt to retrieve
a lease locally over mesh using a simplistic protocol over port 191.
* The XS serves the leases over mesh and abg.
* The XO can request it via mesh (but see #8976 affecting 8.2)
* The XO cannot request it via abg
This is implemented on the XO in the signed initrd so it's not trivial
to hack on.
= Activated =
Will regularly make requests to http://antitheft.laptop.org following
http://wiki.laptop.org/go/Theft_deterrence_protocol to check for
blacklisted status.
* The client will not attempt to reach a local address (so we need to
change this)
* This protocol is currently not supported by XS (needs implementation!)
* Can the local exchange signed with a delegated key?
In the protocol description there's discussion of the OATC only
requesting new keys if/when it's over half the life of the activation
lease. On the other hand, the protocol bundles blacklist checks and
lease renewal together. Blacklist checks doesn't have the same logic
as activation lease lifetime.
If the OATC implements the logic described in the wiki, machines are
deaf to the blacklist for long periods.
= Expired lease - passive kill =
I suspect that the codepath we hit here is the same as the 'never
activated' case.
= Found self in blacklist - active kill =
I suspect that the codepath we hit here is the same as the 'never
activated' case.
- = - = - =
Do I have a reasonable understanding of where the XO situation is? I
am trying to map roughly what the work plan is...
cheers,
martin
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
[EMAIL PROTECTED]
http://lists.laptop.org/listinfo/server-devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On 25.11.2008, at 17:37, Jordan Crouse wrote: > Bert Freudenberg wrote: >> On 25.11.2008, at 11:57, Strider wrote: >>> Hi, >>> I have a XO Laptop which is a nice machine machine with a high >>> res display of 1200x900 pixels. The problem with this is that the >>> laptop isn't powerful enugh to handle fullscreen applications at >>> this resolution. If only the display could switch to a lower >>> resolution things would be much better but it seems that this >>> laptop only supports a single resolution. >>> >>> So I was wondering if it would be possible of simulating lower >>> res at a low level, that is the xf86-video-geode driver. >>> I'm not an expert in video drivers but i imagine that there are >>> functions to request a pixel to be drawn on screen based on >>> what's in the video ram. >>> Now let's say that it's not one pixel but two that we put on >>> screen, and that we draw each lines two times. That would result >>> in a 600x450 resolution. >>> If we do the same thing but repating the operations three times , >>> we would have a 400x300 resolution. >>> Some emulators have a scale option to do such a thing and manage >>> it quite well, but if we had such an option in the video driver, >>> the result would be even faster ! >>> >>> So what do you think about this? Is it possible ? >> The Geode actually can do real upscaling (that is, scale multiple >> graphics resolutions to the panel resolution), it works fine on >> other machines and LCDs. But latest word is that this somehow >> interacts badly with our DCON, so no-one has gotten it to work >> correctly on the XO yet. > > Indeed. I think there is a DCON interaction happening, because the > mouse gets "corrupted" during upscaling as well - and that implies > that the issue is happening after the screen is constructed. The > upscaling works fine on a CRT and on a "standard" TFT panel, so that > is what leads me back to the DCON. Its also a long shot that the > 1200x900 resolution is confusing the scaler, but I doubt it since > the aspect ratio is still 4:3. I would love for other people to try > the driver (it is in the latest debxo, I think); perhaps you can see > the pattern that I can't. > >> There still may be hope, because the video upscaler can take RGB >> 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be >> upscaled on-the-fly (and the upscaler does 30 fps easily). But I >> guess getting this to work would require a very determined X >> hacker ... > > The RGB video overlay should just work (TM). So it would take less > of a determined X hacker, and more of a determined application > hacker to put all the pieces together. Well, I meant that this could be used to actually provide, say, an 800x600x16 mode in the driver, without having to hack applications. While adapting a single app may be comparatively easy, it's still a major hassle to patch each and every app. Having it in the driver would make things just work (TM). But that would be a major hack, don't you agree? An intermediate solution would be hacking Xephyr to do the scaling, and since those legacy apps need to be wrapped anyway that approach might be rather viable. Would be a nice improvement to the X activity. Anyone? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
Bert Freudenberg wrote: > On 25.11.2008, at 11:57, Strider wrote: > >> Hi, >> I have a XO Laptop which is a nice machine machine with a high res >> display of 1200x900 pixels. The problem with this is that the laptop >> isn't powerful enugh to handle fullscreen applications at this >> resolution. If only the display could switch to a lower resolution >> things would be much better but it seems that this laptop only >> supports a single resolution. >> >> So I was wondering if it would be possible of simulating lower res >> at a low level, that is the xf86-video-geode driver. >> I'm not an expert in video drivers but i imagine that there are >> functions to request a pixel to be drawn on screen based on what's >> in the video ram. >> Now let's say that it's not one pixel but two that we put on screen, >> and that we draw each lines two times. That would result in a >> 600x450 resolution. >> If we do the same thing but repating the operations three times , we >> would have a 400x300 resolution. >> Some emulators have a scale option to do such a thing and manage it >> quite well, but if we had such an option in the video driver, the >> result would be even faster ! >> >> So what do you think about this? Is it possible ? > > > The Geode actually can do real upscaling (that is, scale multiple > graphics resolutions to the panel resolution), it works fine on other > machines and LCDs. But latest word is that this somehow interacts > badly with our DCON, so no-one has gotten it to work correctly on the > XO yet. Indeed. I think there is a DCON interaction happening, because the mouse gets "corrupted" during upscaling as well - and that implies that the issue is happening after the screen is constructed. The upscaling works fine on a CRT and on a "standard" TFT panel, so that is what leads me back to the DCON. Its also a long shot that the 1200x900 resolution is confusing the scaler, but I doubt it since the aspect ratio is still 4:3. I would love for other people to try the driver (it is in the latest debxo, I think); perhaps you can see the pattern that I can't. > There still may be hope, because the video upscaler can take RGB 5:6:5 > data, so in theory a lower-res 16 bpp frame buffer could be upscaled > on-the-fly (and the upscaler does 30 fps easily). But I guess getting > this to work would require a very determined X hacker ... The RGB video overlay should just work (TM). So it would take less of a determined X hacker, and more of a determined application hacker to put all the pieces together. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Java & Scratch on XO
i'm forwarding this note from john maloney (scratch maintainer) to devel. this certainly sounds like a mime types issue, but i'm not sure where or how we'd augment the canonical list. paul john wrote: > Hi, Paul, Cynthia, and Claudia. > > I got a question from a professor at U. of Wisconsin about how to work > with Scratch projects downloaded from the Scratch website (see below). > > I verified that the problem is that the .sb file gets renamed to be > something in /tmp ending in .bin. I think this happens when you put > the .sb file in the clipboard. In any case, when you drag the file > icon onto Scratch, that is the file name that is reported. > > So my question is: is there a way to tell the browser the files ending > in .sb are Scratch project files so that it doesn't rename them? Is it > something like registering a MIME type? > > Does anyone else have any suggestions for making it easier to get > downloaded Scratch projects to open in Scratch? > > -- John > > > > - > My understanding of the problem (now that I'm running Scratch 1.3 > everywhere) is that the XO does not properly name the files it > downloads from the scratch site (i.e., they don't have .sb > extensions), and Scratch refuses to recognize files without that > extension. If I use the Linux terminal program to change the name (or > download them onto a USB from another machine) I can get the Scratch > to open the files. Does this make sense? It is a total pain in the > neck though, because I can't figure out a solution that does not > involve a USB: the only way I can find the Scratch program file from > the Linux terminal is if I use the Journal to copy the file to the USB > (I can't figure out where it lives in the Journal world). > - =- paul fox, [EMAIL PROTECTED] give one laptop, get one laptop --- http://www.amazon.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On 25.11.2008, at 11:57, Strider wrote: > Hi, > I have a XO Laptop which is a nice machine machine with a high res > display of 1200x900 pixels. The problem with this is that the laptop > isn't powerful enugh to handle fullscreen applications at this > resolution. If only the display could switch to a lower resolution > things would be much better but it seems that this laptop only > supports a single resolution. > > So I was wondering if it would be possible of simulating lower res > at a low level, that is the xf86-video-geode driver. > I'm not an expert in video drivers but i imagine that there are > functions to request a pixel to be drawn on screen based on what's > in the video ram. > Now let's say that it's not one pixel but two that we put on screen, > and that we draw each lines two times. That would result in a > 600x450 resolution. > If we do the same thing but repating the operations three times , we > would have a 400x300 resolution. > Some emulators have a scale option to do such a thing and manage it > quite well, but if we had such an option in the video driver, the > result would be even faster ! > > So what do you think about this? Is it possible ? The Geode actually can do real upscaling (that is, scale multiple graphics resolutions to the panel resolution), it works fine on other machines and LCDs. But latest word is that this somehow interacts badly with our DCON, so no-one has gotten it to work correctly on the XO yet. There still may be hope, because the video upscaler can take RGB 5:6:5 data, so in theory a lower-res 16 bpp frame buffer could be upscaled on-the-fly (and the upscaler does 30 fps easily). But I guess getting this to work would require a very determined X hacker ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On Tue, Nov 25, 2008 at 12:52 PM, <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 11:57:17AM +0100, Strider wrote: > > The problem with this is that the laptop isn't powerful enugh > > to handle fullscreen applications at this resolution. > > All those I have tried have worked fine at this resolution. Which > particular applications are you referring to? > > I've tried; konqueror, galeon, gpredict, xclock, firefox, emacs, xterm, > inkscape, gimp, abiword, openoffice, wesnoth, and xastir. I'm probably > not using an application you're using. Which is it? Perhaps there is a > design problem in the application. Perhaps the application requires a > display bandwidth that exceeds what is available. > > -- > James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ It is indeed the applications that are in cause. I tried zsnes which is not usable in other resolution than the original 256x224, I also ran the amiga emulator e-uae which does not support upscaling but only resolution changes. Other emulators such as dgen for the Sega Genesis or gnuboy for the game boy have a software scaling option working really well. One solution would be to patch each problematic application to support 1200x900 but it's will not be possible with closed source software. I'd also like to try to run games that ran on 1999's PCs such as Quake 3 and Unreal Tournament, I think the laptop is powerful enough to run these games at a 400x300 resolution but i doubt it will be smooth at 1200x900. I have found this message : http://lists.x.org/archives/xorg-driver-geode/2008-August/000353.html on the x.org mailing list and it might be what i'm talking about, I have to give it a try. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Simulating a lower resolution on the OLPC XO Laptop
On Tue, Nov 25, 2008 at 11:57:17AM +0100, Strider wrote: > The problem with this is that the laptop isn't powerful enugh > to handle fullscreen applications at this resolution. All those I have tried have worked fine at this resolution. Which particular applications are you referring to? I've tried; konqueror, galeon, gpredict, xclock, firefox, emacs, xterm, inkscape, gimp, abiword, openoffice, wesnoth, and xastir. I'm probably not using an application you're using. Which is it? Perhaps there is a design problem in the application. Perhaps the application requires a display bandwidth that exceeds what is available. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Simulating a lower resolution on the OLPC XO Laptop
Hi, I have a XO Laptop which is a nice machine machine with a high res display of 1200x900 pixels. The problem with this is that the laptop isn't powerful enugh to handle fullscreen applications at this resolution. If only the display could switch to a lower resolution things would be much better but it seems that this laptop only supports a single resolution. So I was wondering if it would be possible of simulating lower res at a low level, that is the xf86-video-geode driver. I'm not an expert in video drivers but i imagine that there are functions to request a pixel to be drawn on screen based on what's in the video ram. Now let's say that it's not one pixel but two that we put on screen, and that we draw each lines two times. That would result in a 600x450 resolution. If we do the same thing but repating the operations three times , we would have a 400x300 resolution. Some emulators have a scale option to do such a thing and manage it quite well, but if we had such an option in the video driver, the result would be even faster ! So what do you think about this? Is it possible ? Regards, Mathieu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Packet loss during wireless scans (Testing needed)
Reproduced on 767 with 5.110.22.p18 Also observed packet loss when switching between text virtual consoles using Alt/F1 and Alt/F2 ... but it was difficult to reproduce. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
On Tue, Nov 25, 2008 at 02:42:42PM +0545, Bryan Berry wrote: > One important point, make sure you hit the "Fn" key last when you do the > 4-finger salute. Agreed. http://wiki.laptop.org/go/Four_finger_salute -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch pads
> From: "David Leeming" <[EMAIL PROTECTED]> > Subject: Touch pads > To: <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Some feedback on touch pads. I returned to the PNG trials school of Giare > last week to do some training, and noticed several of the XO-1s (received in > June 08) and running version 8.2 suffering very badly from the touchpad > problem. One boy's laptop was almost unusable. We tried chalk, the 4 finger > salute, rebooting, etc. Despite this, he managed to do the attached with > Paint in the morning when it was cooler. During the afternoon the > temperature must have been 35 deg C and 90% humidity. > > > > Is this problem likely to be solved with software updates? > > > > David Leeming > > Solomon Islands, South Pacific We have consistently had similar problems in Nepal. I think it is a hardware problem. One important point, make sure you hit the "Fn" key last when you do the 4-finger salute. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Packet loss during wireless scans (Testing needed)
On Tue, Nov 25, 2008 at 03:55, John Ferlito <[EMAIL PROTECTED]> wrote: > Hi, > > I've been debugging a packet loss issue with the VideoChat application > for the last few days. After a fair bit of fiddling I discovered the > packet loss is being caused by network scans being performed by > Network Manager. We are seeing 0.4-0.8 second losses of network > connectivity when these occur. > > I've filed a bug here https://dev.laptop.org/ticket/9048 > > The problem is easily reproducible by doing the following > >ping -i 0.1 GATEWAY_IP >iwlist eth0 scan > > You should see two lots of 4 packets drop and the antennae light on > the XO should flash. > > My testing has been on > Build: 767 > Firmware: Q2E18 > Marvel Firmware: 5.110.22.p18 > > Could others with other builds please test to see if this has been > around for a while. Email me privately and I'll summarise in the > ticket. Reproduced with 767. No packet loss with 656. Commented on the ticket. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
