Re: [Server-devel] Amateurish Workaround to Get Bonding to Work With eth1
Will a new ISO (XS-0.5.1?) be released to address this issue? On Wed, 2008-12-10 at 18:51 -0200, Martin Langhoff wrote: > On Wed, Dec 10, 2008 at 6:09 PM, Martin Langhoff > I spotted exactly > the same difference and tested it -- does not seem > > to work. Hope to get to the bottom of it. > > Alright, fixed. Credit to Anna and Jerry for narrowing down on the issue. > > The actual problem is laughably simple -- late in the dev cycle of 0.5 > a typo sneaked in. A minor edit of ifcfg-eth1 fixes it, see: > > http://dev.laptop.org/git?p=projects/xs-config;a=commitdiff;h=acd64ab3d2342fbda08a944e31878db6b3b563f2 > > In any case, you can grab the rpm with the fix from > > http://xs-dev.laptop.org/xsrepos/testing/olpc/9/i386/xs-config-0.5.7.g11aaacf-1.noarch.rpm > > or perform > > yum --enablerepo=olpcxstesting install xs-config > > thanks everyone -- specially Anna -- for you help and patience. > > cheers, > > > > martin ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Backup of user home
On Tue, 2009-09-15 at 15:59 +0200, Martin Langhoff wrote: > On Tue, Sep 15, 2009 at 3:25 PM, Raul Gutierrez Segales > wrote: > > But how will a non-root user be able to read the backup files > > at /library/users give the following permissions: > > Look at the acls for a hint. Apache can already read those files :-) > Interesting! I've been looking at the whole "set nice acls" trick via incrond and /usr/bin/ds-postprocess.py and I have a question: Instead of "using acls creatively (via a cronjob)" would you be accepting a patch for ds-postprocess.py that would allow us to set extra acls rules in a conf file? In that way, we can rest assure that acls are encapsulated through one unique point (which can get additional rules from a conf file). Plus, our XS upgrade won't break are backup scheme :) Thanks! Raúl ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Q3A12 firmware
On Sun, 2009-10-11 at 11:58 -1000, Mitch Bradley wrote: > http://wiki.laptop.org/go/OLPC_Firmware_q3a12 > > This is a stabilization release for B2 machines, fixing numerous issues > with the q3a11 firmware that was installed on them during manufacturing. > It works on XO-1.5 A1, A2, B1, and B2 systems, but does not work on any > XO-1 machines. > > The change list is rather long - see the release page above for details. > We upgraded (an XO 1.5 B2) with the following procedure: flash u:\boot\q3a12.rom After rebooting, kernel initialization dies with: "olpc-dcon: Discovered DCON version 2" Nothing more is printed afterwards. Downgrading to q3a11 makes everything work again. Any ideas? Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Q3A12 firmware
I forgot to mention the software build we are using and also I am not sure how to find that out. Reading /etc/fedora-release I just get: OLPC release 11 (Leonidas) Kernel version is: Linux localhost.localdomain 2.6.30_xo1.5-20090908.1416.1.olpc.d1b0c02 #1 PREEMPT Tue Sep 8 14:24:21 EDT 2009 i686 i686 i386 GNU/Linux And partition layout is: [o...@localhost ~]$ mount /dev/mmcblk0p2 on / type ext4 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /tmp on /tmp type tmpfs (rw) varcacheyum on /var/cache/yum type tmpfs (rw,mode=755) vartmp on /var/tmp type tmpfs (rw) none on /ofw type promfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) gvfs-fuse-daemon on /home/olpc/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=olpc) /dev/mmcblk0p1 on /media/Boot type ext2 (rw,nosuid,nodev,uhelper=devkit) On Mon, 2009-10-12 at 09:48 -0400, Raul Gutierrez Segales wrote: > On Sun, 2009-10-11 at 11:58 -1000, Mitch Bradley wrote: > > http://wiki.laptop.org/go/OLPC_Firmware_q3a12 > > > > This is a stabilization release for B2 machines, fixing numerous issues > > with the q3a11 firmware that was installed on them during manufacturing. > > It works on XO-1.5 A1, A2, B1, and B2 systems, but does not work on any > > XO-1 machines. > > > > The change list is rather long - see the release page above for details. > > > > We upgraded (an XO 1.5 B2) with the following procedure: > > flash u:\boot\q3a12.rom > > After rebooting, kernel initialization dies with: > > "olpc-dcon: Discovered DCON version 2" > > Nothing more is printed afterwards. Downgrading to q3a11 makes > everything work again. > > Any ideas? > > Raúl > > > > ___ > 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
[PATCH] oatslite should log when sending a lease
Hi Daniel,
This one-liner is useful to cross-check with our XOs listing and spot
out those laptops that might have activation problems during certain
periods (i.e.: vacations).
Muchas gracias!
Raúl
diff --git a/oatslite b/oatslite
index cd8abf5..95f797c 100755
--- a/oatslite
+++ b/oatslite
@@ -150,6 +150,7 @@ class OATSRequestHandler(BaseHTTPRequestHandler):
if cfg_get("serve_leases").startswith("y"):
lease = get_lease(dict['serialnum'][0])
if lease is not None:
+syslog.syslog("Sending lease for %s" % rq_sn)
resp["lease"] = lease
if updates is not None:
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Hey guys,
Is it cheating to change the screen depth? I change it to 24 bpp and now
cheese and totem work. Changes to /etc/X11/xorg.conf:
(in the Screen Section)
DefaultDepth 24
(in the Display SubSection)
Depth 24
Cheese doesn't show live video from the camera but I am able to take
pictures. And totem reproduces video (no sound, but hey! that it is
another thread/ticket).
Anything wrong with using X with 24bpp?
I can feel F11 on the XO-1 near :)
On Mon, 2009-12-21 at 23:21 +, Tomeu Vizoso wrote:
> Hmm, it's a bit hard to read with so many details, can you run it
> again without -v --leak-check=full --show-reachable=yes ? Those are
> useful when looking for memory leaks.
>
> I would expect that valgrind would complain when the uninitialized
> values get read.
>
> Thanks,
>
> Tomeu
>
> On Mon, Dec 21, 2009 at 20:13, crodas wrote:
> > Hi there,
> > On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
> > wrote:
> >> On Sat, Dec 19, 2009 at 07:00, John Gilmore wrote:
> #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
> at xvimagesink.c:864
> src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
> dst = {x = 137730309, y = 3, w = 0, h = 137691184}
> result = {x = 0, y = 0, w = 322, h = 241}
> draw_border = 322
> __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"
>
> The src.w value is in the same range as the Xlib function addresses;
> -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
> the XSync function is at 0x4b0eccf7. The other values seem
> irrational. This may be evidence that the stack has been corrupted
> somewhere else, or the values not initialised.
> >>>
> >>> Just to rule out going too far down a blind alley...
> >>>
> >>> Try adding a printf of these values to the code there, rather than or
> >>> in addition to using GDB. GDB may not be 100% reliable when accessing
> >>> variables from optimized code. (I used to maintain GDB, and I worked
> >>> very hard to make it never lie to you, but that precept hasn't always
> >>> been followed in the intervening decade, and optimizations have also
> >>> gotten a lot more complicated.)
> >>>
> >>> Or try compiling that code without -O and see if that changes either
> >>> its behavior, or what the debugger reports.
> >>
> >> At this point is when I would run totem in valgrind, I can help
> >> interpreting the output if it's not clear.
> >>
> >> # yum install valgrind
> >> $ valgrind totem
> > I hope it helps,
> >
> > http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
> >
> > cheers,
> >
> >>
> >> Regards,
> >>
> >> Tomeu
> >
>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: possible progress on XO-1 camera issues
Btw, Record in Sugar works with the same symptoms as Cheese in Gnome
(that is, you can take pictures but you don't get a live feed).
Hth,
Raúl
On Tue, 2009-12-22 at 21:42 -0300, Raul Gutierrez Segales wrote:
> Hey guys,
>
> Is it cheating to change the screen depth? I change it to 24 bpp and now
> cheese and totem work. Changes to /etc/X11/xorg.conf:
>
> (in the Screen Section)
>
> DefaultDepth 24
>
> (in the Display SubSection)
>
> Depth 24
>
> Cheese doesn't show live video from the camera but I am able to take
> pictures. And totem reproduces video (no sound, but hey! that it is
> another thread/ticket).
>
> Anything wrong with using X with 24bpp?
>
> I can feel F11 on the XO-1 near :)
>
>
>
> On Mon, 2009-12-21 at 23:21 +, Tomeu Vizoso wrote:
> > Hmm, it's a bit hard to read with so many details, can you run it
> > again without -v --leak-check=full --show-reachable=yes ? Those are
> > useful when looking for memory leaks.
> >
> > I would expect that valgrind would complain when the uninitialized
> > values get read.
> >
> > Thanks,
> >
> > Tomeu
> >
> > On Mon, Dec 21, 2009 at 20:13, crodas wrote:
> > > Hi there,
> > > On Sat, 19 Dec 2009 12:06:41 +, Tomeu Vizoso
> > > wrote:
> > >> On Sat, Dec 19, 2009 at 07:00, John Gilmore wrote:
> > >>>> #10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
> > >>>> at xvimagesink.c:864
> > >>>> src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
> > >>>> dst = {x = 137730309, y = 3, w = 0, h = 137691184}
> > >>>> result = {x = 0, y = 0, w = 322, h = 241}
> > >>>> draw_border = 322
> > >>>> __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"
> > >>>>
> > >>>> The src.w value is in the same range as the Xlib function addresses;
> > >>>> -1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
> > >>>> the XSync function is at 0x4b0eccf7. The other values seem
> > >>>> irrational. This may be evidence that the stack has been corrupted
> > >>>> somewhere else, or the values not initialised.
> > >>>
> > >>> Just to rule out going too far down a blind alley...
> > >>>
> > >>> Try adding a printf of these values to the code there, rather than or
> > >>> in addition to using GDB. GDB may not be 100% reliable when accessing
> > >>> variables from optimized code. (I used to maintain GDB, and I worked
> > >>> very hard to make it never lie to you, but that precept hasn't always
> > >>> been followed in the intervening decade, and optimizations have also
> > >>> gotten a lot more complicated.)
> > >>>
> > >>> Or try compiling that code without -O and see if that changes either
> > >>> its behavior, or what the debugger reports.
> > >>
> > >> At this point is when I would run totem in valgrind, I can help
> > >> interpreting the output if it's not clear.
> > >>
> > >> # yum install valgrind
> > >> $ valgrind totem
> > > I hope it helps,
> > >
> > > http://oficina.paraguayeduca.org/~crodas/valgrind-debug.txt
> > >
> > > cheers,
> > >
> > >>
> > >> Regards,
> > >>
> > >> Tomeu
> > >
> >
> >
> >
>
> ___
> 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: possible progress on XO-1 camera issues
On Wed, 2009-12-23 at 18:09 +, Daniel Drake wrote: > On Wed, 2009-12-23 at 14:28 -0300, César D. Rodas wrote: > > Hello Everybody, > > > > After hard debugging with Raul, we've realized that the problem was in > > the Geode driver. > > > > I've changed a line within the memory buffer, and it seems to work now. > > > > Looking forward to get feedback (please don't be evil, it's my first > > patch :-) > > > > http://oficina.paraguayeduca.org/~crodas/0045-Fixed-Out-of-memory-error-on-XO-1.patch > > Can you add an explanation? > > It doesn't look correct to me. You are right. It's not correct. The allocation algorithm is OK as it is. We got a wrong understanding of it and since our change made totem and cheese work (because memory was returned - even though we might probably be stepping on someone's else memory) we decided to share the results. The linked list which keeps the count of used regions seems to be manipulated correctly so no problem there. We are actually running out of offscreen memory. After much looking at the code I went back to X's log and I saw an interesting difference between 8.2 and F11. 8.2 (old geode driver): (II) EXA(0): Offscreen pixmap area of 11208320 bytes F11 (new geode driver): (II) EXA(0): Offscreen pixmap area of 5829856 bytes I wonder why there is a 3MB difference. Ideas? Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
On Tue, 2010-01-05 at 22:43 -0800, John Gilmore wrote: > > Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling > > power management in Sugar. > > Is there any reason for cutting release after release that don't work > unless end users disable power management (sometimes twice!)? > > Surely if you can't fix the bugs, you could at least ship the release > with power management disabled by default, so it works out of the box. > Or, one step up from that, have it figure out which hardware it can > reliably suspend on, and only have it enable suspend by default on > that hardware. According to trac this (regression) has been fixed: http://dev.laptop.org/ticket/9779 Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release of F11 for the XO-1 - Build11
On Sun, 2010-01-17 at 17:17 -0500, Steven M. Parrish wrote: > On Wednesday 06 January 2010 01:43:54 John Gilmore wrote: > > > Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling > > > power management in Sugar. > > > > Is there any reason for cutting release after release that don't work > > unless end users disable power management (sometimes twice!)? > > > > Surely if you can't fix the bugs, you could at least ship the release > > with power management disabled by default, so it works out of the box. > > Or, one step up from that, have it figure out which hardware it can > > reliably suspend on, and only have it enable suspend by default on > > that hardware. > > > > John > > > > Sorry it took a bit of time to respond but I've been on vacation and now am > recovering from the flu. > > I released OS11 as a 1st build with the new buildsystem. There are still > some > issues which need to be addressed but I wanted to get a new build with > updated > kernel etc out for testing. > > I did some local testing with powe rmanagement disabled by default and the > issue persisted. It only went away when I went into the control panel and > manually enabled and then disabled power management. > > I truly wish I had the hours to devote to tracking down and fixing all these > issues, however the $DAYJOB along with commute time keeps me away from home > for 13 hours a day, and the $DAYJOB is not in the industry, where I could > work > on this on the side, but it does pay the bills. > > It is my hope to get the remaining issues addressed in short order so a final > release can be made. We do have a time constraint since F11 the base of our > releases will go "End of Life" in June. We want to help. Could you give us a hand to get the build machinery up and running? I found this : http://wiki.laptop.org/go/F11_for_XO-1#Notes_on_how_to_create_XO-1_builds but it is under revision. I think that might help in reducing the contention. Once we are able to cook builds we can help to speed up the testing/fixing process since we (our deployment team) have more time (almost the entire day!) because of schools being on vacations. Thanks for your help and work! Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: B R E A K T H R O U G H -- F11-on-XO1 has working video player
Mikus, F11 is almost out of the oven!! Thanks Mikus & everybody for all of your hard testing! Special kudos to SMParish for doing the builds! Here at .PY we have been able to setup the os image build machinery (thanks Bernie!) so we plan to roll out a signed image soon.. Stay tuned! Any other major blocker that deserves attention? Raúl On Wed, 2010-01-27 at 01:25 -0600, Mikus Grinbergs wrote: > Ever since mid-December 2008, none of the newer XO-1 builds (beyond > 8.2.x) were able to properly show any "moving pictures" for me. > > I ended up substituting another video driver in place of xv. That gave > me a smaller picture (sometimes showing only "snapshots" rather than a > "movie"). > > > Having applied the ticket #9590 fix (adding 'Virtual 1200 900' to the > "Screen" section of xorg.conf), I changed my os11 systems back to using > the xv video driver. I tested under identical conditions both with and > without the #9590 fix. That single change made the difference -- now on > my XO_1 systems, "moving pictures" work properly in F11-on-XO1 builds. > > > Prior to the application of the #9590 fix I could not honestly recommend > any builds beyond 8.2.x to an XO-1 owner. Now I can. > > > mikus > > > > p.s. My current Mplayer command line: > > mplayer -framedrop -vo xv -vfm ffmpeg -lavdopts > > skipframe=nonref:skiploopfilter=nonkey:fast=1 > > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: svn repo for Inventario?
Hola Martín!, On Thu, 2010-02-04 at 17:25 -0500, Martin Langhoff wrote: > Hola Raúl, > > I am trying to test / review / play with Inventario, but can't get to > the SVN repo... > > $ svn co svn://codigo.paraguayeduca.org/inventario > svn: URL 'svn://codigo.paraguayeduca.org/inventario' doesn't exist > > $ svn co http://codigo.paraguayeduca.org/inventario/ > svn: OPTIONS of 'http://codigo.paraguayeduca.org/inventario': 200 OK > (http://codigo.paraguayeduca.org) > > Has it moved elsewhere? Yes, you can view our svn repo structure here: http://trac.paraguayeduca.org/browser/inventario-branches You should find detailed instructions for installation here: http://wiki.paraguayeduca.org/index.php/Get_Inventory_System If you are 100% a Fedora guy things will be quick & easy. Ubunteros shall wait a little more until Bernie gives me a hand to create the needed .debs. Btw, I got an email of people from Rwanda interested in setting it up.. are you helping them out? Just to sync efforts (not sure if they listen to this ML). Please let me know if you stump into any problems. I am around in the usual are-you-looking-for-trouble places in freenode (#sugar, #olpc). Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
recycling chargers
Created by the local techs of our deployment in Caacupé: http://oficina.paraguayeduca.org/~rgs/multiple-chargers/ Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ANNOUNCE: Sugar 0.88 for the XO-1
On Tue, 2010-05-25 at 12:25 -0400, Bernie Innocenti wrote: > Hello everyone, > > we've just started a new development cycle aimed at providing Sugar 0.88 > for the XO-1. Our focus is stability and usability for deployments, > although we're also attempting to merge a couple of low-risk features > developed in Uruguay. > > Full details are here: > > http://wiki.sugarlabs.org/go/Deployment_Team/Sugar-0.88_Notes > > The current image, os140py, is an alpha quality build with a few known > regressions. > s/os140py/os240py/ Raúl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
On Mon, 2010-07-19 at 21:33 -0400, Walter Bender wrote:
> On Mon, Jul 19, 2010 at 9:27 PM, Gonzalo Odiard wrote:
> > Yeah
> > How we detect what keyboard is present?
>
> You can possible to detect the XO 1, which guarantees a membrane
> keyboard. And a non-OLPC machine, which guarantees a non-membrane
> keyboard. It is the XO 1.5 that is at issue. I'll look into it.
http://wiki.laptop.org/go/OLPC_Firmware_q3a44 mentions:
1889: OLPC keyboard driver, avoid confusing EC with enable scan command
I wonder if somehow the type of detected keyboard is discoverable
via /ofw.
Cheers,
Raúl
>
> -walter
>
> def _get_hardware():
> """ Determine whether we are using XO 1.0, 1.5, or "unknown" hardware """
> bus = dbus.SystemBus()
>
> comp_obj = bus.get_object('org.freedesktop.Hal',
> '/org/freedesktop/Hal/devices/computer')
> dev = dbus.Interface(comp_obj, 'org.freedesktop.Hal.Device')
> if dev.PropertyExists('system.hardware.vendor') and \
> dev.PropertyExists('system.hardware.version'):
> if dev.GetProperty('system.hardware.vendor') == 'OLPC':
> if dev.GetProperty('system.hardware.version') == '1.5':
> return XO15
> else:
> return XO1
> else:
> return UNKNOWN
> elif path.exists('/etc/olpc-release') or \
> path.exists('/sys/power/olpc-pm'):
> return XO1
> else:
> return UNKNOWN
>
> > Gonzalo
> >
> > On Mon, Jul 19, 2010 at 9:26 PM, Walter Bender
> > wrote:
> >>
> >> On Mon, Jul 19, 2010 at 5:20 PM, Paul Fox wrote:
> >> > 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.
> >>
> >> The only activity I am aware of that uses F5 and F6 on the XO is the
> >> most recent version of Paint that Gonzolo is working on. Presumably
> >> these keymaps could be grabbed by Paint when running on an OLPC XO 1.0
> >> or when we detect the membrane keyboard. Otherwise, we could keep the
> >> mapping as Bert suggests.
> >>
> >> > any yeas or nays?
> >>
> >> Yeah.
> >> >
> >> > 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
> >> >
> >> > ___
> >> > Sugar-devel mailing list
> >> > sugar-de...@lists.sugarlabs.org
> >> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Walter Bender
> >> Sugar Labs
> >> http://www
