Re: Corrupted display on XO1.5 when suspended with screen on
On Tue, Jun 25, 2013 at 12:18:43AM -0500, Sebastian Silva wrote: El 21/06/13 13:56, John Watlington escribió: This is likely due to the video controller being disabled before the DCON driver has completely finished loading the image into the DCON. Our image is based on 11.3.1 shipping firmware olpc-firmware-q3c06 (but my testing machine has q3c07 and exhibits the same malfunction). (...) We did some work to fix the DCON driver in newer releases. So what component / package etc should I be looking to backport? The kernel, specifically kernel patches to the DCON driver or related components. 11.3.1 was based on kernel 2.6.35.13_xo1.5-20120508.1139.olpc.eb0c7a8 which corresponds to branch olpc-2.6.35 of the olpc-kernel repository: http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35id=eb0c7a8 Development then switched to the branch x86-3.3, and this is where any DCON or display driver fixes after 11.3.1 will be found. I've had a quick look and these viafb fixes look relevant: http://dev.laptop.org/git/olpc-kernel/commit/?h=x86-3.3id=3ef9f18dfe5f97dbae96b8b7658590b6dbf81cea http://dev.laptop.org/git/olpc-kernel/commit/?h=x86-3.3id=d5caefcdf160b0b24153bba89b111419da2f92c3 Other than these viafb fixes, there have been no DCON driver fixes in x86-3.3. I recall some fixes in the ARM laptops though. Perhaps they were not backported. As kernel fixing can be costly for you, let me take you back a few steps in diagnosis ... can you confirm that the problem also affects the original OLPC OS 11.3.1 and not only your own build of 11.3.1? Does the problem only occur with automatic power management enabled? Is there a way to induce the problem quickly? It reminds me of #11231 and #10038. You might see if the reproducers in those tickets cause a problem. Also, although we understand you cannot go to deployment phase with anything later than 11.3.1 because of non-technical reasons, the analysis of this problem could really benefit from trying to reproduce it with 12.1.0, 13.1.0, or 13.2.0. If the problem does not reproduce in 12.1.0 for instance, it means the fix may be in that interval. It would also help to exclude hardware as a cause. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Headphone volume adjustment
This behaviour is coded in rt5631.c ... the codec registers for speaker and headphones have different dB ranges and we use the same value in both registers, with the low end truncated. http://dev.laptop.org/git/olpc-kernel/tree/sound/soc/codecs/rt5631.c?h=arm-3.5#n364 http://dev.laptop.org/git/olpc-kernel/tree/sound/soc/codecs/rt5631.c?h=arm-3.5#n322 -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Māori Macrons olpc keyboard
On 24/06/13 23:43, Walter Bender wrote: Which build are you running? In the latest Sugar builds, there is a keyboard settings control panel section. We could probably backport it to your build if it is reasonably recent. I don't know which build they are running. I've tried One Education OS 1.2 (build au889) with Sugar 0.94.1 13.2.0 for XO-4 (build 10) with Sugar 0.98.7 XO-system 1a for XO-4 (build 34) with Sugar 0.98.7 and none of them have a keyboard settings thing. I don't think a keyboard settings control panel is immediately necessary as the laptops will remain in Maori. It would be good in a future release if we could say after reflashing, set your language and keyboard to maori without having to resort to customizations. Meanwhile, we may have to make a new X keyboard symbols file for you that does the right thing. Not impossible to get upstreamed. I wasn't really able understand the /usr/share/X11/xkb directory, but using xkbcomp to retrieve the current config, modify it and return it to the X server does the trick. Is there a document that describes the right way to add a keyboard and select it? Using xkbcomp in a startup script might work but is obviously a hack. http://wiki.laptop.org/go/Creating_A_New_Keyboard_Layout seems to cover this but appears to be out of date. Until we get feedback from the actual users about what they want their keyboards to do, I think it's best to customize the build they have rather than upstream something and get a new build. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Māori Macrons olpc keyboard
Tom, it's not correct to say the laptops will remain in Maori. Many schools have both Maori and English classes, and the ability of these machines to cross the boundary, to have a child work either in their first language or (with a simple switch in Settings-Language) to gain experience in another, is one of our strong features. Having the switch relatively easy is a great, and I've seen some kids do it while I'm supposedly talking to them. Incidentally, there's a _bug _when declaring the second language second. It seems that whichever language is _last declared_ becomes the current language in which alternative languages are expressed -- as for instance for the list within _Speak_. Since I don't yet have a Maori version of the ESPEAK voice engine (takers anyone?), and since English pronunciation and prosody is a poor substitute, I routinely tell the children typing in Maori to set the _Speak _language to Vietnamese. This is a surprisingly good substitute. But it becomes hard to find if someone has last set the login 2nd language to Arabic. This bug shouldn't be hard to fix. Until then, declare your #2 language first, and your #1 language last. -- barry On 25/06/2013 10:51 p.m., Tom Parker wrote: On 24/06/13 23:43, Walter Bender wrote: Which build are you running? In the latest Sugar builds, there is a keyboard settings control panel section. We could probably backport it to your build if it is reasonably recent. I don't know which build they are running. I've tried One Education OS 1.2 (build au889) with Sugar 0.94.1 13.2.0 for XO-4 (build 10) with Sugar 0.98.7 XO-system 1a for XO-4 (build 34) with Sugar 0.98.7 and none of them have a keyboard settings thing. I don't think a keyboard settings control panel is immediately necessary as the laptops will remain in Maori. It would be good in a future release if we could say after reflashing, set your language and keyboard to maori without having to resort to customizations. Meanwhile, we may have to make a new X keyboard symbols file for you that does the right thing. Not impossible to get upstreamed. I wasn't really able understand the /usr/share/X11/xkb directory, but using xkbcomp to retrieve the current config, modify it and return it to the X server does the trick. Is there a document that describes the right way to add a keyboard and select it? Using xkbcomp in a startup script might work but is obviously a hack. http://wiki.laptop.org/go/Creating_A_New_Keyboard_Layout seems to cover this but appears to be out of date. Until we get feedback from the actual users about what they want their keyboards to do, I think it's best to customize the build they have rather than upstream something and get a new build. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC New Zealand] Māori Macrons olpc keyboard
On 24/06/2013 9:43 PM, Walter Bender walter.ben...@gmail.com wrote: Which build are you running? In the latest Sugar builds, there is a keyboard settings control panel section. We could probably backport it to your build if it is reasonably recent. I remember that perhaps a year ago we had to remove the keyboard applet because it was causing some weird side effects. It wasn't a concern at the time because our focus was on English. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC New Zealand] Māori Macrons olpc keyboard
The widget was broken until recently. Not sure my patches have landed in any releases yet. But we should be able to make a layout that works for both English and Maori without any end-user intervention. Will try to get to it this week. -walter On Tue, Jun 25, 2013 at 9:07 AM, Sridhar Dhanapalan srid...@dhanapalan.com wrote: On 24/06/2013 9:43 PM, Walter Bender walter.ben...@gmail.com wrote: Which build are you running? In the latest Sugar builds, there is a keyboard settings control panel section. We could probably backport it to your build if it is reasonably recent. I remember that perhaps a year ago we had to remove the keyboard applet because it was causing some weird side effects. It wasn't a concern at the time because our focus was on English. -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Māori Macrons olpc keyboard
Maybe the font used is related to this issue? You can test using abiword from gnome or the terminal, and try different fonts. Gonzalo On Mon, Jun 24, 2013 at 7:53 AM, Tom Parker t...@carrott.org wrote: Hi, I'm looking at how you enter a macron for Māori language users. It seems that the olpc us international keyboard binds a ̄ COMBINING MACRON (unicode U+0304) to algr + hyphan. When typed after the letter a you get ā which is similar to but not the same as ā LATIN SMALL LETTER A WITH MACRON (unicode U+0101). Issues I've noted with a small amount of testing: On older builds, Write does not correctly load files containing the combining macron. The combining macron is not rendered at the correct height for lower case letters. (on older builds this seems to be the case all the time, on newer builds, it is rendered correctly after loading a file until you delete a following character the on the same line, then it jumps up) You can have more than one combining macron, they stack. You have to delete twice, once to delete the macron and again to delete the character. Have these issues come up before? I don't see any. I will raise tickets for the bugs rendering the macron in the latest version of write shortly. I'm not sure if anyone wants a ticket for older builds? Obviously stacking macrons is by-design when using the combining macron character (see https://twitter.com/glitchr_/ for more improbable outcomes of combining characters, perhaps your browser will crash). I haven't yet experimented with entering the ā U+0101 characters into sugar (tomorrow!) Apparently on Windows, the Māori keyboard is set up such that when you hit the grave (apparently this is what I have always called the backtick) key and then one of the vowels, you get the macron version of the vowel. I haven't seen this in action but Māori typists claim it is very efficient. Gnome on Ubuntu on my laptop binds right-alt-a to ā U+0101 when using the Māori keyboard layout. I'm not sure how Maori typists feel about this inconsistency with windows. When you choose the language in sugar, can this change the keyboard layout too? If not, what is the recommended way to configure this? How complex is it to change the localization of the keyboard for the Maori language? The xkb files don't look too complicated. Is the grave - vowel = macron vowel possible while still preserving the backtick for shell scripting? I haven't seen the laptops in question but I'm told they have the Australian simplified key caps, so changing the existing alt-gr mappings to render macron vowels (ie to mimic the Maori keyboard option on Gnome-Ubuntu) instead of the existing mappings won't confuse the key caps. Obviously touching all the laptops to change how the keyboard works is a pain and the change is potentially erased by future updates. __**_ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/**listinfo/develhttp://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Testing and comparing wireless setups.
On Mon, Jun 24, 2013 at 6:24 PM, James Cameron qu...@laptop.org wrote: [Warning: this author is on coffee for the first time in months] On Mon, Jun 24, 2013 at 07:14:11AM -0500, David Farning wrote: As part of the XSCE, we would like to start offering wireless setup guidelines. Large deployments might be able to afford a site assessment. Small deployments are left scratching their heads and making decision on anecdotal references. This results in a bottleneck. Smart and motivated people are spending time, early in a deployments lifecycle, on wireless which means other critical task are left undone. This topic is challenging because it is complex. Every workload is different and every electromagnetic environment is different. My idea is start very simply by assigning a numerical score for various wireless devices based on simple criteria like throughput, connection count, overheating, and range. My _very_ naive experiences are that among consumer grade devices: 1. Some devices can handle more connections than others before they start dropping connections. 2. Some devices can handle higher throughput - Several kids watching youtube and me doing a download. 3. Some devices overheat and reset more frequently than others. 4. Some devices have better range than others. I think this is overly simplistic, yet I know a simple heuristic is what is needed. So I suggest coming at it from a different angle. Does this information seem valuable to deployments? Does the general approach seem sane? The stack is deep, so deep that anecdote can be inaccurate and misleading. The phase space has a large number of dimensions. It may be better to accumulate test reports so that people can form their own opinions. The test report should include: - the wireless access point manufacturer, model, serial number, and firmware version, - the XSCE version, - the XO OS version, model, and wireless card, - the measured capability of the internet service, in terms of latency and bandwidth, measured with ping and wget, - the number of access points deployed adjacent to the XSCE, - the number of XO users active during the test, - individual user XO performance observations, in terms of latency, bandwidth, and packet loss, such as ping, wget, and curl POST, rolled up into a total performance score in the range 1 to 10. Then, abstract from the collection of reports a list of access points, user counts, and total performance score. Link each line to the actual report. This ensures that the claims the community make about the access points can be substantiated ... which benefits the community, the deployers, and the manufacturers of the devices. (With enough data, of the order of ten or so reports, the workload and radiofrequency environment aspects can be reduced in importance. I think those aspects are better handled by site design guidelines based on what we find is common to all working deployments.) -- James Cameron http://quozl.linux.org.au/ James, Let's agree to agree on the type of data that is desirable . Yours is better than mine :) My next question is how do we collect, analyze, and publish that data. IE the organization. Our challenge, as XSCE, is that we don't _currently_ have the knowledge or resources to implement the complete testing you propose. As such, we need to bootstrap the process. ( http://en.wikipedia.org/wiki/Bootstrapping ) As XSCE, we are more likely add value to the ecosystem by breaking the big problem down into a series incremental problems which provide a foundation for understand and solving other problems. Working on this series incrementally enables us to build the credibility to attract additional knowledge and resources to work on the issue. So, to slightly shift the conversation. Is is possible to break down the process of getting your endpoint into a series of series of iterative steps? -- David Farning Activity Central: http://www.activitycentral.com ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
