debxo 0.3 release

david at david at
Sun Nov 2 21:39:05 EST 2008

On Sun, 2 Nov 2008, pgf at wrote:

> david at wrote:
> > On Sun, 2 Nov 2008, pgf at wrote:
> ...
> > > i suggest searching for things like this -- last year's
> > > g1g1 users have done a lot of work supporting the XO h/w under non-sugary
> > > environments.
> >
> > well, I was hoping that with an open hardware platform running opensource
> > software there would not be a need to search forums for reverse engineered
> > 'secrets' or 'hacks', but instead such information would be readily
> > available (ideally already documented, but possibly in the "that's so
> > obvious that we didn't think to write it up" catagory for the folks who
> > are experts on the system.
> sorry -- i didn't understand which information you were lacking.
> olpcnews is still a good place to start when doing "aftermarket"
> research.  the XO is an open system, to be sure, but our focus
> has been on creating deployment-focused releases, and not on the
> h/w API documentation.  i'm sure this will be get better over
> time, with the help of motivated helpers.

no problem, I may have been wishing too hard

> >
> > >  my variation on the backlight thing:
> > >
> >
> > thanks, this is exactly the type of thing I was looking for.
> >
> > why did you store the brightness in a file instead of reading the
> > beightness and mode from the /sys hooks?
> i think you must have skimmed too quickly -- it's exactly those /sys
> hooks that it reads and writes.)

you are right, for some reason I read that as reading in a local file, 

> > > on a couple of ubuntu-based thin client machines i have i run a
> > > very simple daemon that eavesdrops on an /dev/input/eventN node
> > > in order to support special multi-media keyboard keys.  i suspect
> > > it would be easy to adapt this to supporting the XO special keys
> > > if there's not already a packaged way of doing it.  (the keys
> > > invoke arbitrary scripts, and iirc, they're active in either
> > > console or X11 modes.)
> >
> > is this the 'right' way to do this on a linux system? or is there some way
> > that is more seamless (at least for cases where we want button presses to
> > become normal keys instead of invoking scripts)?
> i confess i don't really know that the "right" way is, since i
> suspect the "right" way has changed many times since linux was
> born, and probably a couple of times before that.  i do recall that
> when i came up with my current solution, i couldn't find a hotkey
> solution that wasn't completely wedded to either X, or worse, to
> a specific window manager.  i didn't even want the keys to be
> attached to a specific user login session.  (specifically, i
> wanted the volume/play/pause/mute buttons on my keyboards to
> control the livingroom stereo no matter who or what was using the
> computer.)


> >
> > things that I can see as possibly needed
> >
> > game keys
> on a traditional PC keyboard, the keypad area to the right
> contains duplicate arrow, pgup/down and home/end keys that are
> operational when numlock is not in effect.  the gamepad produces
> the same keycodes that those keypad keys do.  i.e., the dpad
> produces keypad up/down/left/right, and the square/check/circle/
> cross keys produce the traditional keypad page up/down and
> home/end.  (not necessarily in that order -- i don't have an XO
> handy to verify which are which.)

hmm, I don't think they are the same keycodes at the hardware level. if 
they were then they would work the same in all software, and what I'm 
seeing is that on the debxo systems the game keys are doing nothing. given 
that the system can tell the difference between booting and holding down a 
game key, or booting and holding down an arrow key, they have to be 
different at some point.

the OLPC builds then map them to the same thing, but I don't think they 
must be that way (and I've had a ticket in since last december asking for 
info on how to map them to other keys)

More information about the Devel mailing list