Re: identifying a 1.75
martin wrote: On Tue, Aug 9, 2011 at 6:31 PM, Paul Fox p...@laptop.org wrote: thoughts/comments? better approaches? obvious additions? Hi Paul timely - I was just hacking on olpc-utils, bitfrost and sugar on exactly the same thing (while on the plane, no internet). Something along the lines of what you have is needed, I'll probably merge it into my hacking. And we need it as part of a mini bash function library as well, machine identification and other tasks reading from ofw are spread across olpc-utils at random. So I'll prolly hack olpc-hwinfo into a shell of what you posted (oh! the pun!) -- calling into shared function calls. And will refactor other scripts to match. something else i found this morning, while looking at #11126 -- udev uses dmi/id/product_name to decide to apply our keyboard map. this won't work on 1.75, so i guess we'll need to choose a/the canonical method of distinguishing a 1.75 from sysfs. paul cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
identifying a 1.75
on XO-1 and XO-1.5, we were able to discover the model of the laptop from the information under /sys/class/dmi/id. the DMI schema comes from the PC world, and we can't expect it to exist on ARM. there was also information to be found in /ofw on those machines, like serial number, and uuid. the hex model designator found there was used as a fallback if the dmi tree wasn't there (on older XO-1 firmware). on 1.75, there's no dmi tree, and /ofw has moved to /proc/device-tree, so we need to modify a lot of places that try and dig up platform info. (see #6) so i'm floating the attached script, tentatively named olpc-hwinfo, as a strawman. i think it gives access to the most often needed info, and can obviously be expanded if needed. it would go in olpc-utils, which would put it in /usr/sbin (since some clients live in /usr/sbin). thoughts/comments? better approaches? obvious additions? paul =- paul fox, p...@laptop.org olpc-hwinfo Description: - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying a 1.75
stephen john smoogen wrote: On Tue, Aug 9, 2011 at 16:31, Paul Fox p...@laptop.org wrote: on XO-1 and XO-1.5, we were able to discover the model of the laptop from the information under /sys/class/dmi/id. the DMI schema comes from the PC world, and we can't expect it to exist on ARM. there was also information to be found in /ofw on those machines, like serial number, and uuid. the hex model designator found there was used as a fallback if the dmi tree wasn't there (on older XO-1 firmware). on 1.75, there's no dmi tree, and /ofw has moved to /proc/device-tree, so we need to modify a lot of places that try and dig up platform info. (see #6) so i'm floating the attached script, tentatively named olpc-hwinfo, as a strawman. i think it gives access to the most often needed info, and can obviously be expanded if needed. it would go in olpc-utils, which would put it in /usr/sbin (since some clients live in /usr/sbin). thoughts/comments? better approaches? obvious additions? Check the CPU? Shouldn't /proc/cpuinfo tell you what you have since the major change is cpu? yeah, i thought of that. it's likely the next OLPC product will use the same processor, so we'll need something else in the future anyway. it happens that /proc/cpuinfo even says: Hardware: OLPC XO-1.75 (since ARM kernels provide slightly different info than x86 kernels), which makes it very tempting to use that. but if we're lucky, the next product might share the same kernel (so that string may change). in any case, i think i'd prefer using info that sourced from the hardware or firmware rather than a compiled in string. (but maybe i'm missing something here, and that line in /proc/cpuinfo is exactly what we should be using. anyone?) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying a 1.75
martin wrote: On Tue, Aug 9, 2011 at 6:31 PM, Paul Fox p...@laptop.org wrote: thoughts/comments? better approaches? obvious additions? Hi Paul timely - I was just hacking on olpc-utils, bitfrost and sugar on exactly the same thing (while on the plane, no internet). Something along the lines of what you have is needed, I'll probably merge it into my hacking. And we need it as part of a mini bash function library as well, machine identification and other tasks reading from ofw are spread across olpc-utils at random. So I'll prolly hack olpc-hwinfo into a shell of what you posted (oh! the pun!) -- calling into shared function calls. And will refactor other scripts to match. okay. most clients don't need hw info at high rates, so i figured a self-contained script would be sufficient (and necessary, for some clients). but certainly refactoring into sourceable chunks is a fine idea. (and more to the point, i won't commit anything -- ball's in your court. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: C\C++ SDL
mustafa wrote: a C++, python, C, Java, vala, Scala, (maybe C# too) ide with a couple of tuts for each language bundled with the OLPC XO will be great so kids can learn programming contrary to what some believe, the goal of the XO, and the OLPC project overall, is not to teach kids programming. the goal is to help kids learn _lots_ of things -- programming, and familiarity with computing, is one small part of an education that includes learning to read, to write, to do math, to understand geography, or astronomy, or biology, or..., or..., or... the XO already support 4 (to my knowledge) programming environments as Activities, and as others have said, more languages (C++, java, whatever) are readily installable, if not under sugar. i'd rather see Physics, for instance, become better suited as an instructional tool than support for more computer languages. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: C\C++ SDL
mustafa wrote: Hi well children can learn all those stuff at school but programming must be done on a computer and as technology affects our life more more people must learn programming, searching, word processing, etc. please tell me about those activity IDEs and how to compile with them on OLPC and can a simple child easily get and use them Etoys, TurtleArt, Scratch, and Pippy are the activities i was referring to. i'm sure you can find more information on them on your own. and about physics if more people know how to program OLPC XOs teachers (and maybe physics experts) can help program physics stuff Physics, like most Sugar activities, is written in python. and we can do both things just some people can improve physics things while others increase support for programming languages you seem to feel that increased support for programming education on the XO is extremely important. i heartily recommend that you get involved, and help create what it is you think is needed. BTW I love physics and i think it should be better (it's more important than literature and unimportant stuff like that) i confess, with comment like that i'm starting to suspect you of being a troll. paul To: ahmed_nematal...@hotmail.com Subject: Re: C\C++ SDL From: p...@laptop.org CC: devel@lists.laptop.org Date: Mon, 8 Aug 2011 10:43:56 -0400 mustafa wrote: a C++, python, C, Java, vala, Scala, (maybe C# too) ide with a couple of tuts for each language bundled with the OLPC XO will be great so kids can learn programming contrary to what some believe, the goal of the XO, and the OLPC project overall, is not to teach kids programming. the goal is to help kids learn _lots_ of things -- programming, and familiarity with computing, is one small part of an education that includes learning to read, to write, to do math, to understand geography, or astronomy, or biology, or..., or..., or... the XO already support 4 (to my knowledge) programming environments as Activities, and as others have said, more languages (C++, java, whatever) are readily installable, if not under sugar. i'd rather see Physics, for instance, become better suited as an instructional tool than support for more computer languages. paul =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
(fwd) kernel branch change
sent this to the wrong list... i wrote: Date:Mon, 08 Aug 2011 15:07:50 EDT To: techt...@laptop.org From:Paul Fox p...@laptop.org Subject: kernel branch change to be sure everyone's now on the same page: kernel development for 1.75 has moved from the olpc-3.0 repo to the olpc-kernel repo. the branchname remains the same: arm-3.0 the olpc-3.0 repo has been made inaccessible to prevent further commits. (lennert's last commit (on behalf of james: Trivial fix to olpc-ec-1.75 messages for readability of dmesg) has been cherry-picked to its new home.) i think this makes the move to the olpc-kernel repo complete as far as any current continuing kernel development is concerned. paul =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: C\C++ SDL
; To: ahmed_nematal...@hotmail.com Subject: Re: C\C++ SDL From: p...@laptop.org CC: devel@lists.laptop.org Date: Mon, 8 Aug 2011 10:43:56 -0400 mustafa wrote: a C++, python, C, Java, vala, Scala, (maybe C# too) ide with a couple of tuts for each language bundled with the OLPC XO will be great so kids can learn programming contrary to what some believe, the goal of the XO, and the OLPC project overall, is not to teach kids programming. the goal is to help kids learn _lots_ of things -- programming, and familiarity with computing, is one small part of an education that includes l e arning to read, to write, to do math, to understand geography, or astronomy, or biology, or..., or..., or... the XO already support 4 (to my knowledge) programming environments as Activities, and as others have said, more languages (C++, java, whatever) are readily installable, if not under sugar. i'd rather see Physics, for instance, become better suited as an instructional tool than support for more computer languages. paul =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel git reorganisation
daniel wrote: On Thu, Aug 4, 2011 at 3:08 AM, Paul Fox p...@laptop.org wrote: when you say delete the branch, does this imply no longer being able to look at the history leading to the X or Y tag? No, git log archive/olpc-2.6.30 will still show full history, and git checkout -b olpc-2.6.30 archive/olpc-2.6.30 will locally recreate the branch as before. The only real difference is that you can't commit to branches that have been archived in this manner, unless you recreate the tag pointing at a new tip. thanks. i figured/was hoping it was something like this. go for it. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: powerd-dbus network extension
hi daniel -- daniel wrote: Hi Paul, For 11.3.0 I'd like to implement a solution for the issue where powerd idle-suspends while wifi connections are being established, causing connection failures and other undesirable activity. The solution I'm thinking of isn't ideal in that it adds a mini-daemon alongside powerd. But hey, you just got rid of HAL, we have breathing space ;) and I can't think of a better way. Here is what I've thought up: Instead of being on-demand and short lived, powerd-dbus will be launched by powerd and will become a full-time daemon. In addition to the functionality that it already has, it will connect to the dbus system bus and monitor NetworkManager's StateChanged signals. The NM states are: DEVICE_STATE_UNKNOWN = 0 DEVICE_STATE_UNMANAGED = 1 DEVICE_STATE_UNAVAILABLE = 2 DEVICE_STATE_DISCONNECTED = 3 DEVICE_STATE_PREPARE = 4 DEVICE_STATE_CONFIG = 5 DEVICE_STATE_NEED_AUTH = 6 DEVICE_STATE_IP_CONFIG = 7 DEVICE_STATE_ACTIVATED = 8 DEVICE_STATE_FAILED = 9 Lets assign a variable: nm_suspend_ok = state = 3 state = 8 since that can't be true, i assume you meant: nm_suspend_ok = state = 3 || state = 8 (i.e. suspend is only OK if we aren't establishing a connection) It will also monitor the wpa_supplicant signals for the same device, watching for the Scanning signal. wpas_suspend_ok = !Scanning Finally: suspend_ok = wpas_suspend_ok nm_suspend_ok you're far more familiar with the details of how NM and wpa_supplicant operate, so i'm sure your proposed conditions are likely correct. When the suspend_ok flag changes, it would be communicated to powerd through the powerevents socket, as network_suspend_ok or network_suspend_not_ok. There would be a 2 second settle period after a not-OK to OK transition before sending the powerd event (and the event would be aborted if the situation changes within those 2 seconds). This captures the case where NM says the device is disconnected, and wpa_supplicant has finished a scan (suspend_ok == TRUE), but NM will initiate a connection immediately after (once it has processed the scan results). When powerd has been told network_suspend_not_ok, it would not suspend until told otherwise. (I'll probably ask you to implement this bit, I guess you could do it rather quickly?) sure. as john suggested in another message, this is yet another application-specific protocol being implemented in powerd, as a heuristic to keep the user happy. while i have no problem adding it (what's one more? :-), we should certainly be tracking the ongoing kernel work which might support all our suspend inhibitors in a more cohesive way. The above is the main functionality I want to implement. But, to kill 2 birds in 1 stone, having this full-time daemon around lets me solve another issue: rfkill. You probably recall that sugar-0.84 executed rfkill block olpc when the disable wifi checkbox was ticked. Unfortunately this was never it used to be rfkill block wifi, but perhaps that's changed. upstreamed (boo), so 11.2.0 doesn't have that functionality. In 11.2.0, the NM WirelessEnabled property is manipulated, and the interface is brought down, but we don't actually cut power. We do have the option of reimplementing it in Sugar, but (for now) I think powerd would be a nicer place to do this. (Ultimately, we want NM to do it). So, in addition to the above, powerd-dbus would monitor for NetworkManager's PropertiesChanged signal, and apply this simple logic. if WirelessEnabled == true: rfkill unblock olpc else: rfkill block olpc again, you're closer to the wireless bits than i am. i guess we know that NM won't be confused by having the card logically disappear when it brings the interface down? if so, then it sounds like a reasonable plan. (though it feels like a bit of a hack for it to be in powerd-dbus.) paul How does this sound to you? Thanks, Daniel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Kernel git reorganisation
daniel wrote: Hi, We've recently talked about reorganising our kernel git repo, and avoiding having multiple repos like we have ended up with now. I propose the following (and I volunteer to do it): When I say archive X I mean: create a tag named archive/X pointing at the current tip of branch X, then delete the branch. And archive X as Y means: create a tag named archive/Y pointing at the current tip of branch X, then delete the branch. when you say delete the branch, does this imply no longer being able to look at the history leading to the X or Y tag? i hope not. if it's purely to give the tips more meaningful names, then that, of course, is good. - ask Chris to take a backup - olpc-2.6 is renamed to olpc-kernel - symlink set up so that olpc-2.6 still works - Existing master is tagged as archive/olpc-2.6.27 - master is reset to Linus HEAD as of now - remove origin branch (seems to be entirely contained within olpc-2.6.22) - archive stable as olpc-2.6.22 - archive testing as olpc-2.6.25 - archive xo-1.5 as xo15-2.6.30 - archive xo_1.5-2.6.30 as xo15-2.6.30-2 - archive xo-v2.6.30 as xo1-2.6.30 - archive 2.6.30-rc5 as olpc-2.6.30-rc5 - archive mfgtest - archive olpc-2.6.30 - remove olpc-2.6.31-updates (entirely contained within olpc-2.6.31) - archive olpc-2.6.34-dev - archive zones_of_death This leaves just 2 branches: olpc-2.6.31 and olpc-2.6.35 Then ARM can add arm-3.0 where XO-1.75 11.3.0 kernels will be built from. When ARM does move into the repo (which should be soon, I'd hope), I'd like to request that it goes back to the linear usage of git that we've done for our other branches. I've been trying to keep an eye on the ARM kernel but it's simply too confusing with 2 repos, scratch branches, branches being rewinded/rebased, etc. Obviously theres a lot fully agree here. paul of churn going on, but that's the way it is, even post-production. A year from now it will be difficult to figure out what happened, unless you can go through the commit list. It is already painful doing that for XO-1.5 (look at the mess we made with the 2.6.30 branches above) but everything can still be traced quite easily. What would be nice to have is a branch where releases are built from, which doesn't ever get rewinded. Commits can be reverted, experimental stuff can be committed, but it shouldn't ever rewind or rebase. Things do get a bit messy, but every 2 months we should be looking at rebasing on top of a new Linus release (in a new branch), at which point commits can be merged and cleaned up, and we should be upstreaming heavily at the same time. Those measures will keep things manageable. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
james wrote: On Thu, Jul 21, 2011 at 12:14:14AM -0400, Martin Langhoff wrote: On Wed, Jul 20, 2011 at 6:04 AM, Martin Langhoff mar...@laptop.org wrote: On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff mar...@laptop.org wrote: ?- Updates olpc-utils to disable X zapping and fix serial port terminal Initial testing seems to indicate serial port needs a bit more attention. I've also tested it with a newer kernel containing Paul's tty config fix, and it doesn't make a difference. Looking at it again -- there is no apparent problem with using the serial port, only an early msg in var/log/messages Jul 21 04:07:36 localhost init: ttySx main process (33) terminated with status 1 I looked into this. /etc/init/ttyS.conf says start on startup, but if it is changed to start on runlevel [12345] this strange message goes away. Perhaps it that would probably be okay. when i changed our conf file to start on startup a year or more ago, it was to get the serial port up as soon as possible, because i was tired of not having it while the system booted. (it was being treated as a normal user getty before that, i think.) paul is caused by some interaction with upstart's init, or perhaps we are not following best practices in ttyS.conf. (We have our own ttyS.conf, but curiously /etc/init/serial.conf might have been starting a process, but it says it requires ttyS2 to be the last or primary console in the kernel command line, and for it to be listed in /etc/securetty. Doing those things doesn't cause serial.conf to start a process though.) But nothing seems to be broken - shutdown/reboot works correctly (and the plymouth workaround has been removed) - switch to gnome / sugar works correctly - bash is respawned correctly if you exit My gut feel is that we still have something lurking here, but nothing we ship at the moment tries modem control on /dev/ttyS2. Not even ModemManager, according to strace. (Pity it doesn't ignore USB serial adapters as well.) I looked briefly at the serial/pxa driver. When a user process configures for modem control on /dev/ttyS2 via termios, the upshot is the setting of bit AFE (Auto-flow Control Enable) in the UART MCR (modem control register). Good. During serial_pxa_startup, /dev/ttyS3 is configured for AFE automatically. But I didn't see any obvious way at mmp2_add_uart time to tell the driver not to bother setting UART_MCR_AFE for /dev/ttyS2. The control lines themselves aren't exposed, which is presumably why threads that do I/O hang. But hey, the same thing happens on XO-1.5, just tested ... so we're good to go. ;-) -- James Cameron http://quozl.linux.org.au/ ___ Techteam mailing list techt...@lists.laptop.org http://lists.laptop.org/listinfo/techteam ___ Engineering mailing list engineer...@laptop.org http://lists.laptop.org/listinfo/engineering =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
martin wrote: On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff mar...@laptop.org wrote: - Updates olpc-utils to disable X zapping and fix serial port terminal Initial testing seems to indicate serial port needs a bit more attention. I've also tested it with a newer kernel containing Paul's tty config fix, and it doesn't make a difference. Haven't had time to diagnose yet - what's the X zapping part of this? unfamiliar with the reference. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 release notes ready for review
daniel wrote: Hi, The 11.2.0 release notes are now ready for review by the OLPC team and by any other interested contributors: http://wiki.laptop.org/go/Release_notes/11.2.0 Feedback needed quickly, as the release is imminent. - i'm not sure mentioning Skype is worthwhile, unless we know it works (reasonably). it never has before -- has this changed? http://wiki.laptop.org/go/Release_notes/11.2.0#New_XO-1.5_video_driver - regarding sparse fs-updates: it occurred to me that we could probably improve on the strange look by changing the updater so that every block's color changes. skipped blocks could have their colors changed when skipped, perhaps to a different shade of the same color used for written blocks. http://wiki.laptop.org/go/Release_notes/11.2.0#Faster_installation_for_XO-1.5 paul cheers Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 release notes ready for review
james wrote: On Wed, Jul 20, 2011 at 07:00:24AM -0400, Paul Fox wrote: - regarding sparse fs-updates: it occurred to me that we could probably improve on the strange look by changing the updater so that every block's color changes. skipped blocks could have their colors changed when skipped, perhaps to a different shade of the same color used for written blocks. Yes, that's possible. However, I don't think now is a good time to do it, because the release is so near. I think we've lost the opportunity to fix it. certainly not. i agree. While it is different to how it was before, it still does indicate install progress, just that it jumps forward. We've had the odd I'm not sure if it is working response from our testing community, but after the initial reaction I've heard nothing more. So it is a training issue that can be solved by education. If we release as is, then I don't think we should change it back in a later release. That will just confuse people more. it wouldn't be changing it back. it would be almost just like it is now, except that the blocks that are left gray now would become a different shade of green than the data-filled blocks. it's not a big deal. paul Still, if there is consensus that it should be changed, I'm happy to investigate it. -- James Cameron http://quozl.linux.org.au/ =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: udev rules for wedo
jerry wrote:
Hi all:
Playing around with wedo, I've found that scratch is providing udev
rules for wedo and there are rules installed by olpc-utils. I'm
wondering if the rules provided by scratch should be used in place of or
in conjunction with the olpc provided rules in /etc/udev/rules.d. Here
are the contents of the 2 files for F11.
30-olpc-wedo.rules:
# Lego WeDo
SYSFS{idVendor}==0694, SYSFS{idProduct}==0003, GROUP=dialout,
MODE=0660
45-lego-wedo.rules:
# Lego WeDo
SYSFS{idVendor}==0694, SYSFS{idProduct}==0003, MODE=0666
Looks to me that what is provided by scratch should be part of
olpc-utils.
i believe scratch supplies rules because (at least at the time) it
could be installed on XO distributions that didn't include udev
rules at all.
and since the 'olpc' user is a member of group 'dialout', i think these
rules are equivalent in practice. (except for use by 'other',
and i'm not sure how that would happen on an XO.) both rules
give the olpc user read/write access to the device.
are you seeing a conflict or other problem?
paul
Jerry
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Build 871
mikus wrote: I still cant connect to the candidates on download.laptop.org. Works fine from here. I have tried several times over the past 24 hours and the connection worked ok each time. I've been trying (browser, wget) on Jul 1 and Jul 2 and Jul 3 -- the attempted connection (ping tells me it's to pedal.laptop.org 18.85.2.148 ) ALWAYS times out. you're not a verizon customer, by any chance? a couple of us in the office have been seeing the same symptom -- from verizon's FIOS network (at least), 18.85.2.148 is inaccessible -- completely unrouteable -- whereas dev.laptop.org (18.85.2.147) works just fine. ed mcnierney has a service ticket open with VZ about it. paul mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] 11.2.0 successful XO-1 olpc-update, keyboard woes
s wrote: Also, pressing left and right mouse buttons simultaneously used to paste the primary selection in Terminal, I think because this simulates a middle-click and that's been the middle mouse button behavior in UNIX. Not any more. ah! i wondered about that. i noticed it didn't work, but wasn't sure how long it had been broken. i know of no reason _not_ to enable 3-button emulation, and it's very convenient for users of other system that have three buttons. if it's easy, it would be great to turn that back on. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F13-arm build os17
martin wrote: Hmmm. Upon review, it seems like it's missing CONFIG_OLPC_BATTERY so os18 is on its way. sorry -- i should have updated the defconfig along with my commits. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updates for OLPC English Keyboard mappings table
sridhar wrote: On 27 June 2011 00:11, Sridhar Dhanapalan srid...@laptop.org.au wrote: I have been consulting http://wiki.laptop.org/go/OLPC_English_Keyboard and performing some of my own tests with an external US-style keyboard (Logitech Internet 350) on an XO-1.5 running XO-AU OS 10.1.3-au2. sorry, i missed this the first time around. i'm not sure that the table you're referring to is really pertinent -- external keyboards are treated in a relatively raw manner, when compared to the internal keyboards. this is trickey topic. the problem is that there are many layers of mapping going on (keyboard driver, olpc-kbdshim, X, sugar), and expressing them all in a table describing the keyboard is incomplete. there are many types of keyboard as well (membrane, clickety, external). couple that with newer releases that run sugar (which wants to own neighborhood/ friends/home/activity/frame) as well as gnome (which wants those keys to generate F1...F12), and it's all pretty complicated. So far I have determined that: * F1-F4 changes views (Neighbourhood/Friends/Home/Activity) * F5 switches to the journal * F6 shows the frame on an external keyboard, i think those all work because sugar catches the literal function keys. the table you linked to contains things like XK_ViewMesh -- while sugar might catch that too, it's not why an external keyboard works. (i'm not even sure it's why an internal keyboard works anymore, but it might be. running xev would tell you.) * F11/F12 controls volume (also, volume controls on most keyboards work) * my additional volume keys also work this one is tricky. olpc-kbdshim is involved here for internal keyboards, but not for external. (internal are hard, because the labeling on the membrane and mechanical keyboards are quite different -- see http://wiki.laptop.org/go/OLPC_English_Non-membrane_Keyboard) in any case, sugar must be catching both F11/F12 and the media key values. for both to work from your external keyboard. but note that if you were running gnome, and an application took over F11 (for Full Screen, say), then it would no longer control volume. on an internal keyboard volume control would still be available via fn-F11. you asked later about the brightness keys and an external keyboard: the same comments should apply for F9 and F10, but i guess sugar doesn't handles those anymore? i can never remember where to find this code in sugar anymore -- perhaps someone else can look. (by same, i mean that olpc-kbdshim will do nothing for an external keyboard, and therefore it's all up to sugar.) * right Alt behaves as AltGr don't know about that one, or where the distinction happens. * Windows key acts as Hand/Grab (hold this button and move on the track pad to scroll) olpc-kbdshim does that, and intentionally does it whether the keyboard is internal or external. It looks to me that the function/modifier keys for frame, volume and grab are not mapped in the table on that wiki page. I didn't want to edit it unless I was sure about it. Can someone knowledgeable please confirm and/or update the page? again, that's a table describing the internal membrane keyboard -- one that i'm not even sure is still accurate. i don't think it should contain information for external keyboards. perhaps a new page is needed. paul Also, is there a way to change the screen brightness via an external keyboard? Thanks, Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1.75 support in olpc-utils
martin wrote: On Mon, Jun 27, 2011 at 11:37 AM, Richard A. Smith rich...@laptop.org wrote: How are you determining in olpc-utils that you are running on a 1.75? Is this available for runin to pickup? +# FIXME XO-1.75 fallback support until we get ofw data +# exposed via device tree +elif [ `uname -m` == 'armv7l' ]; then +XO_VERSION=1.75 note that i've also added detection code in runin-battery -- if /sys/power/ec doesn't exist, it tries for the new debugfs node. so that module already knows what platform it's on. paul Right now the battery test seems to skate by. We have a minimum SOC diff of 20 clicks and the battery discharge test is coming in at 24 clicks. From the sample set I have so far the runin power draw seems to be very consistent and a margin of 4 may be enough but its pretty close. I may need to adjust the test levels if a 1.75 is detected. Sounds reasonable. James has been looking after runin so CC'd. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Screen dimming XO1 vs XO 1.5
daniel wrote: On 26 June 2011 15:22, Kevin Gordon kgordon...@gmail.com wrote: Sorry, soon I will learn to use terminology correctly. In this case, by dim I meant instant off. :-) Yep, this is a known issue - but one that we treat only with low priority. Auto screen poweroff on inactivity has been implemented on XO-1 but not on XO-1.5. given you referred to #9710, i'm assuming you think kevin is seeing DPMS. did we reenable DPMS on XO-1? i hadn't realized that. i've recommended keeping it off for some time, because it fights with powerd, but maybe you've fixed that. The XO-1 implementation is a bit questionable, that's why it is not a trivial task to include it for XO-1.5. equivalent functionality would be trivial, with a new checkbox to reconfigure powerd to allow dimming/blanking the screen but prevent sleeping. this would work on both platforms. paul In future this may get easier, when we get our OLPC-specific display controller driver into the kernel, and when we eventually move our graphics driver into the kernel (KMS). So, I wouldn't worry about digging into this. Here is a relevant ticket you could track: http://dev.laptop.org/ticket/9710 Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: More 'human' voice synth (TTS)
sridhar wrote: I'm wondering if there's anything we can do to make TTS sound more 'human'. We'd like to be able to use the XOs to teach English literacy, but the espeak voices are very robotic. My understanding is that espeak is optimised for low-power devices (great for XOs) and clear (if robotic) speech. Would it be feasible to switch to something else, like festival? i've run festival as part of my home automation system for many many years, including the last 3 or so on an XO-1 (debxo) which acts as my current HA server. the first secret is to run it in client/server mode, to avoid the server startup latency on every enunciation. but even after that, i think the latency will be too high for your application. i just tested it: given a moderate english sentence, it took 3 seconds to produce output. (i hide this on my system by caching utterances -- that's more feasible in a menuing system than when teaching literacy.) http://dev.laptop.org/~pgf/junk/festival_out.wav (5 seconds on XO-1) flite is a lower cost version of festival that might be appropriate. it seems to reduce the conversion time to about half a second. but the quality suffers as well. http://dev.laptop.org/~pgf/junk/flite_out.wav (.5 seconds on XO-1) fyi, current festival server process footprint: root 999 0.0 9.4 26668 20004 ?Ss Jun06 10:03 /usr/bin/festival --server /usr/local/etc/nosil.scm i haven't used espeak -- i suspect there are API interfaces that are far richer than what i'm doing from the shell commandline. i don't know how one might access festival at that level. paul This is some food for thought: http://braille.uwo.ca/pipermail/speakup/2008-July/046755.html Sridhar Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
yioryos wrote: Date: Tue, 14 Jun 2011 09:45:08 +1000 From: James Cameron qu...@laptop.org Subject: Re: XO-1 touchpad once more Well, we certainly seem to have reduced the frequency of the problem overall, even if a few people who never had the problem now have it. ;-) It's the overall frequency that matters. I do not know why you say we certainly seem to have reduced the frequency of the problem overall but here is some numbers to compare. james' statement surprised me a bit, too, since i'm not sure that we have data to back that up. but regardless... I'm not using my XO-1s as much lately, since the XO-1.5 is much more pleasant to use :-) but still managed to gather touchpad events through several hours of use from my 2 XO-1s. One is running os860 while the other different OLPC 11.2.0 development builds. Both are also running Puppy linux from an SDcard. The data record re-calibration events and in most cases CPU load and memory use, in 5 or 7 minutes intervals. When running puppylinux there are also some logs where the touchpad is powered cycled in 5 or 7 minutes intervals during a sudo anti-RSI step that appears to improve touchpad behavior [1]. Unfortunately the data are not processed in any meaningful way but the frequency and the extend of the events is evident. Maybe it i guess i don't see it. just skimming your logs, i'm not having trends jump out at me. but as you say, that's not really fair without having the data plotted in some meaningful way. perhaps someone listening with good data visualization skills could help us out here? paul could be compared with F7/F9 data if available. [1] http://www.murga-linux.com/puppy/viewtopic.php?p=513017#513017 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
smith wrote: On 05/24/2011 11:37 PM, Paul Fox wrote: certainly not as serious as with XO-1.5: http://dev.laptop.org/ticket/10402#comment:5 what's not clear is a) whether this condition can be caused by lid-switch, and b) whether it can be caused in your charging racks. from my experience with those racks, i suspect the effects won't be as severe as with vertical stacking. Its the other way around. The original problem was reported by people using the racks. We just theorized that people who stack them would also have a similar problem. yes. but quozl's test of xo-1 laptops, as reported in the above comment link, showed screen damage when vertically stacked. he didn't test in a rack. i was suggesting that the temperatures might not rise as high in the charging racks, which is sridhar's use case. paul -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
sridhar wrote: On 24 May 2011 14:42, Paul Fox p...@laptop.org wrote: hi sridhar -- i'll take a stab at more detailed answers to all of these questions tomorrow.. powerd was developed initially on machines that had ohmd installed (i think the rpm still tries to uninstall ohmd first) so it's probably not far from working. but it's entirely possible (likely) that some support for older kernels has been lost along the way, or, more correctly, that newer powerd features depend on fixes/features in newer kernels. obviously a system upgrade would be preferable... but i'm sure you feel the same way. :-) Thanks Paul. Obviously a full OS upgrade is the ideal solution, but we've been having a hard time over the past few months getting people on the ground to do this. There is still a danger of these XOs overheating, so we are looking to develop a solution that is as painless and quick to deploy as possible. i think james cameron has better data, since he did the testing, but i seem to recall that XO-1 doesn't overheat to the same extent that you discovered with 1.5. (unless you have more evidence in that regard.) if we were convinced that was true (and i'm only surmising right now), then those old builds are less of a worry. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
sridhar wrote: We're still grappling with the aftermath of http://dev.laptop.org/ticket/10402 XO-1.5s that have been damaged from overheating are being replaced, but we also need a means to prevent others from meeting a similar fate. Our preferred solution is to upgrade to our latest build, which has a fixed powerd. However, we are finding that many teachers are unable to do this (due to lack of time, etc.). For them, we are devising a simple means for them to specifically update powerd on their systems. This method employs a modified customisation stick[0][1] to automatically install the RPMs. A challenge is that the XOs came from the factory (starting in May 2010) with a range of builds ranging from os65 to os203. The earlier builds have power management handled by ohm[2] instead of powerd. This raises some questions: 1. are there any problems with simply removing ohm and installing powerd? very old versions of powerd will certainly work fine, and more recent ones may too. for the most part powerd checks for the existence of features (e.g., nodes in /sys) before using them. however, some of those features (e.g., the lid-state node) are part of the solution to this unwanted wake-on-lid issue you're having. 2. at what point did powerd become usable in F11 XO builds? i'm not sure what you're asking here. powerd was usable on F11 long before it was able to suppress wake-on-open behavior. powerd-29 fixed that in 10.1.3 (#10403)) for 1.5 laptops, but XO-1 required kernel support. XO-1 started doing the right thing with powerd-30 (#10424), but that required kernel fixes for lid state detection and wakeups (ad366d03315d1bd461db24f68a7506fff5f48a1e and 1edf204d38125e46ae9e45c641f9b7877eec2a5c) 3. are there any other changes that we need to be aware of, e.g. in the power management panel in My Settings in Sugar? yes -- i think releases built with ohmd won't have the sugar control panel smarts to control powerd's behavior. 4. do we need to upgrade the firmware as well? i really don't recall. sorry. 5. is there anything else that we need to be aware of? as you've gathered, there are a lot of pieces that make all this work: the UI, powerd, the kernel, the firmware. if you could upgrade all of the last three, you might be fine, but of course then other interactions between your user-level and the kernel might get upset. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
james wrote: Does ohm wake on lid open? It's been so long ... yes. i think it can't help it, as there's no way to suppress lid-open wakeups on older kernels. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
sridhar wrote: On 25 May 2011 12:45, Sridhar Dhanapalan srid...@laptop.org.au wrote: On 24 May 2011 23:42, Paul Fox p...@laptop.org wrote: i think james cameron has better data, since he did the testing, but i seem to recall that XO-1 doesn't overheat to the same extent that you discovered with 1.5. (unless you have more evidence in that regard.) if we were convinced that was true (and i'm only surmising right now), then those old builds are less of a worry. Does the wake-on-lid-open behaviour exist in older XO-1 builds? We haven't upgraded any XO-1s in quite some time. Answering my own question, it seems like wake-on-open was standard behaviour in all builds prior to #10424. right. Fortunately, we haven't heard of any problems with XO-1s. certainly not as serious as with XO-1.5: http://dev.laptop.org/ticket/10402#comment:5 what's not clear is a) whether this condition can be caused by lid-switch, and b) whether it can be caused in your charging racks. from my experience with those racks, i suspect the effects won't be as severe as with vertical stacking. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing powerd on earlier F11 builds
hi sridhar -- i'll take a stab at more detailed answers to all of these questions tomorrow.. powerd was developed initially on machines that had ohmd installed (i think the rpm still tries to uninstall ohmd first) so it's probably not far from working. but it's entirely possible (likely) that some support for older kernels has been lost along the way, or, more correctly, that newer powerd features depend on fixes/features in newer kernels. obviously a system upgrade would be preferable... but i'm sure you feel the same way. :-) paul sridhar wrote: We're still grappling with the aftermath of http://dev.laptop.org/ticket/10402 XO-1.5s that have been damaged from overheating are being replaced, but we also need a means to prevent others from meeting a similar fate. Our preferred solution is to upgrade to our latest build, which has a fixed powerd. However, we are finding that many teachers are unable to do this (due to lack of time, etc.). For them, we are devising a simple means for them to specifically update powerd on their systems. This method employs a modified customisation stick[0][1] to automatically install the RPMs. A challenge is that the XOs came from the factory (starting in May 2010) with a range of builds ranging from os65 to os203. The earlier builds have power management handled by ohm[2] instead of powerd. This raises some questions: 1. are there any problems with simply removing ohm and installing powerd? 2. at what point did powerd become usable in F11 XO builds? 3. are there any other changes that we need to be aware of, e.g. in the power management panel in My Settings in Sugar? 4. do we need to upgrade the firmware as well? 5. is there anything else that we need to be aware of? Thanks, Sridhar [0] http://lists.laptop.org/pipermail/devel/2011-May/031901.html [1] http://dev.laptop.org.au/issues/593 [2] http://wiki.laptop.org/go/OHM_power_management Sridhar Dhanapalan Technical Manager One Laptop per Child Australia M: +61 425 239 701 E: srid...@laptop.org.au A: G.P.O. Box 731 Sydney, NSW 2001 W: www.laptop.org.au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.2.0 development build 19 released
simon wrote: On 05/20/2011 10:15 AM, James Cameron wrote: On Fri, May 20, 2011 at 09:38:12AM +0200, Simon Schampijer wrote: On 05/20/2011 12:29 AM, James Cameron wrote: On Thu, May 19, 2011 at 06:54:54PM +0200, Simon Schampijer wrote: Hmm, the representation of the missing blocks and the 'Warning' at the end that not all blocks have been written put me off. It looked to me as if there was an error. Maybe we can represent that better? No, just put it in the release notes. I presume you used an old firmware version to do the fs-update. Exactly which version did you use? This is important to know. For those updating from the latest stable 10.1.3 which has Q3A62, we expect no warning. For those updating using a firmware version after Q3A62, and before Q3A65 or Q3B04, a warning may appear. I did update from dx2. I guess one can live with the missing blocks if the warning is not displayed at the end. Do you know what firmware you used to do the fs-update? This is displayed just before the ok prompt. It may have changed since, of course. Now is Q3B03, but afaik it got updated. I could not find out easily which firmware version dx 2 from Paraguay had. fyi -- q3b03 contained a fairly serious regression, which can cause command timeouts when linux tries to talk to the EC. it's fixed in q3b04. (d.l.o. #10881) paul Regards, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Prelink
james wrote: On Wed, May 18, 2011 at 07:45:49AM -0400, Kevin Gordon wrote: Might be over my head in the specific prelink OLPC talk here, but in my experience on the iSeries - anything that optimizes a software update process (which happens twice a year) at the expense of a program loads or the object instantiation process (which happen thousands of times an hour) is a bad trade-off. +1 but unless i misunderstood dsd, prelink is making our update process non-functional. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Prelink
james wrote: On Wed, May 18, 2011 at 08:13:18AM -0400, Paul Fox wrote: but unless i misunderstood dsd, prelink is making our update process non-functional. I thought it only made the process slower than it should be, since moving from one build to another will cause, for each binary affected by prelink, a laptop to server transmission of the file segment hashes, and a server to laptop transmission of the changed block. i was referring to this comment of daniel's: This is one of the reasons that olpc-update doesn't work (runs out of disk space) between two similar versions of 11.2.0 for XO-1: it has to duplicate almost all binaries and libraries on the system, even those that have not otherwise changed. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mountain Dew on XO-1 video?
martin wrote: Does anyone remember the video starring Seth, an XO-1 and some Mountain Dew? Is there a link to it anywhere? Google doesn't seem to know about it :-/ http://www.youtube.com/watch?v=LznVHSbL91I =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bash scripts
kevin wrote: Sascha: Continued to play with this. Went into nautilus on an ext2 formatted card, and there is a checkbox in the panel for allowing execution of files. The owner and other permission boxes didn't seem to do anything; but, clicking that on *did* work. Also, you were correct about it needing to not be FAT, checking that box, even though it sill displays, didn't 'stick' for FAT. Thanks. i've lost track of where exactly this issue sits, but if it's a regression, i suggest opening a ticket. then it can be resolved in a documented fashion (whether fixed as bug or wontfixed as a feature). paul Cheers, KG On Monday, April 18, 2011, Kevin Gordon kgordon...@gmail.com wrote: Sascha: The file system actually had no bearing on the issue I was having, whether ext2, ext3, or FAT32, the symptoms were identical - recent versions of udisks now does not allow 'direct' execution of scripts from auto-mounted removable media. Also, there is some debate as to whether putting a journalling fs onto an SD or USB drive is wise, as it might half its life by in essence doubling the number of writes. In general, I tend to stick with the factory default unless I need multiple partitions, symbolic link, or specific linux-swap support, since I presume the manufacturer has formatted it with the right number of blocks, units, etc to best match their controller/memory config. If I need those, I will still use ext2. Call me optimistic :-) Cheers, KG On Mon, Apr 18, 2011 at 4:13 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Kevin Gordon's message of Mon Apr 18 00:36:26 +0200 2011: But, since my main use of this technique is to semi-automate the process of installing a slew of custom activities and rpm's upon initial build and deployment, having to manually change every machine manually to basically avoid 5 keystrokes, was sort of counter-productive :-) If you're only using this USB stick with Linux machines, why don't you just format it using a file system with POSIX semantics, i.e. ext3? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
ismael wrote: Hello everyone, I'm trying to perform some tests on XO battery life performance and I have some questions which I couldn't find a clear answer in the wiki or this list: i'm sure richard will chime in, but here's a start. - When the battery level is critically low the OS (Sugar 0.88 based Dextrose) performs a safe shutdown. I would like to know what is the exact condition that triggers this. the answer to this depends on what version of powerd is running. in the latest powerd versions, we force a shutdown if the capacity is 1% (or less :-), or if the battery voltage is 5.7V or less. we don't bother with these checks unless the capacity is below 40% (which may be a pointless optimization). these checks were slightly different in powerd versions 27 and earlier, but i suspect dextrose is running something newer than that. - Likewise, at some level controlled by the XO EC, the battery led light begins to flash orange/red. I would also like to know which is the exact condition that triggers this. Is it the SOC, battery voltage, ACR... ? And i believe this value is 5.7V. (i.e., battery voltage) what level triggers this condition? I would also like to know the level in which the XO performs a hard poweroff. 5.5V on XO-1.5, 5.4V on XO-1. also remember that the voltage at the battery will change, substantially, between the suspended and running states -- so what the EC sees during suspend may be several tenths of a volt higher during suspend than when the system is running. paul Any help is appreciated. Thanks! Regards, Ismael -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO power management
ismael wrote: OK. Great. Is the attached version newer than the one in Sugar 0.88?? almost certainly. paul Because the latest dextrose image is mainly based on Sugar 0.88 2011/3/24 Richard A. Smith rich...@laptop.org On 03/24/2011 10:41 AM, Ismael Schinca wrote: I'm planning to use different XO's, all of them 1.0 hardware. I definately won't be able to finish today because they all have different OS images and I think it would be best if I update them all (even for future tests). Maybe tomorrow, maybe monday. Yes certainly please use the same image on all of them. If you have to install software then please use the latest version of olpc-pwr-log. I have it attached to this mail. I think it will be very hard to perform the same test under the same conditions as you suggest because: - It will be very time consuming (though it doesn't need a lot of attention during the test) My goal is to automate the test and use a very short test window. ie 20 minutes or so. - The air conditioning in our building is quite frankly chaotic so temperature is really variable (which is actually a lot worse for us humans than batteries ;) ) Yes. Sorry my use of the word exactly was probably too strong. I don't mean that it has to be 25 degC ambient and only that temperature. The temp fluctuations in a air conditioned office should be within reason. I just don't want the profiles generated in an office and then the test run in a outside warehouse at 33C. Or the curves generated on a XO-1 with build 8.2 but the test run on a 1.5 with build 10.1.3. That sort of thing. The closer I might get, which I think could be pretty close is: - Install the SAME fresh OS image and firmware version on all the test XOs - Disable power management in every XO. and dpms. xset -dpms from the sugar terminal other wise the screen will turn off in 20 minutes and change the power draw. - The laptops batteries are mostly charged, so it will be a charge after discharge, so I think temperature there is less of a concern - Run the tests at the same time in every XO Yes. I believe that will work fine. Note: I'm getting on a plane in a few minutes so this will be my last e-mail until much later on today. Possible tonight or tomorrow. -- Richard A. Smith rich...@laptop.org One Laptop per Child -- Ismael Schinca Centro Ceibal - Depto. Técnico - I+D Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601 57 73 Int. 2232 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Discovering the XOs local timezone in a bash script
sascha wrote: Excerpts from C. Scott Ananian's message of Sun Mar 13 04:06:56 +0100 2011: Last I knew we used standard Linux conventions for timezones and sugar called the standard Linux commands (via sudo) to set the timezone. Can you point me at that old code, please? (we currently use gconf [1], so Sugar is decoupled from the rest of the system w.r.t. time zone). do you know why this is/was done? is it simply a matter of not wanting the sugar user to do root-like things? paul p.s. either my mailer did something very odd, or your message had a surprising set of addressees. intentional? cc: c.sc...@flatty.sascha.silbe.org, Ananian csc...@laptop.org, a.sm...@flatty.sascha.silbe.org, OLPC Devel devel@lists.laptop.org, rich...@flatty.sascha.silbe.org, rich...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Memory replacement
kevin wrote: Mikus and James and the gang: OK, the little 8GiB microSD card inserted into an SD adapter, inserted into the external SD slot, passed the dir test that James said to perform at OFW. Didnt complain. However, it is a Class 2 Sandisk card, so it might not really be the right way to go. Before I do the surgery, armed with silver heat sink paste, and being very careful about pressure on the m/b, no paste is used when the laptops are manufactured, and none should really be necessary afterward. it's true that later head spreaders were modified (with an extra attachment point) to ensure proper contact with the cpu, but you can help ensure the same thing by gently bending each of the flat feet that holds a screw slightly downward. (not the ones that _don't_ hold a screw -- leave those flat.) bending the mounting tabs down will cause the center of the heat spreader to bow towards the motherboard when the screws flatten out the feet. there's a picture here: http://lists.laptop.org/pipermail/devel/attachments/20091103/4e777bb2/attachment-0001.pdf (it's an attachment to this devel message: http://lists.laptop.org/pipermail/devel/2009-November/026110.html ) and having my anti-static wrist guard properly attached - advice please: go, no-go, spend the extra pennies and get a Class 4/6/8/10. All I know for sure is the 2GiB card in there has to be replaced. There are progressively if you're using the machine a lot, and you have the pennies, the difference a faster card makes will be noticeable. paul more and red squares appearing on every refresh, and since this is a 'contributors machine' that I screw up regularly testing a billion USB contraptions, I reload almost every day that I use it :-) Thanks gents. and ladies, i'm sure. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.1 differences
sridhar wrote: A year ago, we deployed about 200 XO-1.1 machines in a community. I'm not sure if that version number is official, but it's what we call XO-1s with XO-1.5 style capacitive trackpads. i'm afraid we just know them as CL1 (old trackpad) and CL1A (new trackpad) machines (because that's what the manufacturer calls them when they're built). there's no casual designator of the sort you've coined. (for the record, the XO-1.5 is CL1B, and the XO-1.5 HS model with the clickety keyboard is CL1C.) I am going to that community in a couple of weeks to upgrade them to the latest OS build. I only have the standard XO-1s available to me for testing. Is there anything peculiar that I need to know about the XO-1.1s that will affect development and testing? i don't believe so, but it would be foolish of me to not suggest that you should really test on the machine you'll be deploying on. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pending xkeyboard-config OLPC patches
martin wrote: In our F11 we shipped a heavily patched rpm for xkeyboard-config. Unfortunately, the rpm was not tagged 'olpc' so we didn't spot it as a custom rpm, and the git repo we worked with is hard to figure out patches vs upstream changes. I've spent some time separating - Our F9 patches (some got dropped) - F11 SRPM: separating our patches from Fedora's, reapplying dropped patches With this in hand, I've prepared a git repo of upstream xkeyboard-config with 3 interesting branches. - v1.5-olpc - these are the patches from the keyboard-data repo, plus the patches we dropped from F9. Paul, could you give this a quick check? i'll cut to the chase and say that i'm completely confused by what's happened, or not happened, and by what you've done to make it better. in other words, it's probably all fine. ;-) i'm not sure what a quick check means in this case. i'm sure the rebasing process was as accurate as any diffing or eyeballing i can do now, and from experience, the only reliable way to find bugs in the keyboard maps is to try every key on every keyboard. i no longer have the machines necessary to do that testing. what i don't understand from your messages so far re: keyboards is, what exactly is wrong? which keys, on which keyboards, for which languages, don't work? - v1.9-rebase - rebase of our patchseries for v1.9 (which we ship for F14) - post-2.1-rebase - rebase of our patchseries on today's master all at http://dev.laptop.org/git/users/martin/xkeyboard-config when i try and clone this repo, it seems to work fine until the very end, then says: warning: remote HEAD refers to nonexistent ref, unable to checkout. and i get no content. the web view, of course, is working fine. paul My intention is to - talk with upstream (Hi Sergey!) about the patches in post-2.1-rebase - prep patched rpms for F11 and F14, tracking both in fedpkg-style http://dev.laptop.org/git/packages/xkeyboard-config/ - these rpms will be tagged olpc m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pending xkeyboard-config OLPC patches
martin wrote: On Thu, Feb 24, 2011 at 1:36 PM, Paul Fox p...@laptop.org wrote: i'll cut to the chase and say that i'm completely confused by what's happened, or not happened, and by what you've done to make it better. in other words, it's probably all fine. ;-) Ok. So for the F11 series, you and Sayamindu worked on the 'keyboard-data' repo. It had some issues... - It has an initial import that wasn't upstream's pristine 1.5 -- it was 1.5 plus several patches (the patches Fedora rpms were applying at that exact time, plus some of ours... but not all). So I studied the delta between pristine and our import to trace all changes. thanks. that clarifies. It paid off -- there was a one line change that wasn't in any patch, and I think it'd have bitten us. - That repo also has dropped some patches that were present (and of value) the F9 rpm. Notably the 'olpc2 for es' patch that is discussed @ http://dev.laptop.org/ticket/9126 . Same with the patch for http://dev.laptop.org/ticket/5060 . I don't know if this was intentional. I've re-merged the #9126 patch. I strongly suspect that #5060 is addressed in a different way now. Were these patches removed for a good reason? Perhaps you can remember... no, sorry, i don't remember -- i suspect it was an oversight. i started from the tree sayamindu pointed me to, and didn't spend a lot of time on anything but the mechanical key layouts. (it was a bit of a rush: the h/w layout of the mech keys was very carefully done to avoid any need for software remapping of the US keyboard, but at the time we'd sort of overlooked the mapping work needed for the spanish version. and since the principle customer for those keyboards was spanish... :-) paul what i don't understand from your messages so far re: keyboards is, what exactly is wrong? which keys, on which keyboards, for which languages, don't work? So we discovered that olpc-utils has a code block for #9126, which triggers, but there is no es / olpc2 definition. all at http://dev.laptop.org/git/users/martin/xkeyboard-config when i try and clone this repo, it seems to work fine until the very end, then says: Sorry - fixed now. thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [ANNOUNCE] XOpup-2.0
yioryos wrote: XOpup-2.0, puppy linux for the XO-1 and XO-1.5 is released At 92MB has the puppy linux feel, an Ubuntu 10.04 LTS core and utilizes all the XO features. i played with this image while debugging a kbdshim issue that yioryos spotted, and i really must recommend it -- when he says above, puppy linux for the XO-1 and XO-1.5, what he means is a single image which boots on either laptop, which is slick, and we should perhaps be thinking along those lines going forward. and i'll at least be keeping a copy of xopup handy for times when i've made my main install unbootable. (yes, it happens :-) paul Special thanks to Paul Fox and Jon Nettleton for helping with the screen rotation. See the full announcement here: http://ftp.cc.uoc.gr/mirrors/linux/XOpup/Announce_XOpup-2.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touch-pad expectations
hal wrote: rich...@laptop.org said: One absolute we know is that the touchpad hates multi-touches. If you have more than 1 point of contact with the sensor then it will go bonkers. Due to the button placement below the touchpad this is quite easy to do. Its trivial to show that double touches throw the pad into a tailspin. Other failure modes are harder to duplicate. Thanks. That may be part of my problem. I keep my left thumb on the left button. My left hand is underneath the XO and the thumb wraps around to the button but doesn't get near the touchpad. But my ring finger may be drooping down and getting close enough to cause troubles. I'll try to keep an eye on that. I would really like to see some feedback when it is doing a recalibrate. Can somebody point me at the right section of code and/or provide a few hints on how to implement that? I'm thinking of a hack, nothing clean and elegant. For an experiment, I'd be happy to dedicate any corner of the screen. (Say 1/4 inch sq, or bigger if I can't see that fast enough.) the recalibration happens in the touchpad driver: http://dev.laptop.org/git/olpc-2.6/tree/drivers/input/mouse/hgpk.c?h=olpc-2.6.31#n601 there's no direct indication to userspace when a recalibration occurs, but during development i had a script of some sort that watched for the kernel message you see there, i.e. Recalibrating touchpad.., and beeped or something when it happened. there are other tuneables available as well -- feel free to play with them, obviously. see here, and following: http://dev.laptop.org/git/olpc-2.6/tree/drivers/input/mouse/hgpk.c?h=olpc-2.6.31#n78 paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Integrity checking of firmware
sridhar wrote: Following on from my question about OS images, does the XO check the integrity of a firmware file before writing it? bootfw.zip files can be checked against the CRC, but what about the .rom files? the .rom files contain an internal checksum which is validated before flashing. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 10.1.3 image and Firmware q2e42
daniel wrote: Hi! We are using a software image based on dextrose, I know that the official OLPC software image is different, but for this question I think that is the same. We want to install dextrose (suppose 10.1.3 image) with the firmware q2e42. What do you think? This is possible or we will have problems with this combination of firmware and software image? you can read the release notes for the firmware releases between q2e42 and q2e45 here: http://wiki.laptop.org/go/OLPC_Firmware_q2e45 http://wiki.laptop.org/go/OLPC_Firmware_q2e44 http://wiki.laptop.org/go/OLPC_Firmware_q2e43 i'm sure the release will run. but q2e45 in particular contains a fix for machines hanging during boot (d.l.o #9100) as well as EC firmware which fixes issues with resuming from suspend from the touchpad. you can also see that q2e43 fixed very many bugs -- many of them are related to the selftest diagnostics, but others could affect OFW's ability to install new releases. we don't issue new firmware lightly, and of course we recommend that deployments always use the latest firmware. paul Regards, Daniel. -- Forwarded message -- From: Daniel Castelo dcast...@plan.ceibal.edu.uy Date: Tue, Feb 1, 2011 at 4:25 PM Subject: Dextrose and Firmware q2e42 To: dextr...@lists.sugarlabs.org We have delivered dextrose 1.0 for our XO 1.5 machines, we want to release this version to XO 1.0 one's, but based on some bad experiences that we had in the past we aren't allowed to update the firmware (problems with some machines that remained broken after the process). The question is, if we have the firmware q2e42 installed, will dextrose (version 1) run properly in this machines? After a first test ( ten minutes one) seem that works, but I suppose that we could have some problems if we don't update the firmware to the last version. Thanks Daniel -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2 601 57 73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] !! in 10.1.3, setting languages property clears all activities
daniel wrote: Hi Tim, On 28 January 2011 15:36, Timothy Falconer tee...@waveplace.org wrote: sugar-control-panel -s languages Kreyol/Haiti And after restarting, ALL OF THE ACTIVITIES ARE GONE. Can anyone confirm this or give me guidance. How can I set the language in a bash script in 10.1.3? I imagine this is because the language is not included. What version why would this make the activities disappear? paul of the software did you last successfully run this on? The languages included in 10.1.x are: en_US,es,ar,pt,pt_BR,fr,ht,mn,mr_IN,am_ET,km_KH,ne_NP,ur_PK,rw,ps,fa_AF,si,zh_CN Reconstructing the image with another language added is as easy as having good bandwith and a Fedora 11 machine available (which is probably very difficult if you are in Haiti). The target XOs must all be unlocked (security disabled). I'd be happy to guide you through the build process if this is an option for you. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
power management overview page on the wiki
i wanted to put up a page about powerd on the wiki (a little overdue, i know), and i realized that it wasn't really clear where i should put it. to that end, i've searched out all the obvious pages i could find related to XO power management, and grouped them all under: http://wiki.laptop.org/go/Power_Management_Overview which is now linked from the main Software page. as you'll see, some of the pages referenced there are fairly ancient, and only get included because of their titles. conversely, i'm sure there are other more informative pages that i didn't find which should be included. please add them if you know of any. there are also probably some other obvious pages missing. feel free to point those out too. :-) paul p.s. the powerd page is here: http://wiki.laptop.org/go/Powerd most of it was cribbed directly from a message i sent to the linux-pm list last summer. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: advantage of full linux over android for OLPC
sridhar wrote: On 18 January 2011 20:11, Carlos Nazareno object...@gmail.com wrote: Kudos on the switch and getting stuff to run on ARM. Low power = big big deal! (btw, is the battery tech still the same between the XO-1, 1.5 and 1.75)? Yes for the XO-1 and XO-1.5. The XO-1.75 is still in development, but I assume yes. definitely yes. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suppressing mesh
martin wrote: On Thu, Dec 23, 2010 at 1:49 PM, Paul Fox p...@laptop.org wrote: change if it's wanted. i don't know when it would get into a release, but the kernel rpm would be available shortly after. Does the patch apply to the F14 kernel? As things go, we'll prob look at this for the F14 series... dunno. probably -- it's a pretty small patch. (get it from the trac ticket (#10579), not from the mail thread.) paul (It's still interesting to have it on the F11 kernels, as a technically sophisticated deployment can choose to use it...) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suppressing mesh
after testing the patch below i've opened d.l.o #10579 to track this.
a revised patch is attached to that ticket. i can commit/push this
change if it's wanted. i don't know when it would get into a release,
but the kernel rpm would be available shortly after.
the revised patch adds a libertas_disablemesh parameter, which, if
set, permanently disables until the module is reloaded without it.
paul
paul wrote:
i wrote:
martin wrote:
On Fri, Dec 17, 2010 at 6:15 PM, Martin Abente
martin.abente.lah...@gmail.com wrote:
I wrote this script that is a little bit better than just waiting N
seconds,
and it seems to work fine:
...
great!
But I like Martin's idea better, just not sure how to make it work
atm.
embed exactly that chunk of code you wrote at the end of the function
I linked to earlier.
I'm 99.9% sure it'll just work. If/when it does, we make it
conditional on a config option and pester pgf to include it an
release.
this actually sounds like a perfect use for the resume script
hook to me, since they're already spawned into the background.
is mesh off a general problem?
so it seems that being able to permanently suppress mesh on the XO-1
is becoming a desired feature, since ad-hoc is the way forward if
mixing XO-1/1.5 in under a tree sharing.
but powerd isn't the right place for fixing this.
could others who've been inside libertas take a look at this small
patch? it adds a module parameter that would allow keeping mesh
disabled on card discovery, but also allow enabling it later on if
desired. (uncompiled/untested)
paul
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 3f81289..f355b6a 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -39,6 +39,10 @@ unsigned int lbs_debug;
EXPORT_SYMBOL_GPL(lbs_debug);
module_param_named(libertas_debug, lbs_debug, int, 0644);
+unsigned int lbs_startmesh = 1;
+EXPORT_SYMBOL_GPL(lbs_startmesh);
+module_param_named(libertas_startmesh, lbs_startmesh, int, 0644);
+
/* This global structure is used to send the confirm_sleep command as
* fast as possible down to the firmware. */
@@ -1347,7 +1351,10 @@ int lbs_start_card(struct lbs_private *priv)
/* Check mesh FW version and appropriately send the mesh start
* command
*/
-if (priv-mesh_fw_ver == MESH_FW_OLD) {
+if (!lbs_startmesh) {
+priv-mesh_tlv = 0;
+
+} if (priv-mesh_fw_ver == MESH_FW_OLD) {
/* Enable mesh, if supported, and work out which TLV it uses.
0x100 + 291 is an unofficial value used in 5.110.20.pXX
0x100 + 37 is the official value used in 5.110.21.pXX
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: re active the network mesh when suspends the system
martin wrote: Ok then, i think that patch you sent to the list is basically the same idea, being able to switch it off (in a elegant way). Is there someone I can bug to make sure that the patch you sent gets included? :) first someone needs to agree that it might do what i say it does, and then someone needs to test it, and only then can someone get it included. paul On Sat, Dec 18, 2010 at 2:43 AM, Paul Fox p...@laptop.org wrote: martin wrote: On Fri, Dec 17, 2010 at 6:15 PM, Martin Abente martin.abente.lah...@gmail.com wrote: I wrote this script that is a little bit better than just waiting N seconds, and it seems to work fine: ... great! But I like Martin's idea better, just not sure how to make it work atm. embed exactly that chunk of code you wrote at the end of the function I linked to earlier. I'm 99.9% sure it'll just work. If/when it does, we make it conditional on a config option and pester pgf to include it an release. this actually sounds like a perfect use for the resume script hook to me, since they're already spawned into the background. is mesh off a general problem? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
suppressing mesh
i wrote:
martin wrote:
On Fri, Dec 17, 2010 at 6:15 PM, Martin Abente
martin.abente.lah...@gmail.com wrote:
I wrote this script that is a little bit better than just waiting N
seconds,
and it seems to work fine:
...
great!
But I like Martin's idea better, just not sure how to make it work atm.
embed exactly that chunk of code you wrote at the end of the function
I linked to earlier.
I'm 99.9% sure it'll just work. If/when it does, we make it
conditional on a config option and pester pgf to include it an
release.
this actually sounds like a perfect use for the resume script
hook to me, since they're already spawned into the background.
is mesh off a general problem?
so it seems that being able to permanently suppress mesh on the XO-1
is becoming a desired feature, since ad-hoc is the way forward if
mixing XO-1/1.5 in under a tree sharing.
but powerd isn't the right place for fixing this.
could others who've been inside libertas take a look at this small
patch? it adds a module parameter that would allow keeping mesh
disabled on card discovery, but also allow enabling it later on if
desired. (uncompiled/untested)
paul
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 3f81289..f355b6a 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -39,6 +39,10 @@ unsigned int lbs_debug;
EXPORT_SYMBOL_GPL(lbs_debug);
module_param_named(libertas_debug, lbs_debug, int, 0644);
+unsigned int lbs_startmesh = 1;
+EXPORT_SYMBOL_GPL(lbs_startmesh);
+module_param_named(libertas_startmesh, lbs_startmesh, int, 0644);
+
/* This global structure is used to send the confirm_sleep command as
* fast as possible down to the firmware. */
@@ -1347,7 +1351,10 @@ int lbs_start_card(struct lbs_private *priv)
/* Check mesh FW version and appropriately send the mesh start
* command
*/
- if (priv-mesh_fw_ver == MESH_FW_OLD) {
+ if (!lbs_startmesh) {
+ priv-mesh_tlv = 0;
+
+ } if (priv-mesh_fw_ver == MESH_FW_OLD) {
/* Enable mesh, if supported, and work out which TLV it uses.
0x100 + 291 is an unofficial value used in 5.110.20.pXX
0x100 + 37 is the official value used in 5.110.21.pXX
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: re active the network mesh when suspends the system
martin wrote: I have done a few test in 3 different builds, the tests are: A. Killing the mesh with echo 0 /sys/class/net/eth0/lbs_mesh, then suspend and then check if the mesh is re-activated after resume. B. While the mesh is active, add a script in postresume.d with the same line to kill the mesh (granting it run permission), then suspend and then check if the mesh is de-activated after resume. The builds I used for the test are: * olpc os852 (powerd 26, kernel 2.6.31_xo1.20100823.1641.1.olpc) * olpc os359 (powerd 32, kernel 2.6.31_xo1-20101119.1249.1.olpc) * last dextrose 2 (powerd 32, kernel 2.6.31_xo1-20101216.1250.1.olpc) Results: For build os582: A: the mesh is _not_ being re-activated (this is the behaviour we need!) B: postresume.d scripts are not supported. (but if does not matter because with A is enough) there was a bug in os852 which prevented us from ever powering off the wlan during suspend. it was as if config_MESH_DURING_SUSPEND was always turned on. have your script sleep for 10 or 20 seconds before disabling mesh, and see if that helps. there may be a better solution, but that would give some more data. paul For build os359: A: the mesh is re-activated. :( B: the mesh is not being de-activated (even though the script effectively runs, something else must be happening _after_ postresume.d script that re-activates the mesh) For build last dextrose 2: A: the mesh is re-activated. :( B: the mesh is not being de-activated (it is probably the same problem as with os359) Comments: I am not sure why the os852 build behaves as we need, while any of the newest builds does not. Could it be a regression in powerd? =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: re active the network mesh when suspends the system
martin wrote: On Fri, Dec 17, 2010 at 6:15 PM, Martin Abente martin.abente.lah...@gmail.com wrote: I wrote this script that is a little bit better than just waiting N seconds, and it seems to work fine: ... great! But I like Martin's idea better, just not sure how to make it work atm. embed exactly that chunk of code you wrote at the end of the function I linked to earlier. I'm 99.9% sure it'll just work. If/when it does, we make it conditional on a config option and pester pgf to include it an release. this actually sounds like a perfect use for the resume script hook to me, since they're already spawned into the background. is mesh off a general problem? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: re active the network mesh when suspends the system
martin wrote: On Wed, Dec 15, 2010 at 11:52 AM, Esteban Arias ear...@plan.ceibal.edu.uy wrote: I have the mesh inactive (dextrose version xo-1.0) In the file: /etc/rc.local I have: echo 0 /sys/class/net/eth0/lbs_mesh but, when suspends the system, (close and open the laptop xo), reactive the mesh I think recent versions of powerd can run scripts on resume -- actually post-resume scripts have been available for some time. it was pre-suspend scripts that were added recently. look for Post-resume scripts in /usr/sbin/powerd for documentation. Note: these scripts run when there's a high likelihood that the system will, or did, suspend. but the suspend may not actually have happened. in the case being discussed (echo 0 lbs_mesh), it sounds like that's probably okay, but you wouldn't want to use these script hooks to implement a suspend counter, or something that breaks the system if the suspend didn't actually take place. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rotation on VX855 saga
mitch wrote: On 12/16/2010 5:08 AM, Martin Langhoff wrote: - Mitch - does the OFW change make sense, or will it make other OSs explode? IOW, who is responsible for dcon-unfreeze on the resume codepath? The only way to find out is to test it. it also might be useful to understand the history behind the code. i looked for a similar dcon unload in the XO-1 resume path, and didn't find it (but didn't expect to, and so could have missed it). is it possible that the unfreeze in the via code was leftover from early development, when the kernel didn't yet have a dcon driver? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: re active the network mesh when suspends the system
esteban wrote: if I change configuration /etc/powerd/powerd.conf runs ok. config_MESH_DURING_SUSPEND=*yes* is this on XO-1? if not, then i don't know how that would change anything. if so, then you should know that doing this probably causes the wlan to stay powered (and it wakes almost 1W!) when the lid is closed or you've used the power button to put the laptop to sleep. a resume script would be a better solution, if it works. paul Regards 2010/12/16 Paul Fox p...@laptop.org martin wrote: On Wed, Dec 15, 2010 at 11:52 AM, Esteban Arias ear...@plan.ceibal.edu.uy wrote: I have the mesh inactive (dextrose version xo-1.0) In the file: /etc/rc.local I have: echo 0 /sys/class/net/eth0/lbs_mesh but, when suspends the system, (close and open the laptop xo), reactive the mesh I think recent versions of powerd can run scripts on resume -- actually post-resume scripts have been available for some time. it was pre-suspend scripts that were added recently. look for Post-resume scripts in /usr/sbin/powerd for documentation. Note: these scripts run when there's a high likelihood that the system will, or did, suspend. but the suspend may not actually have happened. in the case being discussed (echo 0 lbs_mesh), it sounds like that's probably okay, but you wouldn't want to use these script hooks to implement a suspend counter, or something that breaks the system if the suspend didn't actually take place. paul =- paul fox, p...@laptop.org -- Esteban Arias Investigación y Desarrollo - Plan Ceibal Avda. Italia 6201 - Edificio Los Ceibos Montevideo - Uruguay. Tel.: 2601.57.73 Interno 2228 E-mail : ear...@plan.ceibal.edu.uy =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why do we rfkill in Sugar?
[ moving to devel ] martin wrote: Hi Paul, techteam, you patched the codepath that controls the wireless disable to run rfkill to *really* kill the network when wwe mean to kill the network. Why did we do this? Regulatory reasons? Is there a tracking bug where I can get more background? The commit msg was rather terse :-) Why do we care? It is confounding GNOME/NM/nm-applet, and depending on the rationale, my workarounds may be valid or not. we needed a way to control power to the wireless card for power management. on XO-1, we used a private mechanism (/sys/power/wlan-enabled), but on 1.5, we wanted to something standard. so we implemented rfkill. we later, also implemented rfkill on xo-1, which makes common code at user level possible. NM will react to changes in a devices rfkill status. it will not, however, actually control rfkill. and yes, i was aware that the NM applet disable function was incompatible. what are your workarounds? paul cheers, m -- mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] prevent screen rotation in a sugar activity?
...there are however practical considerations on XOs that lead us to want to disable UI rotation. ... i guess i don't understand how this would work in practical terms. i'm using my XO, and, at the home screen, i push the rotate button, and start playing with it in portrait mode. i bring up Read, and enjoy an ebook for a while. i then bring up a cool game a friend showed me recently, and all of a sudden i have to change how i'm holding the laptop. the game's not functioning the way i recall it from last week, so i go to the journal -- and have to rotate the laptop again -- to find the older instance. i click on it, and annoyingly, i have to yet again change my hold on the laptop. perhaps this is smooth/seamless on an iphone or android, but i'm having trouble picturing it on an XO. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
i'm pretty sure those numbers (and the corresponding numbers from the
1.5 DSDT) came from the battery manufacturer. obviously we could move
the data to the EC, but i'm not sure what the advantage of that would
be. i know that the numbers don't come from the battery itself.
paul
mitch wrote:
By not providing more information, I was sending a subtle signal that I
am busy with something else right now and do not want to go into
digging up everything I know or can find out about batteries mode at
the moment.
On 12/10/2010 3:09 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradleyw...@laptop.org wrote:
There is some battery info in the _BIF (battery info) method in the
BATT node of the ACPI DSDT. I don't remember if it is correct or
not. The numbers below match the DSDT numbers.
Wait, so where did *those* numbers come from? A spec somewhere, the
EC, or did you actually reverse engineer them?
(Note that ACPI is only available on XO-1.5, so pulling them from ACPI
on XO-1 isn't an option.)
On 12/10/2010 2:38 PM, Andres Salomon wrote:
On Fri, 10 Dec 2010 22:15:10 +
David Woodhousedw...@infradead.org wrote:
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Looking for startup sound recording
sridhar wrote: I'm looking for a recording of the XO startup sound. It is identified on this wiki page as Edge1-8k-EQ-Comp-Amp-Short.wav: http://wiki.laptop.org/go/Startup_sound However, the link to the file is broken, and Web searching isn't helping either. Does anyone know where I can get a copy in a standard format? i think there are mp3 and wav copies here: http://dev.laptop.org/~pgf/Edge1.mp3 http://dev.laptop.org/~pgf/Edge1.wav but the computer i'm using right now isn't audio-capable, so you'll have to listen and decide for yourself if it's the right tune. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 ebook switch driver - upstream submission
daniel wrote: Hi Paul, I've made some small changes to your code for the XO-1.5 ebook switch driver and am wondering if you have any comments before I submit this upstream. this looks great. thanks again for taking this on. i haven't yet had a chance to do a close review (will do tom'w), but assuming the details are right, just a couple of initial comments... - driver renamed to xo1p5-ebook like chris, i don't think this is a great name. we already use at least two naming styles (olpc_dcon_xo_1_5.c, olpc-pm-1.5.c) and introducing a third doesn't seem great. frankly, i think xo15, xo175, etc, would be sufficient, since the lack of a decimal is unlikely to lead to ambiguity, but barring that, i'd stick with using '_'. (of course, if dcon hasn't gone upstream yet (i don't recall), then now would be the time to change it too, if we want to change.) - THRM# bit handling removed, since we'll do that in the DSDT (pending Mitch's approval) whether or not we eventually decide to apply your DSDT patch, i think we'll probably want to leave the in-kernel bit twiddling in place for at least until the new firmware is available. and i guess i'm assuming that we wouldn't do new firmware just for this, but would wait until some more compelling reason came along. paul - /proc interface removed - /sys interface added (much simpler) - minor updates for new ACPI API powerd will need an update for the /sys change. I'll take this on when the time comes. (all this is framed for post-F14 release) [PATCH] OLPC XO-1.5 ebook switch driver ... =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F14 os3 development image released (XO-1 and XO-1.5)
da...@lang.hm wrote: On Fri, 26 Nov 2010, Samuel Greenfeld wrote: On 11/26/2010 9:43 PM, Bernie Innocenti wrote: * Automatic power management seem to have improved a lot and is almost unnoticeable. However, can't we disable it while the laptop is on AC? I'm pretty certain I recall reading that XOs show the charging indicator light to show they have enough external power to charge. The charging light does not necessarily indicate that there is external power to charge the battery and run the laptop at the same time purely from an external power source. XO's do not presume that the external power source is an AC adapter, allowing a wide range of input tolerances before you damage the computer. that's fine for the default, but there should be some way to tell the system that when I plug it in to external power, that can be considered AC and disable automatic power management. the dim, blank, and sleep timers can all be set separately for the externally powered case, and set to 0 to disable them completely. by default they're set the same for both battery and external power. the one setting that's different in the default config is that on battery, they system will eventually shut down on its own. on external power, it will not. (btw -- that last setting (when to shut down when sleeping) is set to just 1 hour. since the 1.5 can stay asleep for several days before the battery goes, one hour is probably a bit aggressive. paul David Lang There is a somewhat stale wiki page at http://wiki.laptop.org/go/Battery_and_power with a lot of user comments about what happens if you try to charge an XO via various alternative means. --- SJG ___ 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Firmware update
c. scott ananian wrote: At one point Michael and I also had a side-loading mechanism implemented -- if you put your target RPMs in some directory in /home/olpc -- I think it was ~/.rpms -- then they'd automatically get re-installed after olpc-update. That was (at the time) the preferred mechanism for adding a few packages persistently to a build. Assuming this mechanism hasn't code-rotted, this is a nice intermediate step: less work than rolling an entire new build, and relatively easy to accomodate new upstream builds without disruption. see #6432, and http://wiki.laptop.org/go/Yum#Making_persistent_changes i believe the location was/is /home/olpc/.custom/rpms, but i haven't tried using it in a very long time. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrading a _very_ old OLPC
sameer wrote: Krishnan is local to SF. We'll help him get upgraded. be sure and verify what hardware he has before starting. build 417 is pretty old, and could represent a pre-B3, or whatever the oldest machine still installable with current s/w is. paul Sameer On Wed, Nov 17, 2010 at 1:16 AM, C. Scott Ananian csc...@laptop.org wrote: -- Forwarded message -- From: Krishnan R.S. rskrish...@hotmail.com Date: Wed, Nov 17, 2010 at 2:48 AM Subject: Upgrading a _very_ old OLPC To: csc...@laptop.org Hello, I managed to get my hands on a very old OLPC XO laptop for my daughter. I've been trying, unsuccessfully, to upgrade the OS to something current. The main issues are: My image has no olpc-update I tried to follow the wiki instruction to update olpc-update - alas that leads to more issues about missing python2.5 I tried to install python using apt/deb/dpkg but all of these fail since the apt/deb/dpkg tools are missing :( Looking at /etc/issue - I see build 417 - and some messages that look like errors kernel \r \m :) so maybe I have a pre-alpha build :) So ... I'm somewhat at a loss as to what my next steps are. My daughter seems pretty excited with the device and enjoys the paint application. I'd like to get a more recent build so she can use the newer apps/toos. Can you point me in the right direction ? Or am I wasting my time trying to do the impossible? Thanks, Krishnan +1-415-606-3069 -- Krishnan Subramaniam rskrish...@hotmail.com -- ( http://cscott.net/ ) ___ 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Swapping microSD cards
sridhar wrote: Is there anything wrong with swapping the internal microSD cards between XO-1.5s, for testing or even in deployment? This would be a quick way to move a software installation (including the Journal) from a broken XO/motherboard to another, hence simplifying repairs. there's no problem at all with doing this. you can also move between internal and external (with an adapter) for testing, file transfer, etc. (external will take priority when booting.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New 10.1.3 build os351 for XO-1 and XO-1.5
daniel wrote: I have tried to migrate the Screen rotation support fix to our Dextrose version: I installed: +olpc-kbdshim-15-1.fc11.i586 +olpc-powerd-29-1.fc11.i586 +olpc-powerd-dbus-29-1.fc11.i586 +xorg-x11-drv-openchrome-0.2.990-1.fc11.i586 And I modified /etc/X11/xorg-x1.5-dcon.conf to add this line: Virtual 1200 900 (based on Martin's email). With this steps If I press the rotate button the screen changes, but the behavior is not appropriate. not appropriate in what way? paul Do you have any idea? Maybe we have to modify some Sugar packages to have this feature working? (remember that we have a version of sugar based on sugar 0.88). Regards, Daniel. On Wed, Nov 3, 2010 at 10:28 AM, Simon Schampijer si...@schampijer.dewrote: On 11/03/2010 01:18 PM, Martin Langhoff wrote: On Wed, Nov 3, 2010 at 7:49 AM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: Can I install this 2 GB image in a XO with 8 GB for test purpose? Yes. And if you can put the SD card on a different machine you can use resize2fs on it. m Yeah - I have only build the 2GB images for now due to size constraints on the build machine. Yes, you can install it on a machine with 2GB. There will be 8GB images soon, too. Regards, Simon -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2 601 57 73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Synaptics driver on XO-1.5 hw?
martin wrote: On Thu, Oct 28, 2010 at 11:01 AM, Daniel Drake d...@laptop.org wrote: Are there reasons to think Synaptics may now work? As far as I know there is still no explanation nor diagnosis for the super-strange EC behaviour in this mode. I don't know if anyone has tested if the same occurs on XO-1.5. Well, I have now. Works very nicely, does not show any of the scary issues discussed in #8901. It may still be spewing too much information, not sure how to measure that. EC does not seem to get swamped or confused. it's entirely possible that the incremental performance improvements that have gone into the EC over time have changed the behavior. be sure to test touchpad sanity while battery is both charging and discharging, since it's the battery calculations that can hold off ps2 bytes from being transferred. paul The synaptics driver will need a similar set of S/R hacks that we apply to psmouse in order to play nice with idle suspend. I don't know the full range of S/R hacks. Our psmouse code using proto=bare seems to be a tad smarter -- it captures the wakeup stroke when we're waking up from TP activity. Synaptics mode misses it. That's all I can see. Also, kbdshim will need an update, because right now it only deals with relative input devices. Agreed. Collected this info, and outcomes of my test, here http://dev.laptop.org/ticket/10417 thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut
james wrote: On Wed, Oct 13, 2010 at 01:20:17PM +0200, Simon Schampijer wrote: Ok, my point was that I do not have to unlink the files in Sugar, since powerd takes care of that. It would be more efficient for the activity to unlink the files rather than leave the job to powerd. The activity can know it needs to be done. powerd has to find out by calling kill(2) with a sig of 0 in inhibit_files_present(). powerd executes in bash, and kill is a builtin, so it's not a huge cost. if it's trivial for the activity, sure, but it's not very expensive for powerd -- it's exactly the cost of a kill and an unlink. there's much juicier, much lower fruit on the tree to be had, i'm sure. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power down USB when suspending
=?iso-8859-1?q?mat=edas_poloni?= wrote: We are engineer students from Uruguay and we are working on our grade thesis with a XO-1 olpc laptop. We need to take a photo after resume with a usb webcam as quick as possible. We already know that the usb is powered down when suspending and this leads to excesive delay taking a picture after resume. We can`t find any documentation explaining why it is not possible not to power down the usb. We`ll be very grateful if you help us with information related with this issue because we need it for the documentation of our thesis. the external USB ports cannot be powered during suspend due to hardware limitations. (this is true for both XO-1 and XO-1.5.) paul Is there any tip to power up the usb sooner when resuming? Or something to have a smaller delay? Thanks! -- Matías Poloni +598 98867573 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #10363 NORM 10.1.3: Auto-Suspend gets in the way when sharing over Salut
tomeu wrote: On Thu, Sep 16, 2010 at 23:38, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Sep 16, 2010 at 5:05 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: So the problem is that if you had to resync all state for each machine every time they wake up, you would use lots of bandwidth with the (...) Another issue with this is that you not only want to resync presence, but shared activities also would need to resync their state. Correct. My notes on the bug are probably unreadable -- it was late last night, apologies. What I mean to say is that we could 1 - explore the interaction between sleep timeouts and Salut resync frequency for presence 2 - hack the Tubes/Telepathy stack to _prevent sleep_ while an actual collaboration session is running I think #1 needs to be done regardless, as it'll improve behaviour even if/when we our networking/suspend issues sorted. And some of the issues in network/suspend interaction won't be easy to resolve. I doubt there's much that can be done in Salut about it, should be instead done inside Avahi. I would see how mDNS works, then look for opportunities of tuning knobs in Avahi to speed up rediscovery: http://tools.ietf.org/html/draft-ietf-dnsext-mdns-47 I'm going to ask around in case somebody has already thought of it and can provide a shortcut. the laptop knows how long it was suspended, and this information could be made available to a resume hook (which almost exists, but not quite, in powerd) if it would be useful. i.e., a a post-resume script could decide whether to kick the protocols to do something differently, if that was needed. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: USB charging while XOs are switched off
christoph wrote: Hi all, going through some of my notes from South America I stumbled across a question from a Peruvian teacher who had asked me whether future XOs would allow her to charger her mobile phone while the XO is turned off. Not sure where she had seen that but I think it combination with more and more mobile phones going to towards USB chargers this is actually quite an interesting idea. Is this a feature that has been considered for the XO-1.75? if by off you really mean off, then i doubt the USB ports will have power when the laptop is off. if by off you mean in suspend, then i'm sure we'll be considering it. we were hoping to have USB powered during suspend on 1.5, but were foiled by poor documentation of the gpio pins in question. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] [IAEP] Announcing the OLPC OS 10.1.2 final release!
kevin wrote: On Mon, Sep 06, 2010 at 10:16:42AM -0700, Sameer Verma wrote: James, I've noticed this when updating fully drained XOs. The power indicator blinks when plugged in, but upon reflashing, when the XO reboots, it won't apply the firmware because the battery is too low, and will skip to booting into the new OS image. Would it be worth someones time to find a way to notify the user about this: That it is waiting to be plugged-in or for sufficient voltage before it completes the firmware upgrade. Would this be OFW or OLPC OS work? i believe the user is already notified, with a warning in red, that the flash update has been skipped. but it's true that that warning isn't localized, and is relatively easy to miss (since the system keeps booting). the assumption is that the firmware will be updated the next time the laptop _is_ booted with two power sources, and that that laptop will function adequately until that time. it would certainly be possible to write a frame applet that that warned about this condition, by comparing the available firmware to the installed firmware. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WiFi vs suspend
hal wrote: I have blundered into what may be a workaround for bug 10232 http://dev.laptop.org/ticket/10232 The fix is to edit /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service and add -dddt to the end of the Exec line. It ends up looking like: Exec=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid -dddt [That's one long line that got wrapped.] After that change, I haven't had any hangs in over 24 hours. Without that change, I get one in a few hours. is this still consistent for you? I'd be curious to see if it works for anybody else. me too. i've just released a new powerd-27 which contains a fix for XO-1 which might affect whether power to the wlan is maintained in some cases, and might also cause wake-on-wlan to be disabled by mistake. in addition, i spotted a problem which i don't think we've yet seen, but which might be an issue: the laptop sometimes wakes up for a very short time, usually the result of a battery state change. if a suspend happens very quickly after a resume, the wireless device may not have been fully reinitialized yet, and ethtool will fail when setting the wake-on-wlan options. since those options aren't sticky, it may be that this causes options previously set to be lost. i haven't yet tested to confirm this, but would welcome someone else contriving such a test. (i'm doubtful that this is causing the problems people are seeing currently, but one never knows.) http://dev.laptop.org/~pgf/rpms/olpc-powerd-27-1.fc11.i586.rpm * Wed Sep 1 2010 Paul Fox p...@laptop.org - 27-1 - fix suspend-inhibit for the camera on XO-1.5 (broken in 26-1) - fix no-keypress-wakeup blank-screen suspends - make checks for external power more robust - be more insistent about sync-before-suspend - reduce default brightness to 12 (was 15, full bright) - try not to assume wlan is eth0 paul Don't forget that it doesn't wakeup on ARP packets so you have to manually setup the arp table entry on the machines that you expect to wake it up. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Dextrose] WiFi vs Suspend
tony -- thanks for this. if you could, please open a trac ticket (bug report) at http://dev.laptop.org to describe this issue. the next time it occurs, in order to more simply gather most of the information bernie asked for, plus a little more that may be useful, please run the command olpc-log from a Terminal window. this will create a file called logs.serial_no.timestamp.tar.bz2 in your current directory. please attach that file to the trac ticket. in fact, please run the command twice -- once during the locked up period, and again after, and attach both files. possibly overkill, but might be useful. (the olpc-log command takes an fairly long time to run, but it collects lots of information.) paul fors...@ozonline.com.au wrote: Bernie Sorry, on closer inspection its not locked up, it just looks like its locked up because it is doing something else for a long time. Can be replicated 100%. Shut the lid for a while, 5 minutes is not long enough 1.5 hours is. Resume from sleep. The Wifi shows it is connected at 100% signal (signal is not 100%). There is no internet access. There is no response to Disconnect. Previously I had given up and restarted but if you wait 3 minutes or so it disconnects and then works normally. Tony [cc += olpc-devel] El Wed, 25-08-2010 a las 11:05 +1000, fors...@ozonline.com.au escribió: OS373pyg Wifi is locked up after resume from sleep, must restart. I presume this bug is being tracked at dev.laptop.org/ in one of the 4 tickets below http://dev.laptop.org/ticket/10232 WiFi dies on suspended XO-1,os300 http://dev.laptop.org/ticket/10092 Networking broken over suspend/resume on os13 for XO-1 http://dev.laptop.org/ticket/9960 wake-on-WLAN doesn't always work\ (duplicate) http://dev.laptop.org/ticket/9967 ibertas suspend fails on XO-1 (fixed) There are a number of unsolved bugs in the libertas kernel driver or in its fantastically proprietary firmare. If you turned on automatic power management on an XO-1, you might be seeing this other one: http://dev.laptop.org/ticket/10195 In short, very rarely the libertas usb8xxx disappears from the USB bus when it receives certain commands from the driver. Suspend/resume are known to trigger quite frequently and the mesh also seems to cause it once or twice per day in a classroom of 30 students. Because time for debugging was running out, in the latest beta builds I had to disable both mesh support and automatic power management in the attempt to get rid of this bug. After one week of testing, the problem was not reported any more. If you spot this bug again, could you please: * check whether eth0 is still visible with ifconfig -a * check whether the Marvell 8xxx is still visible with lsusb * dmesg dmesg.out and attach it to the bug. Dextrose enables libertas debug in /etc/rc.local to help diagnose this bug. This never ending saga brings me back to an exasperated email that David Woodhouse wrote about 3 years ago, after spending many days in unfruitful debugging, in which he warned that access to the source code of the firmware was essential in order to nail down all the obscure Libertas bugs. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing single file via signed OFW script
martin wrote: [ background: working with a local team in a process that needs to be quick. Booting linux would take way too long and throw our logistics out of whack ] Is there a straightforward way to have a signed forth script (local team has its own keys) that creates/installs a minimal file to a known location? We just need to install a config file under /etc ... as far as i know, writing to the ext3 root partition from OFW is officially unsupported. the boot partition is ext2 precisely because ext3 can't be written reliably from OFW. if you can put the file in the boot partition, then there are copy commands that let you creat files on int:, i believe. i don't have them at my fingertips. paul (I'll take care of sorting out the /versions rigmarole :-) ) cheers, martin =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: git help needed for 2.6.34 kernel branch revival
daniel wrote: On 17 August 2010 15:08, Paul Fox p...@laptop.org wrote: would it work better to merge each of the the -stable kernels in turn? because then you'd probably get the undo of the -stable change along with the mainline change that supercedes it. but that might not work, and it would be a lot of merges. Not sure what you mean. Can you give a more specific example? Do you mean UNmerge the 2.6.31-stable kernels? (6 were already merged...) i probably don't understand the problem well enough. i was thinking that merging in the rest of the -stable kernels (and there would be a lot of them, from 2.6.31.7 to 2.6.34.N) would get you closer, in a more automated way. the more i think about it the more doubtful i am. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
gary wrote: P.S. of corse you'll now tell me os850 was also pre-linked (I couldn't see anything about it in the build notes for either os850 or os851), and I'll look silly for trying to test for a difference, confirming my results were non significant ;-) that's exactly right. :-) pre-linking has been in the builds for some time, i believe. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend: RTC wakeup, sleep
hal wrote: Can somebody give me a pointer to some sample code that will wake up a suspended system in 5 minutes? I'm assuming there is some way to do this using the alarm interrupt from the RTC. use: rtcwake -s 600 -m mem to wake the system in 600 seconds, after suspending it to S3. see the man page -- but other -m options work, including no, i believe. (although, if someone tries it and it does work, i'll stand corrected.) Can somebody confirm that sleep does what I expect on suspended systems? My expectation is that the sleep timer logically ticks when suspended, but that the system won't get woken up when the sleep timer expires. For example, suppose my program does a sleep(100), and shortly after that the system suspends. If the next wakeup is 200 seconds after the start of the sleep, my program should run then (along with whatever caused the wakeup). Or if the system wakes up after 50 seconds and doesn't suspend again, my program should run 100 seconds after it started to sleep. i'm afraid not. your sleep will be stretched by the duration of the suspend. see the following. a 30 second sleep starts at 15:42:41. the system suspends for 15 seconds, and wakes (that's where the +r gets printed) at 15:43:01 (2 seconds later than it expected to, btw). the sleep terminates, and prints sleep ended and the date at 15:43:25. that's roughly 45 seconds after the 30 second sleep started. [r...@xo-a7-2a-c8 dev]# touch /var/run/powerd-inhibit-suspend/1 [r...@xo-a7-2a-c8 dev]# (date; sleep 30; echo sleep ended; date) [2] 3122 Wed Jul 28 15:42:41 GMT 2010 [r...@xo-a7-2a-c8 dev]# rtcwake -s 15 -m mem; date rtcwake: assuming RTC uses UTC ... rtcwake: wakeup from mem using /dev/rtc0 at Wed Jul 28 15:42:59 2010 +rWed Jul 28 15:43:01 GMT 2010 [r...@xo-a7-2a-c8 dev]# sleep ended Wed Jul 28 15:43:25 GMT 2010 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Broken /etc/rc.local
hal wrote: I botched an edit to /etc/rc.local and now my system hangs during boot. Is there a way to edit a file from firmware? Or delete a file? OFW understands how to read and write ext2 filesystems, so the built-in (micro-)emacs can edit files on /boot. (this is why /boot is an ext2 fs -- so OFW can fix errors in the boot partition.) but the root fs is ext3, and i don't think OFW will touch it, at least not for writing. i keep a separately bootable image around for such occasions -- either a USB or external SD card loaded with an OS i can boot, and use to rescue the primary installation. easiest way to create is to take a spare SD card, and use fs-update: ok devalias fsdisk ext: ok fs-update u:os126.zd then boot the external card, and it will automount the internal card. (i've also used mavrothal's TinyCore images to rescue my laptop -- they boot much faster, so if you're breaking the system a lot, can be handy.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] devel announce list; publicizing major software firmware updates
bernie wrote: El Mon, 19-07-2010 a las 17:32 -0400, Samuel Klein escribió: We have a devel-announce list that hasn't been much used. We also have many people who are interested in getting news about any major release or security update, but don't have time to read all of the traffic that goes to devel. Reuben, Paul and I were discussing this earlier today; I would be happy to see more people using devel-announce to publicize major updates. As there is some demand for this kind of low-traffic list, if you are interested in that information, please sign up. http://lists.laptop.org/listinfo/devel-announce Is this list appropriate also for announcing unofficial builds for the XO, such as the F11-0.88 series? (lately I've become too lazy^W busy to post release notes for our builds...) i believe devel-announce is / will be moderated, and that yes, announcements of non-OLPC builds would be appropriate. since the list won't allow discussion, announcements should probably include a pointer to where discussions of and feedback on the release being announced should occur. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
james wrote: On Tue, Jul 20, 2010 at 01:04:06AM -0400, Raul Gutierrez Segales wrote: On Mon, 2010-07-19 at 21:33 -0400, Walter Bender wrote: On Mon, Jul 19, 2010 at 9:27 PM, Gonzalo Odiard godi...@gmail.com wrote: Yeah How we detect what keyboard is present? http://wiki.laptop.org/go/OLPC_Firmware_q3a44 mentions: 1889: OLPC keyboard driver, avoid confusing EC with enable scan command That's unrelated, I think. yes. the keyboards are indistinguishable electrically, without user input. I wonder if somehow the type of detected keyboard is discoverable via /ofw. The manufacturing data may help to narrow the possibilities, but they would have to be maintained correctly in conjunction with any keyboard changes by deployment repair. Perhaps someone else knows more. right. when the laptops are build, the included keyboard is identified with a specific tag. specifically, the KM tag is olpcm for the mechanical keyboard, and olpc for the membrane keyboards. however, someday it will be possible to swap between membrane and mechanical keyboards (it isn't yet), and that will raise a new identification issue. i suspect we'll end up with a user utility of some sort to correctly identify the keyboard to the system. the upper right-hand key, for instance, is unique on each, so asking the user to hit that will be sufficient. the utility will then rewrite the mfg tag (doubtful) or modify the filesystem (more likely) to record the identification. further background: the KM mfg tag is used by /etc/init.d/olpc-configure to set up the XKB_MODEL variable assignment in /etc/sysconfig/keyboard (this happens just once per software install). when the user session starts, olpc-session sources /etc/sysconfig/keyboard, and passes the XKB_MODEL value to setxkbmap. setxkbmap can in turn be queried to find out what keyboard model (and layout and variant) is in use. i suspect that this is the mechanism that applications should use to detect which keyboard they have, because it's xkb that has to have the right answer in order for all the characters to work correctly. i don't know if there's a programming API lurking under the covers in setxkbmap -print, or not. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
i'd like to bring this discussion to a conclusion. i'm starting to be a fan of this proposal of bert's -- it's very simple, keeps the keys the same in sugar and in gnome, and on membrane and non-membrane keyboards, it's backwards compatible with existing use on XO-1, and the volume/ brightness keys remain easily discoverable. it does require that sugar respond to F5 and F6 for journal and frame -- i still don't have a feeling for whether that's an issue or not, and if so, how big. any yeas or nays? paul bert wrote: On 17.07.2010, at 09:31, Bernie Innocenti wrote: El Thu, 15-07-2010 a las 23:08 -0400, Paul Fox escribió: i think everyone (except apple, i'm learning tonight) agrees this is the correct setup when not in sugar. Lenovo also seems to be switching to the Apple layout: http://www.blogcdn.com/www.engadget.com/media/2010/01/thinkpadedgepost16.jpg http://www.thinkpads.com/wp-content/gallery/lenovo-thinkpad-edge-13-review/lenov o-thinkpad-edge-13-keyboard.jpg Almost all the historic F-key mappings have an alternative CTRL+key or ALT+key mapping in modern HIGs. Keys to control laptop volume and brightness are accessed much more frequently, so it's foreseeable that over time they will supplant the F-keys in PC keyboards. +1 IMHO pressing fn to get f1 to f10 makes sense. In my daily routine I much more often change volume or brightness than use the numbered F keys. Looking at this again http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard I propose: f1-f8 produce F key codes both with and without the fn key f9-f12 produce F codes only with fn, and volume/brightness events without fn. So holding down fn always gets you the F key codes, you can change volume/brightness without modifier, and as a bonus you can use the first eight F keys even without the fn key. This mapping should work both in Sugar and outside. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
daniel wrote: On 15 July 2010 18:26, Walter Bender walter.ben...@gmail.com wrote: Presumably there is a way to detect which keyboard is installed in the machine? While I love Gonzalo's use of the F5-F8 keys, the need for Frame and Journal keys on the non-membrane keyboards is more important in my experience. Yes, let's limit this discussion to the non-membrane keyboard. Not planning any changes in the membrane keyboard (without separate discussion). Walter, what's your opinion? i guess i don't understand why the question is either/or. as i've coded it (so color me biased :-), when running gnome (or anything not sugar), all of the function keys are available to applications. only four of the keys with special labels on them have any meaning in gnome (i.e., the four brightness/volume keys) and those are available with the Fn key. i think everyone (except apple, i'm learning tonight) agrees this is the correct setup when not in sugar. when in sugar (assuming a small patch to sugar, which could presumably be made XO-dependent) all of the specially labeled keys are available without an Fn modifier, and as such act just as they do on the membrane keyboard. this includes the brightness/volume keys. this felt both more compatible and discoverable to me, and to cjb, but this laptop is for an older audience, so maybe that doesn't matter. in addition, the brightness and volume keys are available with Fn. for more uniformity, the rest of the special-labeled F1-F6 could be made available in sugar with Fn as well, with a bit more udev keybinding. as far as i understood, sugar doesn't make much use of the function keys above F1-F4, so i didn't think there was a need to keep them all clear. am i wrong about this? my limited sugar use has been on XO laptops -- i don't have much experience with SoaS. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: xo-1 os300 -- switch off mesh?
martin wrote: Hi all, Is there a way to tweak the os300 build so that it brings up the Libertas device just as eth0 (and doesn't enable the 802.11s features in the firmware)? was there a way to do that in 802? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disabling powersaving temporarily from olpc-session?
hal wrote: martin.langh...@gmail.com said: what would be the right way to signal to powerd that for this session aggressive suspend should be suspended, or its timeout lengthened to several minutes, without affecting the normal setting? My notes say that: touch /var/run/powerd-inhibit-suspend Will inhibit suspend. close, but not quite. /var/run/powerd-inhibit-suspend/ is a directory. Google finds this: http://www.mail-archive.com/devel@lists.laptop.org/msg22607.html google is a good reference. when all else fails, read the comments in /usr/bin/powerd. overly verbose, perhaps, but hopefully complete. :-) there's no good way to lengthen the timeout temporarily. to disable, create a file in /var/run/powerd-inhibit-suspend/ whose name is the pid of the session. i.e., in olpc-session, do: touch /var/run/powerd-inhibit-suspend/$$ there's no need to clean up, so the exec at the end of olpc-session isn't a problem. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Permission problems and accessing usb dispositive
james wrote: Alberto, Sugar Activities are restricted in what they can do by design. It would be better if you could make your Activity work within Sugar's restrictions. One thing that might work is to make a Journal entry out of your compiled code, with a suitable MIME type if there is one. That way you can use the Journal to copy the code to the USB-attached device. James Simmons Date: Wed, 23 Jun 2010 09:03:58 -0300 From: Alberto Arruda de Oliveira alberto.a.o...@gmail.com Subject: [Sugar-devel] Permission problems and acessing usb dispositive To: sugar-de...@lists.sugarlabs.org Message-ID: aanlktikvdxszmt8le1gzkqnb4i7jowzlnmujnv7zt...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hello again, First of all, I'd like to thank everyone that helped me on my other thread, about adapting a software to run as an activity on XO. Thanks to you all, I was able to do it. But now, I'm facing another problem regarding the permissions olpc user has to access diferent dispositives on XO. The software I adapted uses the USB port to communicate with an external module, to which it will send a compiled code. It's an graphical programming tool, with the purpose of robotics teaching. The problem is, since OLPC user doesn't have enough permissions to access the ports, we can't send the compiled code to the external module, unless we manually change the permissions to do so. So, my question is, is there any way to do it without having to do it manually for every machine we install or activity in ? this has come up before, for the Scratch activity: in the XO-1 case, the trick was for Scratch to add the line use-serial to activity/permissions.info. this tells rainbow that this activity can access serial ports. see: http://wiki.laptop.org/go/Activity_bundles#activity.2Fpermissions.info in the XO-1.5 case, making user olpc a member of group dialout was the answer. USB serial devices are already accessible by that group (though i can't at the moment find what makes that happen), so this made everything okay. if the use-serial trick isn't appropriate on XO-1 anymore, then we could make user olpc a member of group uucp, if that's what you say is needed, but that will only help on future s/w builds. in particular, see the use-serial option. this is already in use by Scratch, for access to USB serial modules. (i assume you module is a serial device, given its uucp ownership.) we really need to figure out how to make this problem more painless. it came up the other day in the context of a new Lego peripheral that's been integrated with Scratch. in this case the peripheral appears as a HID device, and it's a bigger leap to simply make all HID devices accessible to any user. paul Just in case, the device our activity is trying to access is /dev/ttyACM0 Using ls -l /dev/ttyACM0 we see that the its access permission is uucp while the group of our activity is olpc. Using chmod o=rw /dev/ttyACM0 solves the problem. Thanks again ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: libertas vs. suspend (was: [IAEP] F11-0.88 os260py)
sascha wrote: Excerpts from Bernie Innocenti's message of Fri Jun 18 03:26:56 + 2010: * Disconnects from network on power save. This is a long-standing kernel bug. In 0.84, we fixed it by disabling power management. I'm not sure what you're seeing is really a kernel bug (unless you don't ship the latest OLPC kernel). It works fine for me even across several hundred suspend/resume cycles (it gets woken about once per 1-2 minutes by IGMP queries from the AP), though this is with an otherwise unused WLAN, so rekeyings are infrequent. And rekeyings might be exactly what's causing you trouble: According to Dan Williams, the libertas chip doesn't wake us for these [1]. I haven't had time to verify that yet. Upgrading to the latest NetworkManager version might also improve things a lot. sascha confirmed on IRC that the above refers to XO-1.5 (and is good news on that front, of course). but bernie's referring to XO-1 behavior. i've been looking at the XO-1 issues recently, and my progress has been investigative, without a lot of actual discovery. :-) i think there are several issues, at least a couple of which have to do with races between suspend/resume and other driver activity. (e.g. #10176) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F11-0.88 os260py
noiseehc wrote: I have just installed it onto my XO-1 (C1 model with the old style touchpad) without anything plugged into it. It seems to work but the suspend/resume is interesting. you're referring to automatic suspend, in the presence of wireless? i think bernie understated this bug in the release notes. the wlan driver on the 2.6.31 OLPC kernels is very broken right now. your symptoms don't shock me. (though i've never tried the rotate button when the system has hung.) (if, on the other hand, you have automatic suspend disabled, then perhaps something else is going on.) paul Sometimes it goes to suspend but after that I cannot wake it up except with the screen rotation button. I press the button and the XO draws a lot of rotated images (10-20) and then it stops. After this I can wake up the laptop when it suspends again by the touchpad or keyboard. What is interesting is that sometimes when it wakes up the screen backlight dims for a fraction of the second. Is it the normal behavior? I mean it seems that the hardware suspended before the backlight could be dimmed. What is the expected behavior? Another strange thing is that when I use Read to read a pdf file and rotate the screen 90 degree then the top of the screen (toolbar) gets black or garbage and when I move the mouse cursor over that area it redraws the toolbar with some garbage. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 HS version announced
tiago wrote: Hi, Will you be keeping that arrow key arrangement or is it still a prototype? that's the final arrangement. paul Best regards, Tiago On Tue, Jun 15, 2010 at 7:41 AM, John Watlington w...@laptop.org wrote: As usual, by a random news outlet: http://news.bbc.co.uk/2/hi/technology/10309116.stm These laptops are the XO-1.5 motherboard, but with a non-membrane keyboard. Thanks to Walter Bender for the layout, visible at: http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard The exciting news, for those who have been working with the traditional XO, is that we've redesigned the lower half to make the keyboard easy to remove for repair. We will phase this in across all XO laptops as tooling allows. The color scheme of the HS laptops will be dark/light blue. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 HS version announced
tiago wrote: From previous e-mails I know there were some challenges fitting the default layout but I'm still kind of surprised that it's become final. Best of luck with deployments and do give some feedback from deployments if possible. I personally wouldn't look twice at a laptop with a keyboard like that but I'm curious to see the real world feedback. it's certainly not perfect. the fact is that in a netbook-sized keyboard there isn't room to put all of the letters and punctuation and everything else in their proper places. paul Best regards, Tiago On Tue, Jun 15, 2010 at 3:29 PM, Paul Fox p...@laptop.org wrote: tiago wrote: Hi, Will you be keeping that arrow key arrangement or is it still a prototype? that's the final arrangement. paul Best regards, Tiago On Tue, Jun 15, 2010 at 7:41 AM, John Watlington w...@laptop.org wrote: As usual, by a random news outlet: http://news.bbc.co.uk/2/hi/technology/10309116.stm These laptops are the XO-1.5 motherboard, but with a non-membrane keyboard. Thanks to Walter Bender for the layout, visible at: http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard The exciting news, for those who have been working with the traditional XO, is that we've redesigned the lower half to make the keyboard easy to remove for repair. We will phase this in across all XO laptops as tooling allows. The color scheme of the HS laptops will be dark/light blue. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Anyone playing with Ubuntu on XO-1.5?
martin wrote: On Mon, Jun 14, 2010 at 12:06 PM, Martin Langhoff martin.langh...@gmail.com wrote: Curious minds want to know... Have you installed, or tried to install vanilla(ish) Ubuntu on an XO-1.5? If yes, which version? What install process? Did it work? Drivers missing our outdated? Did you have to grab custom packages? (which ones?) Interesting notes about Sugar. I was thinking more practically of vanilla ubuntu. Does it boot (given an appropriate olpc.fth? How are we with kernel drivers? xorg? Sound? Wlan? it would have to run our kernel -- or, at least, a rebuilt ubuntu kernel that included our drivers. a lot of work was done for ubuntu on XO-1. much of that work might be applicable as well. i don't have a link handy, i'm afraid. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] F11-for-XO1.5 Release 10.1.1 Release Candidate 2
bert wrote: On 14.06.2010, at 03:47, James Cameron wrote: On Sun, Jun 13, 2010 at 05:32:12PM +0200, Bert Freudenberg wrote: Installed on my 1.5 after updating the firmware to q3a39. Typing boot in OFW right after fs-update froze the machine. Unpredictable behaviour is known to occur if you try to boot after fs-update, you should use bye. Ah, okay. But that shouldn't have done permanent damage, right? Should I reflash? Powered off (long-press on power button) and booted. Let it sit idle for a while in the first-time Sugar screen (name dialog) - machine froze. It should idle suspend. It should not freeze. It does idle suspend. When the LED starts blinking and I touch the pad it wakes up fine. Just when I come back after some time of idling, it doesn't wake up anymore. The freeze happens sometimes with the screen still lit, sometimes after it turned off. However, after letting the machine sit idle for a while (even just after booting, still in the Sugar home screen), the whole machine froze. Power LED was still on. Had to power-cycle. Does not happen all the time, but twice already. Maybe it's my machine (one of the first C-test ones)? Sounds bad. Do you have a serial port attached? I ask because I suspect a kernel panic and a serial port is a practical way to obtain more problem data. No, I don't have one. the next best thing to having a serial port is to edit /etc/rsyslog.conf, and change the destination of all the logs from /var/log to somewhere nonvolatile, like /home/olpc/log (be sure to create the directory). then either reboot, or killall -HUP rsyslogd to make the config change take effect. this might give some information on what was going on before the hang. paul Might also be worth running memtest from OFW as well, just to exclude certain other causes. Ran memtest (from 30m up as Richard suggested), passed, no errors. I also took out the battery to make sure everything is reset. Still freezes when I let it sit long enough. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Am now getting a zero dot hang on my XO-1.5
mikus wrote: Upgraded os125 to kernel 2.6.31_xo1.5-20100607.1740.1.olpc.ead3d3e.i586 Now, whenever I boot, right after the line Loading ramdisk image from /pci/s...@c/d...@1:\boot/initrd.img ... I get the message General Protection Exception - and the boot hangs. The bypass is to do a complete reset (pull AC and battery for a bit), and only then try the boot -- now the boot proceeds normally. The problem is consistently repeatable. I did not have the problew when booting os125 with its original (month-old) kernel. XO-1.5 B2. Q3A39C. so, what's the sequence for repeating? once you clear the problem, how do you make it happen again? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reason for the one dot hang found!
daniel wrote: On 10 June 2010 18:32, Bernie Innocenti ber...@codewiz.org wrote: It's the camera controller. Hence, the other module being loaded must be cafe_ccic. Looking at the initialization of cafe_ccic, there seems to be a complicated dance of mutexes and spin locks, plus a kernel thread and a bunch of sleeps. All the ingredients for a good deadlock are present :-) I doubt it is directly related to locking. If (as you say) there is no crash in the logs then I suspect it is related to an infinite loop within the initialization code. And this all seems very familiar. Google for a thread titled cafe_ccic/ov7670 hang on boot from the 8.2 days. I suspect we never fixed that bug upstream and that same commit needs to be reverted from the new kernel. good catch, good call. commit 8815ea29a9bcbab2a3c7fbc28987cac67c2c41d0 is a revert for 6d77444aca298b43a88086be446f943cd0442ef7, and is present in the testing branch (i.e., XO-1 802 and earlier), but not in our current 2.6.31 branch. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reason for the one dot hang found!
i forgot to give the link to the thread daniel refers to: http://lists.laptop.org/pipermail/devel/2008-June/thread.html#15432 i'm afraid there's not much to be drawn from there in the way of conclusions, though. paul paul wrote: daniel wrote: On 10 June 2010 18:32, Bernie Innocenti ber...@codewiz.org wrote: It's the camera controller. Hence, the other module being loaded must be cafe_ccic. Looking at the initialization of cafe_ccic, there seems to be a complicated dance of mutexes and spin locks, plus a kernel thread and a bunch of sleeps. All the ingredients for a good deadlock are present :-) I doubt it is directly related to locking. If (as you say) there is no crash in the logs then I suspect it is related to an infinite loop within the initialization code. And this all seems very familiar. Google for a thread titled cafe_ccic/ov7670 hang on boot from the 8.2 days. I suspect we never fixed that bug upstream and that same commit needs to be reverted from the new kernel. good catch, good call. commit 8815ea29a9bcbab2a3c7fbc28987cac67c2c41d0 is a revert for 6d77444aca298b43a88086be446f943cd0442ef7, and is present in the testing branch (i.e., XO-1 802 and earlier), but not in our current 2.6.31 branch. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
john wrote: I looked at the kernel patch for emulating the missing instruction (long NOP). It looks like it works, and only needs minor patching-up for security enforcement. The big argument on the Linux kernel list was about not having a little kludge like this, which is likely to grow to emulate many other things and become unmaintainable; some people would rather use the whole virtual-CPU emulation mechanism for this, which is much more heavyweight, but also a lot easier to test and validate. If having to maintain a 20- or 50-line kernel patch is the price of being able to move forward onto using unmodified modern Fedora release repositories, I'd say the choice for OLPC is very clear - do it. The change that introduced the use of this instruction was in the binutils (assembler) rather than in gcc. I believe it is used when a .align directive is given in an executable segment. When optimizing, GCC has been aligning some loops on cache line boundaries for some time (by inserting nop padding BEFORE the loop), but previously, the assembler was filling with various N-byte NOPs that would work on any x86. It has been improved to pick faster ones on modern hardware. there's a wonderful irony in that, given all of the performance issues our laptops face, our big worry this week is the cost of doing nothing at all. :-) i agree with john -- we should definitely try the kernel emulation, and try and gather some statistics on how often it fires, or other easy metric. i'll bet the cost is low. paul The relevant code is in gas/config/tc-i386.c, function i386_align_code(). I haven't pinned down the actual code change that bit us, and perhaps it's just the change in -march and/or -mtune options used by Fedora when calling gcc. Gas is careful to only use NOPs that are compatible with the specified instruction set, if one is specified -- but Fedora is specifying the wrong one for our purposes. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Flash,Gnash,AIR: which builds to test against?
carlos wrote: Hi guys! There's a number of different builds up on the OLPC pages right now: * OLPC 802 (Sugar 0.84) * OLPC F11 - OS11 * Paraguay F11 + Sugar 0.88 * Sugar Labs F11 OS11-OS15 For the purposes of keeping the Flash Platform wikis updated, which are the snapshots I should use for long-term testing of Flash, Gnash AIR? Should I still test against 802 or should I just test against the Paraguay build? I have 2 XO-1s I can do testing on, with a third one is on loan to a Phlashers teammate who's also doing some testing. i think the paraguay build, which is based on F11, represents the future. while martin has an 802 point release in progress, i think it's pretty much done, and he's unlikely to take any more changes to it (but he'll correct me if i'm wrong, i'm sure). the released 802 might be interesting as a baseline, but not much more, i'd think. paul We're going to install Adobe Flash on 2 of the Machines and Gnash on the 3rd machine. Which OS builds should we install on the 3 machines given the above configurations? I'm thinking 802 + Adobe Flash, F11 Paraguay + Adobe Flash, F11 Paraguay + Gnash. Are these the optimal configuations we can test against for the purposes of reporting back results on the wikis given 3 XO-1 machines? We'll be using latest stable builds of Flash, Gnash AIR. Regards, -Naz -- carlos nazareno http://twitter.com/object404 http://www.object404.com -- core team member phlashers: philippine flash actionscripters http://www.phlashers.com -- poverty is violence ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: create new XO-1 build with Gnash update?
james wrote: On Sun, Jun 06, 2010 at 04:24:39AM +0800, Carlos Nazareno wrote: I installed the Paraguay build about a month ago but there were still some bugs. http://people.sugarlabs.org/~smparrish/ - That's the one, right? No. http://people.sugarlabs.org/bernie/olpc/f11-xo1-py/ has the XO-1 official builds released by the Paraguay Educa technology team. os180py is the latest I see there at this time, dated 4th May. It contained (as did os129 of 7th April): there are later releases (0.88 on F11) linked to from here: http://wiki.sugarlabs.org/go/Deployment_Team/Sugar-0.88_Notes (but they're not official, nor signed.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
