Re: ANNOUNCE: F11 for the XO-1 build 140py released
--- On Thu, 4/15/10, Bernie Innocenti wrote: > From: Bernie Innocenti > Subject: Re: ANNOUNCE: F11 for the XO-1 build 140py released > To: "Paul Fox" > Cc: "Yioryos Asprobounitis" , "OLPC Devel" > , "Fedora OLPC List" > Date: Thursday, April 15, 2010, 8:33 PM > On Thu, 2010-04-15 at 09:01 -0400, > Paul Fox wrote: > > and -- question for bernie -- does os140py include a > new firmware? > > Yes, it includes q2e42d. It works on all our laptops, and > smbios is > enabled. > > Yioryos, did you have AC plugged in when you flashed your > laptop? Yes. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Local software installation
On Thu, Apr 15, 2010 at 3:35 PM, Bernie Innocenti wrote: > On Thu, 2010-04-15 at 14:48 -0400, Bernie Innocenti wrote: > >> For a future release cycle, we may want to re-evaluate yum-updatesd as >> an alternative to olpc-updates which provides different trade-offs in >> terms of performance, robustness and distro integration. At the time >> olpc-update was written, yum was still awfully buggy and unreliable. This wasn't why olpc-update was designed differently than yum. At litl we use an apt-based distro. We still have a whole-system update tool. I believe it to be a fundamental mistake to confuse package-based update tools with image-based update tools. Which is entirely orthogonal to the "local package installation" question -- but I couldn't let you get so far off track in your second sentence. Let's keep our terminology straight: "image updater", "root-only package updater", and "local user package updater". These are three different tasks, and could easily be three separate tools, for three different use cases. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
On Thu, 2010-04-15 at 09:01 -0400, Paul Fox wrote: > and -- question for bernie -- does os140py include a new firmware? Yes, it includes q2e42d. It works on all our laptops, and smbios is enabled. Yioryos, did you have AC plugged in when you flashed your laptop? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On 15 April 2010 15:48, Bernie Innocenti wrote: > I noticed that Stephen Parrish had removed olpc-update from F11-XO1, > which made /versions also superfluous. Besides the nice saving in space, > disabling the versioned fs considerably sped up olpc-os-builder. I'd be surprised if there is any significant saving of space. As for build time, that would also surprise me but I'm not so familiar with the technicalities of mkfs.jffs2 - perhaps it does take a lot longer for lots of links. > Hmmm... perhaps I should reconsider this decision. We'd first have to do > some testing to ensure your original work still works well with F11-XO1. > > Last time I looked, the hostname of the update server was hardcoded > inside olpc-update. Did you create a custom package to point it at the > schoolserver? olpc-update-query is the component in question. You need to point it at the mothership like was done in the 801 image, not the school server. If there is an update available, the mothership will ask olpc-update-query to run olpc-update using rsync from the local school server. The new olpc-update-query version will look on the school server first, then a server configured in /etc. (make sure you're using olpc-update-2.22 then you can use the oats_cfg module of olpc-os-builder for this configuration). There is also the option to make it bypass the school server and use the other one directly -- thats what I'd suggest for Paraguay. Regardless of whether you use the updates bit or not, you'll want to reinstate that server configuration so that the laptops can receive lease updates before expiration (Raul told me that they have switched this feature on a while back when school holidays were approaching). > For a future release cycle, we may want to re-evaluate yum-updatesd as > an alternative to olpc-updates which provides different trade-offs in > terms of performance, robustness and distro integration. At the time > olpc-update was written, yum was still awfully buggy and unreliable. I agree with the idea of using a more standard system, but I'd say that yum is not yet a suitable replacement based on a discussion that I started based on this exact question in the beginning of the XO-1.5 development cycle. It's in the archives. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Incidentally, I think it's important to distinguish between "palm detection" and "tap to click". In my experience, most users who are used to tap to click, expect it -- and get frustrated when it doesn't work. On the other hand, I've been using a litl webbook with tap to click enabled since leaving OLPC -- and I can't say I've *ever* had it click when I didn't mean to. The tap gesture just doesn't occur accidentally. But we *do* have the palm-detection turned on, which prevents the "I accidentally brushed the touchpad while typing" behavior, which seems to be the real cause of most of the complaints. In any case, discussion would be more constructive if participants were careful to use the proper terminology --- "tap to click" and "palm detection" -- and carefully distinguish which they like/dislike in their comments. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
illusion (Re: tap-to-click feedback)
Dear Edd, Ed McNierney escribió: > Tuukaa - Thanks for your prompt reply, although it doesn't address the points of our report. We'd appreciate another one that did. Meanwhile, your reply demonstrates more general problems in the OLPC project, which would be worth solving as well. > I don't quite see how you can make statements like "the OLPC project > is not in close contact with the field". How do you know that? We *do* > get many reports from deployment teams that represent hundreds of > thousands of children, and try to collect and communicate that feedback > effectively. In fact, I'm going to meet with the head of one of them in > 15 minutes. To answer your first question, you can read and quote what we wrote: >> It's very easy to tell: the OLPC project is not in close contact with >> the field. In this thread, we can observe the illusion that the >> hundreds of thousands of children would report to you if there was >> something suboptimal with their laptops. And there have been multiple >> reports, and yet "there is no consensus". Key word: illusion. Further, the deployment teams *cannot* represent the children. They should strive to, but there is no substitute for going out on the field and seeing with your own trained eyes. We also suggest you reconsider what level of indirection in an organizational hierarchy you call "close". > There have actually been very few reports of problems with this > touchpad behavior. We don't know why that is, and I don't think you do, > either - although we can both speculate all day and fill the list > archives. We do get plenty of reports of other problems, so I don't > think there's a fundamental failure in our ability to get input from the > field. We can always hope to do better, of course. We can't be sure and we could discuss, but we start to get the feeling that we do have a better idea than you do, and yet you're not willing to present your side and discuss. > Having a small number of users on the devel list report their own > personal experiences and preferences just isn't helpful in determining > what the best course would be. Offering a configuration option would be > nice, although we would still need to know how to advise deployments on > which default to choose. If it wasn't clear, we weren't reporting our personal experiences or preferences. > The device in question is a standard Synaptics touchpad, which comes > configured in tap-to-click mode by default. It's used in plenty of other > laptop machines. Surely that's at least circumstantial evidence that > this behavior isn't universally despised. Used in laptops for use by unprivileged kids in developing countries, or in laptops irrelevant to this discussion?-) > As for your assertion that the problems with the old-style touchpad > are less important than this problem, there are those in the field who > would most firmly disagree with you. That's one bit of evidence as to > why I think a shouting match on the devel list is a rather unhelpful way > to approach a solution. We weren't shouting, were we? We were giving you a direct report from the field as a response to the call for "seeking consensus". Of course the list can only take it as one piece of evidence, but you act as if there still was no evidence. If you have some towards the opposite conclusion, please share. > We have a globally-accessible, open, trouble-reporting database at > http://dev.laptop.org - have you reported this problem? Has anyone else > reported this problem? Searches for "tap-to-click" and "Synaptics" > return a few tickets reporting various items, and one from Martin > Langhoff (#9775) mentioning the ability to disable tap-to-click. But > please don't claim we're not listening if you aren't willing to use the > public trouble-reporting system we rely on. "Globally-accessible". We might say "Internet-enabled". Do you appreciate the fact that Internet access is a scarcity in the developing world? We haven't engaged here before, and maybe we still shouldn't have. All your message is about how you shouldn't ask the children but they should report to you (as if!), yet when we take our time from helping the kids and their teachers and try to do our best in communicating their situation to improve it, even that's not enough to you. We suppose you'd rather this big issue was buried in Trac. If you re-read our message, we mention some imperfections in how this issue has been handled from the beginning in the OLPC project. Please take them as a suggestion on how to improve your organisation for the future, as well as on what to do to fix the current issue. Yes, there's something *you* could do! > - Ed Sincerely, Tuukka and Kaisa > On Apr 15, 2010, at 1:24 PM, Tuukka Hastrup wrote: > >> Hi everyone, >> >> Ed McNierney escribió: >>> No, you're quite right - it's hard. And it's hard to tell whether most >>> users are silent because they're happy with it, or they're silent >>>
Re: tap-to-click feedback
Hi everyone, Ed McNierney escribió: > No, you're quite right - it's hard. And it's hard to tell whether most > users are silent because they're happy with it, or they're silent > because they don't even realize that they have a choice. It's very easy to tell: the OLPC project is not in close contact with the field. In this thread, we can observe the illusion that the hundreds of thousands of children would report to you if there was something suboptimal with their laptops. And there have been multiple reports, and yet "there is no consensus". 0. Of course the kids don't realise that they have a choice. 1. They can't write (a letter). 1. They don't have Internet. 2. They don't speak English and the web sites are in English. 3. Even western kids don't know their feedback counts or how to send it. 4. Same applies to teachers and most other people on the field. We'd really like to see a *memo* about the *decision* that was made to change the default functioning of the touchpad to tap-to-click! Someone recognized the change in time, someone didn't assign enough importance to it to fix it in time. Others haven't documented this problem so that it could be evaluated, reassessed, and fixed at some point. Now, "there is no consensus" even, although the issue is obvious. We didn't know about this before we assisted in a training week for the teachers in Satipo, where we saw that some machines had the new-style touchpads and the teachers were having problems with those. Despite all our explanations, many weren't able to learn to avoid the unintended clicks during the 40 hours of training. This means a lot of the only training they got was wasted. To us it seems obvious that tap-to-click is a bad idea on the XO: It's a complication. It's not very useful to anyone (as you can always click the button instead...). It's very harmful to some (as it makes the functioning of the mouse unpredictable). Did you first make sure that all mouse clicks in all software and all web sites are well-visualised and undo-able ?-) In these third-world conditions, reliability is far more important than small performance tweaks. We all know there's big problems with the old-style touchpads as well, but they are *less* important on the field. Why? Because the child with sweaty hands (try to avoid that here in the tropics!) can keep trying to point the mouse at the correct location until successful, *then* click the *button* and be done. With tap-to-click they aren't able to do this, and there's no solution for them, is there? Without an Internet connection and the knowledge on how and whom to contact, there's no-one listening to them. Greetings from Pucallpa, Tuukka and Kaisa > - Ed > > On Apr 15, 2010, at 11:42 AM, Sebastian Silva wrote: > >> Hi Ed, >> Our friends and volunteers Tuukka and Kaisa are currently in Pucallpa >> working >> with the teachers and kids. They probably havent seen this thread but >> this issue >> has popped up often here too and I wonder what you might think constitutes >> "consensus from deployments". >> >> Also, the larger issue of how to get the "silent majority" to speak up >> is something >> we are constantly working hard from the field to improve. Its hard, >> any suggestions >> on where exactly to aggregate info from the field, in a way that is >> not merely >> anecdotal, is welcome. >> >> Sebastian >> >> 2010/4/15 Ed McNierney mailto:e...@laptop.org>> >> >> Paul - >> >> This issue has bubbled up from time to time over the last 18 >> months or so (judging from my email archives). It is not at all >> clear to me that there is indeed a "consensus from deployments"; >> some like it, some don't. We tend to (unsurprisingly) hear little >> or nothing from the people who think it's working just fine, and >> it is very easy for a local group in which a few folks think the >> behavior is wrong to quickly collectively conclude that it's >> wrong. We've deployed hundreds of thousands of machines since >> this change, and I don't think we've seen hundreds of thousands of >> complaints. >> >> I don't have a strong opinion and I don't know the answer, but we >> should be very careful about ignoring the silent majority, if >> there is one. >> >>- Ed >> >> >> On Apr 15, 2010, at 11:18 AM, Paul Fox wrote: >> >> > daniel wrote: >> >> On 15 April 2010 11:40, Martin Langhoff >> mailto:martin.langh...@gmail.com>> wrote: >> >>> On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva >> >>> mailto:sebast...@fuentelibre.org>> >> wrote: >> BTW how do you disable it? >> >>> >> >>> Yeah -- can we disable it easily on F11 builds? >> >> >> >> (speaking only for XO) No. We would have to change mouse driver >> which >> >> introduces a handful of regressions, will need some real effort to >> >> resolve. See the discussions earlier in the thread. >> >> >> >>
Re: tap-to-click feedback
On Thu, Apr 15, 2010 at 10:54 AM, Daniel Drake wrote: > On 15 April 2010 11:40, Martin Langhoff wrote: >> On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva >> wrote: >>> BTW how do you disable it? >> >> Yeah -- can we disable it easily on F11 builds? > > (speaking only for XO) No. We would have to change mouse driver which > introduces a handful of regressions, will need some real effort to > resolve. See the discussions earlier in the thread. > > The most realistic quick-fix option I can think of is adding a small > hack into the psmouse driver in the OLPC kernel, which sends the > single command needed to disable tap-to-click. Last time I looked at > this code I remember thinking that this would be quite easy, since the > more-powerful synaptics driver doesn't actually change the mode of the > mouse, it just takes advantage of a whole load of non-standard > commands. See http://cscott.net/Projects/Synaptics/ Enjoy! --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: illusion (Re: tap-to-click feedback)
Hello OLPC! Glad to have your attention! Now while we do, it might be a good time to discuss ways to improve the way we can provide feedback. Please don't let our past and constant frustration with OLPC taint the very fact that we are volunteers trying to help OLPC's mission. It is no secret that OLPC has had trouble getting feedback from the field in Peru from the official "deployment team". Its understandable that you cannot be in the field with us. But we are here for you, so please, when we do provide feedback, with all the difficulties that this entails in our circumstances, do not act as if we're personally attacking you. This would be a good start. > "We *do* > get many reports from deployment teams that represent hundreds of > thousands of children, and try to collect and communicate that feedback > effectively. In fact, I'm going to meet with the head of one of them in > 15 minutes." I would have problems with this statement on so many levels, its practically impossible for me to answer constructively. The problem is, at least here, that these "heads of deployment teams" fail to "represent", or even listen to us, in the field, much like you do, to whom shall we direct our concerns? > We do get plenty of reports of other problems, so I don't > think there's a fundamental failure in our ability to get input from the > field. We can always hope to do better, of course. The feedback that you do get, is too little, too late. We are reporting now, and provide you with a window of oportunity to actually look at the field. If you do care, maybe you could use the oportunity to ask more questions? We would be more than happy to try to answer them. Please consider this, when you actually act on your hope. -- Sebastian Silva ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
On Wed, 2010-04-14 at 17:54 -0500, Mikus Grinbergs wrote: > I usually bring the system up with messages being displayed (NOT in > pretty-boot). Several times now, the system has "paused/hung" at about > the time it should be running through /etc/rc.d/rc0.d (or suchlike). > [Note: the camera LED is on.] After SEVERAL MINUTES nothing more has > happened - so I just reboot. [I can not bring up a text console, so I > can't take a dump.] The hang is random - so the next boot usually works. > > As far as I am concerned, if the machines in the field also encounter > this hang -- it is a blocker to the release of build 140py. I have observed this problem a couple of times, although only after reflashing the OS. The machine would hang after displaying the frame of the boot animation with just one dot. In my case, a simple reboot would not cure the problem. Pulling the battery did the job. Therefore, I suspect it may be caused by upgrading the EC code, which wouldn't be a big concern since we have found an easy workaround. Let me know if you see it again on laptops that are already running the latest open firmware code. Please, take note of how you triggered it and how exactly you managed to solve it. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Local software installation
On Thu, 2010-04-15 at 14:48 -0400, Bernie Innocenti wrote: > For a future release cycle, we may want to re-evaluate yum-updatesd as > an alternative to olpc-updates which provides different trade-offs in > terms of performance, robustness and distro integration. At the time > olpc-update was written, yum was still awfully buggy and unreliable. This brings up again an old question: is the installation of additional packages something we support and encourage? In the past, we could get along with a straight answer: "no". (although some exceptions were made for things such as Adobe Flash). Now that we're shipping Gnome alongside Sugar, both environments obviously need a mechanism for software installation. Even though we provide no package management GUI in Gnome, children of Caacupé have already learned how to use yum from the terminal. Shall we remove it, making things a little harder? I bet they'll quickly figure out a workaround. The most effective way to prevent local software installation would consist in taking away root privileges from users, thus violating OLPC's first principle. There's an immense benefit in unleashing the immense software library provided by any Linux distro, enough to counter-balance the concern of some adventurous users breaking their systems in some clever way. There's no damage that couldn't be restored by the quick remedy of reflashing the OS. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: illusion (Re: tap-to-click feedback)
tuukka wrote: > > Further, the deployment teams *cannot* represent the children. They > should strive to, but there is no substitute for going out on the field > and seeing with your own trained eyes. while your point is well taken, the fact remains that no one but the deployment teams is in a position to represent the children. i'm not sure how big an organization you imagine OLPC to be, but it's not nearly big enough to spend enough time in the field to allow replacing feedback from the deployment teams. (which isn't to say that we don't make field visits. we do.) > > There have actually been very few reports of problems with this > > touchpad behavior. We don't know why that is, and I don't think you do, > > either - although we can both speculate all day and fill the list > > archives. We do get plenty of reports of other problems, so I don't > > think there's a fundamental failure in our ability to get input from the > > field. We can always hope to do better, of course. > > We can't be sure and we could discuss, but we start to get the feeling > that we do have a better idea than you do, and yet you're not willing to > present your side and discuss. let's remember that this conversation started with a discussion of how we might go about changing the tap-to-click behavior. again, OLPC has limited resources, and we certainly don't want to make mistakes in applying them. it would be a real shame if we went to the effort of removing tap-to-click only to find that there was a large group of users that was perfectly happy with it, and who, in fact, like it. my personal opinion is that the existence of such a group is unlikely, but ed is right to say that we should be sure. > We haven't engaged here before, and maybe we still shouldn't have. All on the contrary -- we of course welcome your (constructive) suggestions, and, in this case, your feedback directly from the field. the system (such as it is) seems to be working. > If you re-read our message, we mention some imperfections in how this > issue has been handled from the beginning in the OLPC project. Please truly, in terms of mistakes made by OLPC, this one is probably pretty low on the severity list. richard has addressed this, but in case it wasn't clear: the touchpad hardware change was partially involuntary on the part of OLPC -- it was largely due to a supplier issue, but it had the side-effect of eliminating the huge issues we were having with the previous pad. the new h/w happened to coincide with a major s/w release -- in fact, i believe that it turned out to be the last major s/w release OLPC did for the XO-1. at the time, enabling the synaptics driver in the kernel (which would have let us disable tap-to-click) caused other problems which were far, far worse, so we decided not to do so. this seemed reasonable since the _only_ downside of not doing so was the tap-to-click issue. given the huge problems we'd been having (and still have!) with the previous touchpad, i think tap-to-click seemed very minor by comparison. in any case, i guess we should put your votes in the "please disable it" column. thanks for letting us know. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
Daniel wrote: > Ithas only a 15mb overhead. When I type in 'du -x', on os13 it shows me /versions having around 100 MB. On os140py the same command shows nothing for /versions. [The remaining high-level directories (except for /home) have comparable sizes on those two builds.] I do not know how much of what is in /versions gets "counted more than once" (because of all those hard links between pristine and the running system) -- but I'm not convinced the overhead of /versions is only 15 MB. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
On 04/15/2010 01:52 PM, Ed McNierney wrote: >> We'd really like to see a *memo* about the *decision* that was made >> to change the default functioning of the touchpad to tap-to-click! >> Someone recognized the change in time, someone didn't assign enough >> importance to it to fix it in time. I did. Please re-read my previous email. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On Wed, 2010-04-14 at 19:35 -0300, Daniel Drake wrote: > On 14 April 2010 13:22, Bernie Innocenti wrote: > > * Remove olpc-update and disable the /versions kludge (me, smparrish) > > Great work Bernie! > This is the only bit that seems a bit surprising to me. I noticed that Stephen Parrish had removed olpc-update from F11-XO1, which made /versions also superfluous. Besides the nice saving in space, disabling the versioned fs considerably sped up olpc-os-builder. > Granted, the /versions system is a little perplexing (but it works, > and is being shipped on XO-1.5, so it has good support in the present > day). And granted, it doesn't work for large substantial updates, and > doesn't update activities. > > But it is a nice system for small updates, with fairly good > documentation. It has only a 15mb overhead. I also set up all the > infrastructure in Paraguay to push these to schools and XOs > automatically, and we actually rolled out a tiny update in 1 school to > test it (worked perfectly first time). And I documented it. > > Being the first deployment to run with this substantial software > update, it seems somewhat likely that you'll find a few niggly bugs > that would be nice to fix in the coming weeks. olpc-update would > provide you with a mechanism to do that with minimal effort. Hmmm... perhaps I should reconsider this decision. We'd first have to do some testing to ensure your original work still works well with F11-XO1. Last time I looked, the hostname of the update server was hardcoded inside olpc-update. Did you create a custom package to point it at the schoolserver? For a future release cycle, we may want to re-evaluate yum-updatesd as an alternative to olpc-updates which provides different trade-offs in terms of performance, robustness and distro integration. At the time olpc-update was written, yum was still awfully buggy and unreliable. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Tuukaa - I don't quite see how you can make statements like "the OLPC project is not in close contact with the field". How do you know that? We *do* get many reports from deployment teams that represent hundreds of thousands of children, and try to collect and communicate that feedback effectively. In fact, I'm going to meet with the head of one of them in 15 minutes. There have actually been very few reports of problems with this touchpad behavior. We don't know why that is, and I don't think you do, either - although we can both speculate all day and fill the list archives. We do get plenty of reports of other problems, so I don't think there's a fundamental failure in our ability to get input from the field. We can always hope to do better, of course. Having a small number of users on the devel list report their own personal experiences and preferences just isn't helpful in determining what the best course would be. Offering a configuration option would be nice, although we would still need to know how to advise deployments on which default to choose. The device in question is a standard Synaptics touchpad, which comes configured in tap-to-click mode by default. It's used in plenty of other laptop machines. Surely that's at least circumstantial evidence that this behavior isn't universally despised. As for your assertion that the problems with the old-style touchpad are less important than this problem, there are those in the field who would most firmly disagree with you. That's one bit of evidence as to why I think a shouting match on the devel list is a rather unhelpful way to approach a solution. We have a globally-accessible, open, trouble-reporting database at http://dev.laptop.org - have you reported this problem? Has anyone else reported this problem? Searches for "tap-to-click" and "Synaptics" return a few tickets reporting various items, and one from Martin Langhoff (#9775) mentioning the ability to disable tap-to-click.But please don't claim we're not listening if you aren't willing to use the public trouble-reporting system we rely on. - Ed On Apr 15, 2010, at 1:24 PM, Tuukka Hastrup wrote: > > Hi everyone, > > Ed McNierney escribió: > > No, you're quite right - it's hard. And it's hard to tell whether most > > users are silent because they're happy with it, or they're silent > > because they don't even realize that they have a choice. > > It's very easy to tell: the OLPC project is not in close contact with the > field. In this thread, we can observe the illusion that the hundreds of > thousands of children would report to you if there was something suboptimal > with their laptops. And there have been multiple reports, and yet "there is > no consensus". > > 0. Of course the kids don't realise that they have a choice. > 1. They can't write (a letter). > 1. They don't have Internet. > 2. They don't speak English and the web sites are in English. > 3. Even western kids don't know their feedback counts or how to send it. > 4. Same applies to teachers and most other people on the field. > > We'd really like to see a *memo* about the *decision* that was made to change > the default functioning of the touchpad to tap-to-click! Someone recognized > the change in time, someone didn't assign enough importance to it to fix it > in time. Others haven't documented this problem so that it could be > evaluated, reassessed, and fixed at some point. Now, "there is no consensus" > even, although the issue is obvious. > > We didn't know about this before we assisted in a training week for the > teachers in Satipo, where we saw that some machines had the new-style > touchpads and the teachers were having problems with those. Despite all our > explanations, many weren't able to learn to avoid the unintended clicks > during the 40 hours of training. This means a lot of the only training they > got was wasted. > > To us it seems obvious that tap-to-click is a bad idea on the XO: It's a > complication. It's not very useful to anyone (as you can always click the > button instead...). It's very harmful to some (as it makes the functioning of > the mouse unpredictable). Did you first make sure that all mouse clicks in > all software and all web sites are well-visualised and undo-able ?-) In these > third-world conditions, reliability is far more important than small > performance tweaks. > > We all know there's big problems with the old-style touchpads as well, but > they are *less* important on the field. Why? Because the child with sweaty > hands (try to avoid that here in the tropics!) can keep trying to point the > mouse at the correct location until successful, *then* click the *button* and > be done. With tap-to-click they aren't able to do this, and there's no > solution for them, is there? Without an Internet connection and the knowledge > on how and whom to contact, there's no-one listening to them. > > > Greetings
Re: ANNOUNCE: F11 for the XO-1 build 140py released
On Wed, 2010-04-14 at 17:08 -0500, Mikus Grinbergs wrote: > Was unable to boot XO-1 with build140py installed on jffs2, unless > develop.sig was present. > > If not present, OFW (q2e42e) gave the message "No signature for our key > list" I think Stephen Parrish is preparing to release an F11-XO1 image signed with OLPC's private key. If deployments ask for it, I can provide instructions for creating OS images similar to ours, but signed with their private keys. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SOLVED Re: [IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
On Wed, 2010-04-14 at 15:50 -0500, Yamandu Ploskonka wrote: > Disabling the security system fixed it (?) > > http://wiki.laptop.org/go/Activation_and_Developer_Keys#Disable_the_security_system > > All Korrect now Indeed. Our images are signed with the local deployment key, so they need either one of our laptops, or an unlocked laptop. My apologies for not mentioning it in our release notes. > I'll go file bugs Thanks! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
On Thu, Apr 15, 2010 at 12:35 PM, Richard Smith wrote: > Who are the ones that like it? I don't remember any good feedback. +1 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
Re: tap-to-click feedback
Sebastian - No, you're quite right - it's hard. And it's hard to tell whether most users are silent because they're happy with it, or they're silent because they don't even realize that they have a choice. - Ed On Apr 15, 2010, at 11:42 AM, Sebastian Silva wrote: > Hi Ed, > Our friends and volunteers Tuukka and Kaisa are currently in Pucallpa working > with the teachers and kids. They probably havent seen this thread but this > issue > has popped up often here too and I wonder what you might think constitutes > "consensus from deployments". > > Also, the larger issue of how to get the "silent majority" to speak up is > something > we are constantly working hard from the field to improve. Its hard, any > suggestions > on where exactly to aggregate info from the field, in a way that is not merely > anecdotal, is welcome. > > Sebastian > > 2010/4/15 Ed McNierney > Paul - > > This issue has bubbled up from time to time over the last 18 months or so > (judging from my email archives). It is not at all clear to me that there is > indeed a "consensus from deployments"; some like it, some don't. We tend to > (unsurprisingly) hear little or nothing from the people who think it's > working just fine, and it is very easy for a local group in which a few folks > think the behavior is wrong to quickly collectively conclude that it's wrong. > We've deployed hundreds of thousands of machines since this change, and I > don't think we've seen hundreds of thousands of complaints. > > I don't have a strong opinion and I don't know the answer, but we should be > very careful about ignoring the silent majority, if there is one. > >- Ed > > > On Apr 15, 2010, at 11:18 AM, Paul Fox wrote: > > > daniel wrote: > >> On 15 April 2010 11:40, Martin Langhoff wrote: > >>> On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva > >>> wrote: > BTW how do you disable it? > >>> > >>> Yeah -- can we disable it easily on F11 builds? > >> > >> (speaking only for XO) No. We would have to change mouse driver which > >> introduces a handful of regressions, will need some real effort to > >> resolve. See the discussions earlier in the thread. > >> > >> The most realistic quick-fix option I can think of is adding a small > >> hack into the psmouse driver in the OLPC kernel, which sends the > >> single command needed to disable tap-to-click. Last time I looked at > >> this code I remember thinking that this would be quite easy, since the > >> more-powerful synaptics driver doesn't actually change the mode of the > >> mouse, it just takes advantage of a whole load of non-standard > >> commands. > > > > that's a good idea. > > > > if such a thing were to be introduced, and if it could be made > > run-time or boot-time controllable, i take it the consensus from > > deployments is that tap-to-click is more confusing than helpful, > > and it should be disabled by default. correct? > > > > (i know that i myself find it annoying. the XO is annoying > > enough to type on, without having my windows flip out from under > > me because i have careless thumbs.) > > > > paul > > =- > > paul fox, p...@laptop.org > > ___ > > 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 > > > > -- > Sebastian Silva > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Hi Ed, Our friends and volunteers Tuukka and Kaisa are currently in Pucallpa working with the teachers and kids. They probably havent seen this thread but this issue has popped up often here too and I wonder what you might think constitutes "consensus from deployments". Also, the larger issue of how to get the "silent majority" to speak up is something we are constantly working hard from the field to improve. Its hard, any suggestions on where exactly to aggregate info from the field, in a way that is not merely anecdotal, is welcome. Sebastian 2010/4/15 Ed McNierney > Paul - > > This issue has bubbled up from time to time over the last 18 months or so > (judging from my email archives). It is not at all clear to me that there > is indeed a "consensus from deployments"; some like it, some don't. We tend > to (unsurprisingly) hear little or nothing from the people who think it's > working just fine, and it is very easy for a local group in which a few > folks think the behavior is wrong to quickly collectively conclude that it's > wrong. We've deployed hundreds of thousands of machines since this change, > and I don't think we've seen hundreds of thousands of complaints. > > I don't have a strong opinion and I don't know the answer, but we should be > very careful about ignoring the silent majority, if there is one. > >- Ed > > > On Apr 15, 2010, at 11:18 AM, Paul Fox wrote: > > > daniel wrote: > >> On 15 April 2010 11:40, Martin Langhoff > wrote: > >>> On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva > >>> wrote: > BTW how do you disable it? > >>> > >>> Yeah -- can we disable it easily on F11 builds? > >> > >> (speaking only for XO) No. We would have to change mouse driver which > >> introduces a handful of regressions, will need some real effort to > >> resolve. See the discussions earlier in the thread. > >> > >> The most realistic quick-fix option I can think of is adding a small > >> hack into the psmouse driver in the OLPC kernel, which sends the > >> single command needed to disable tap-to-click. Last time I looked at > >> this code I remember thinking that this would be quite easy, since the > >> more-powerful synaptics driver doesn't actually change the mode of the > >> mouse, it just takes advantage of a whole load of non-standard > >> commands. > > > > that's a good idea. > > > > if such a thing were to be introduced, and if it could be made > > run-time or boot-time controllable, i take it the consensus from > > deployments is that tap-to-click is more confusing than helpful, > > and it should be disabled by default. correct? > > > > (i know that i myself find it annoying. the XO is annoying > > enough to type on, without having my windows flip out from under > > me because i have careless thumbs.) > > > > paul > > =- > > paul fox, p...@laptop.org > > ___ > > 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 > -- Sebastian Silva ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Richard - I have a specific recollection of folks in Rwanda "liking it". But my bigger concern is that we've shipped an awful lot of these with very few reported complaints. I just don't know what that means. It may well be that most folks don't like it, but I don't think we know. As they say in some courts of law, "Not Proven". We can certainly make an effort to inquire specifically about this and attempt to get good input from existing users. - Ed On Apr 15, 2010, at 11:35 AM, Richard Smith wrote: > On Thu, Apr 15, 2010 at 11:24 AM, Ed McNierney wrote: >> Paul - >> >> This issue has bubbled up from time to time over the last 18 months or so >> (judging from my email archives). It is not at all clear to me that there >> is indeed a "consensus from deployments"; some like it, some don't. > > Who are the ones that like it? I don't remember any good feedback. > >> We tend to (unsurprisingly) hear little or nothing from the people who >> think it's working just fine, and it is very easy for a local group in which >> a few folks think the behavior is wrong to quickly collectively conclude >> that it's wrong. We've deployed hundreds of thousands of machines since >> this change, and I don't think we've seen hundreds of thousands of >> complaints. > > When we first started testing the new pads this issues came up and > because it was a change in behavior from the way ALPS worked. I > remember the end result was to disable it. The problem is that its on > by default in the hardware. You have to turn it off. To turn it off > you have to run the synaptics driver. Running the synaptics driver > caused many regressions. We had too many other things to work on > rather than the synaptics driver so it shipped with it enabled. > > -- > Richard A. Smith ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
On Thu, Apr 15, 2010 at 11:24 AM, Ed McNierney wrote: > Paul - > > This issue has bubbled up from time to time over the last 18 months or so > (judging from my email archives). It is not at all clear to me that there is > indeed a "consensus from deployments"; some like it, some don't. Who are the ones that like it? I don't remember any good feedback. > We tend to (unsurprisingly) hear little or nothing from the people who think >it's working just fine, and it is very easy for a local group in which a few >folks think the behavior is wrong to quickly collectively conclude that it's >wrong. We've deployed hundreds of thousands of machines since this change, >and I don't think we've seen hundreds of thousands of complaints. When we first started testing the new pads this issues came up and because it was a change in behavior from the way ALPS worked. I remember the end result was to disable it. The problem is that its on by default in the hardware. You have to turn it off. To turn it off you have to run the synaptics driver. Running the synaptics driver caused many regressions. We had too many other things to work on rather than the synaptics driver so it shipped with it enabled. -- Richard A. Smith ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Paul - This issue has bubbled up from time to time over the last 18 months or so (judging from my email archives). It is not at all clear to me that there is indeed a "consensus from deployments"; some like it, some don't. We tend to (unsurprisingly) hear little or nothing from the people who think it's working just fine, and it is very easy for a local group in which a few folks think the behavior is wrong to quickly collectively conclude that it's wrong. We've deployed hundreds of thousands of machines since this change, and I don't think we've seen hundreds of thousands of complaints. I don't have a strong opinion and I don't know the answer, but we should be very careful about ignoring the silent majority, if there is one. - Ed On Apr 15, 2010, at 11:18 AM, Paul Fox wrote: > daniel wrote: >> On 15 April 2010 11:40, Martin Langhoff wrote: >>> On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva >>> wrote: BTW how do you disable it? >>> >>> Yeah -- can we disable it easily on F11 builds? >> >> (speaking only for XO) No. We would have to change mouse driver which >> introduces a handful of regressions, will need some real effort to >> resolve. See the discussions earlier in the thread. >> >> The most realistic quick-fix option I can think of is adding a small >> hack into the psmouse driver in the OLPC kernel, which sends the >> single command needed to disable tap-to-click. Last time I looked at >> this code I remember thinking that this would be quite easy, since the >> more-powerful synaptics driver doesn't actually change the mode of the >> mouse, it just takes advantage of a whole load of non-standard >> commands. > > that's a good idea. > > if such a thing were to be introduced, and if it could be made > run-time or boot-time controllable, i take it the consensus from > deployments is that tap-to-click is more confusing than helpful, > and it should be disabled by default. correct? > > (i know that i myself find it annoying. the XO is annoying > enough to type on, without having my windows flip out from under > me because i have careless thumbs.) > > paul > =- > paul fox, p...@laptop.org > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
daniel wrote: > On 15 April 2010 11:40, Martin Langhoff wrote: > > On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva > > wrote: > >> BTW how do you disable it? > > > > Yeah -- can we disable it easily on F11 builds? > > (speaking only for XO) No. We would have to change mouse driver which > introduces a handful of regressions, will need some real effort to > resolve. See the discussions earlier in the thread. > > The most realistic quick-fix option I can think of is adding a small > hack into the psmouse driver in the OLPC kernel, which sends the > single command needed to disable tap-to-click. Last time I looked at > this code I remember thinking that this would be quite easy, since the > more-powerful synaptics driver doesn't actually change the mode of the > mouse, it just takes advantage of a whole load of non-standard > commands. that's a good idea. if such a thing were to be introduced, and if it could be made run-time or boot-time controllable, i take it the consensus from deployments is that tap-to-click is more confusing than helpful, and it should be disabled by default. correct? (i know that i myself find it annoying. the XO is annoying enough to type on, without having my windows flip out from under me because i have careless thumbs.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
I have an old HP laptop with tap-to-click turned on by default when there's no external mouse. It is annoying to be typing text and have your thumb accidentally brush the touchpad and suddenly you're typing in a totally different location in the text, wherever the mouse pointer happened to be aimed.Perhaps adding a touchpad lockout delay that momentarily disables tap-to-click for 1 second, or whatever, after a keyboard key is pressed would help, something like "debouncing" a switch contact in a driver. A control-panel parameter should be provided to adjust the lockout period -- some kids might need more than a 1 second lockout. On Thu, Apr 15, 2010 at 7:40 AM, Martin Langhoff wrote: > On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva > wrote: > > BTW how do you disable it? > > Yeah -- can we disable it easily on F11 builds? > > > > 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 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
On 15 April 2010 11:40, Martin Langhoff wrote: > On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva > wrote: >> BTW how do you disable it? > > Yeah -- can we disable it easily on F11 builds? (speaking only for XO) No. We would have to change mouse driver which introduces a handful of regressions, will need some real effort to resolve. See the discussions earlier in the thread. The most realistic quick-fix option I can think of is adding a small hack into the psmouse driver in the OLPC kernel, which sends the single command needed to disable tap-to-click. Last time I looked at this code I remember thinking that this would be quite easy, since the more-powerful synaptics driver doesn't actually change the mode of the mouse, it just takes advantage of a whole load of non-standard commands. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
On Thu, Apr 15, 2010 at 11:34 AM, Sebastian Silva wrote: > BTW how do you disable it? Yeah -- can we disable it easily on F11 builds? 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
Re: tap-to-click feedback
BTW how do you disable it? There is a thread about the subject currently on OLPC-Uruguay. http://lists.laptop.org/pipermail/olpc-uruguay/2010-April/002075.html Sebastian 2010/4/15 Sebastian Silva > We saw this issue in our work with the Cantagallo comunity school > here in Lima. Tuukka and Kaisa saw it in the teacher training they > attended, it seems to be very confusing for new users, who have > never used a touchpad before (they tend to touch the pad gently > and briefly, obtaining a click instead of moving the pointer). > > I think more testing should have gone into this before > deploying it! > > Cheers > Sebastian > > 2009/10/22 Daniel Drake > > Just wanted to communicate an experience from the deployment here: >> >> A while back, we (OLPC + community) discussed the behaviour of the new >> XO touchpads which have tap-to-click on by default. We debated >> including the fairly large software changes to be able to disable this >> functionality with the interest of retaining the behaviour of the old >> touchpad. We decided against it and shipped software with tap-to-click >> enabled, in hope that it wouldn't cause problems and users would >> adjust. >> >> Well, in my 3-4 months here in Nepal I've heard repeated cries for >> disabling this, since it is causing confusion for children and >> teachers in the schools. Really I think the biggest issue is that they >> press it by accident while typing or making other motions and have no >> idea why the screen has changed significantly (they don't understand >> that it's because they clicked, or that their hand was near the pad). >> >> Do other deployments share the same experience? >> >> Daniel >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > > > -- > Sebastian Silva > > -- Sebastian Silva ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
We saw this issue in our work with the Cantagallo comunity school here in Lima. Tuukka and Kaisa saw it in the teacher training they attended, it seems to be very confusing for new users, who have never used a touchpad before (they tend to touch the pad gently and briefly, obtaining a click instead of moving the pointer). I think more testing should have gone into this before deploying it! Cheers Sebastian 2009/10/22 Daniel Drake > Just wanted to communicate an experience from the deployment here: > > A while back, we (OLPC + community) discussed the behaviour of the new > XO touchpads which have tap-to-click on by default. We debated > including the fairly large software changes to be able to disable this > functionality with the interest of retaining the behaviour of the old > touchpad. We decided against it and shipped software with tap-to-click > enabled, in hope that it wouldn't cause problems and users would > adjust. > > Well, in my 3-4 months here in Nepal I've heard repeated cries for > disabling this, since it is causing confusion for children and > teachers in the schools. Really I think the biggest issue is that they > press it by accident while typing or making other motions and have no > idea why the screen has changed significantly (they don't understand > that it's because they clicked, or that their hand was near the pad). > > Do other deployments share the same experience? > > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Sebastian Silva ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
--- On Thu, 4/15/10, Daniel Drake wrote: > From: Daniel Drake > Subject: Re: ANNOUNCE: F11 for the XO-1 build 140py released > To: "Yioryos Asprobounitis" > Cc: "Paul Fox" , "OLPC Devel" , > "Fedora OLPC List" > Date: Thursday, April 15, 2010, 9:06 AM > On 15 April 2010 09:48, Yioryos > Asprobounitis > wrote: > >> what changed between the first and second boots > that might > >> have > >> made the second successful after the first > failed? > > > > See http://lists.laptop.org/pipermail/devel/2010-April/028172.html > above > > This sounds like http://dev.laptop.org/ticket/9100 > Your workaround is interesting. > > For me, this bug isn't specific to first boot, it's a > from-time-to-time type thing. os140py only has half a dozen reboots so far but the problem did not reappear. Also it _might_ be different than #9100 since pressing the power button turns the XO off almost immediately. When in kernel land I have the feeling it takes a bit longer (from my mess-ups with different distros, kernels and initrds :-). > > Daniel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
--- On Thu, 4/15/10, Paul Fox wrote: > From: Paul Fox > Subject: Re: ANNOUNCE: F11 for the XO-1 build 140py released > To: "Yioryos Asprobounitis" > Cc: "OLPC Devel" , "Fedora OLPC List" > > Date: Thursday, April 15, 2010, 9:01 AM > yioryos wrote: > > > > > > --- On Thu, 4/15/10, Paul Fox > wrote: > > > > > From: Paul Fox > > > Subject: Re: ANNOUNCE: F11 for the XO-1 build > 140py released > > > To: "Yioryos Asprobounitis" > > > Cc: "OLPC Devel" , > "Fedora OLPC List" > > > > > Date: Thursday, April 15, 2010, 8:12 AM > > > yioryos wrote: > > > > > > > > --- On Wed, 4/14/10, Mikus Grinbergs > > > > wrote: > > > > > > > > > > > > > > If not present, OFW (q2e42e) > gave the message > > > "No signature > > > > > for our key list" > > > > > > > > My XO-1 has security disabled and > boots fine. > > > With the > > > > exception of the first boot that > something on > > > olpc.fth blocks > > > > it (with no OFW messages) and never > goes to console. > > > > > > what changed between the first and second boots > that might > > > have > > > made the second successful after the first > failed? > > > > See http://lists.laptop.org/pipermail/devel/2010-April/028172.html > above > > :-) > > > > To repeat, I loaded the olpc.fth from my SDcard > instead the internal NAND. > > It looked like that: > > > > \ Boot script > > " root=/dev/mtdblock0 rootfstype=jffs2 > console=ttyS0,115200 console=tty0 > > fbcon=font:SUN12x22 selinux=0" to boot-file > > " nand:\boot\vmlinuz" to boot-device > > " nand:\boot\initrd.img" to ramdisk > > setup-smbios > > unfreeze > > dcon-unfreeze > > visible > > boot > > > > Set up os140py. Removed the SDcard and rebooted. > > so one possibility is that os140py isn't successfully > enabling > smbios, or not recognizing the results correctly. I'm not sure. It should not work in subsequent boots also then. No? Looks like that needs something that is provided by the OS/initrd (/ofw?) but is generated after the first successful run. > > what firmware is installed on our XO-1? as said (:-) q2e42d > > and -- question for bernie -- does os140py include a new > firmware? Did not offer to upgrade the FW at any point (initial or later boots) though it was plugged for that exact reason. > > paul > =- > paul fox, p...@laptop.org > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
On 15 April 2010 10:01, Paul Fox wrote: > so one possibility is that os140py isn't successfully enabling > smbios, or not recognizing the results correctly. (assuming this bug is indeed an instance of #9100...) SMBIOS should not be required for not-crashing during early boot. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
On 15 April 2010 09:48, Yioryos Asprobounitis wrote: >> what changed between the first and second boots that might >> have >> made the second successful after the first failed? > > See http://lists.laptop.org/pipermail/devel/2010-April/028172.html above This sounds like http://dev.laptop.org/ticket/9100 Your workaround is interesting. For me, this bug isn't specific to first boot, it's a from-time-to-time type thing. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
yioryos wrote: > > > --- On Thu, 4/15/10, Paul Fox wrote: > > > From: Paul Fox > > Subject: Re: ANNOUNCE: F11 for the XO-1 build 140py released > > To: "Yioryos Asprobounitis" > > Cc: "OLPC Devel" , "Fedora OLPC List" > > > Date: Thursday, April 15, 2010, 8:12 AM > > yioryos wrote: > > > > > > --- On Wed, 4/14/10, Mikus Grinbergs > > wrote: > > > > > > > > > > > If not present, OFW (q2e42e) gave the message > > "No signature > > > > for our key list" > > > > > > My XO-1 has security disabled and boots fine. > > With the > > > exception of the first boot that something on > > olpc.fth blocks > > > it (with no OFW messages) and never goes to console. > > > > what changed between the first and second boots that might > > have > > made the second successful after the first failed? > > See http://lists.laptop.org/pipermail/devel/2010-April/028172.html above > :-) > > To repeat, I loaded the olpc.fth from my SDcard instead the internal NAND. > It looked like that: > > \ Boot script > " root=/dev/mtdblock0 rootfstype=jffs2 console=ttyS0,115200 console=tty0 > fbcon=font:SUN12x22 selinux=0" to boot-file > " nand:\boot\vmlinuz" to boot-device > " nand:\boot\initrd.img" to ramdisk > setup-smbios > unfreeze > dcon-unfreeze > visible > boot > > Set up os140py. Removed the SDcard and rebooted. so one possibility is that os140py isn't successfully enabling smbios, or not recognizing the results correctly. what firmware is installed on our XO-1? and -- question for bernie -- does os140py include a new firmware? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
--- On Thu, 4/15/10, Paul Fox wrote: > From: Paul Fox > Subject: Re: ANNOUNCE: F11 for the XO-1 build 140py released > To: "Yioryos Asprobounitis" > Cc: "OLPC Devel" , "Fedora OLPC List" > > Date: Thursday, April 15, 2010, 8:12 AM > yioryos wrote: > > > > --- On Wed, 4/14/10, Mikus Grinbergs > wrote: > > > > > > > > If not present, OFW (q2e42e) gave the message > "No signature > > > for our key list" > > > > My XO-1 has security disabled and boots fine. > With the > > exception of the first boot that something on > olpc.fth blocks > > it (with no OFW messages) and never goes to console. > > what changed between the first and second boots that might > have > made the second successful after the first failed? See http://lists.laptop.org/pipermail/devel/2010-April/028172.html above :-) To repeat, I loaded the olpc.fth from my SDcard instead the internal NAND. It looked like that: \ Boot script " root=/dev/mtdblock0 rootfstype=jffs2 console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 selinux=0" to boot-file " nand:\boot\vmlinuz" to boot-device " nand:\boot\initrd.img" to ramdisk setup-smbios unfreeze dcon-unfreeze visible boot Set up os140py. Removed the SDcard and rebooted. > > paul > > > > > Regarding the freeze at the camera-check boot point, > I had it with os129py (not > > with os140py yet) but I considered it a consequence > of my broken camera. Maybe > > not then. > > > > > > =- > paul fox, p...@laptop.org > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: F11 for the XO-1 build 140py released
yioryos wrote: > > --- On Wed, 4/14/10, Mikus Grinbergs wrote: > > > > > If not present, OFW (q2e42e) gave the message "No signature > > for our key list" > > My XO-1 has security disabled and boots fine. With the > exception of the first boot that something on olpc.fth blocks > it (with no OFW messages) and never goes to console. what changed between the first and second boots that might have made the second successful after the first failed? paul > > Regarding the freeze at the camera-check boot point, I had it with os129py > (not > with os140py yet) but I considered it a consequence of my broken camera. > Maybe > not then. > > =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
