debxo 0.3 release

[pgf at laptop.org]

david at lang.hm wrote:
 > On Sun, 2 Nov 2008, pgf at laptop.org wrote:
 ...
 > > i suggest searching olpcnews.com/forum 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.

 > 
 > >  my variation on the backlight thing:
 > >    http://dev.laptop.org/~pgf/brightness.sh.txt
 > 
 > 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.)

 > > 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.)

 > > (btw, if there's very much debxo talk, it might be worth setting
 > > up a separate list, since support for other distributions is
 > > somewhat off-topic for this one.)
 > 
 > true, but this information is not specific to debxo, it's specific to the 
 > hardware, and I don't think that there's a seperate 'hardware 
 > support/development' mailing list. if the details of how to deal with the 

you're right -- whatever new list might be created shouldn't be
aimed at a single distribution.  i'll also bet there's overlap
with the fedora-on-XO work -- i've misplaced the url for that
list at the moment.

 > hardware specifics have not already been written up on the wiki somewhere 
 > that would reduce my query to a simple URL link, then they should be.
 > 
 > I'll gather up the information that I find and am pointed at to try to 
 > create such a page.

you might start with this:
    http://wiki.laptop.org/go/Xfce_keybindings
which contains a few of the things you're looking for.

 > 
 > 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.)

paul

 > 
 > extra keyboard keys
 > 
 > lid sensors
 > 
 > the 'slider' function keys (I seem to remember hearing Jim Getty say 
 > something along the lines of the standard X input mechanism can't handle 
 > them)
 > 
 > the four items above should be available with or without X running, 
 > including some ability to set things so that they become 'normal' 
 > keystrokes
 > 
 > EC interface (battery info and charge status). this may show up under the 
 > power interfaces, but from what I've seen on this list the firmware <-> 
 > system API is still being tweaked with, so I don't see how a standard 
 > system would know it.
 > 
 > backlight controls (documented in the script pointed to above, thanks 
 > again)
 > 
 > stylis pad (another comment said that this feature was going to just 
 > disappear from future versions, I'm disappointed to hear that)
 > 
 > information on accessing the mesh mode of the wireless (normal mode works 
 > just fine). given the state of mesh networking, and the ability to do 
 > ad-hoc normal networking, I'm not sure of how needed this is, but for 
 > completeness it should be documented)
 > 
 > hardware encryption engine (does this show up to the kernel as an 
 > available encryption device? (it would be handy if at least the 
 > development builds of the kernel enabled /proc/config.gz for all xo 
 > distros (including the OLPC builds) it costs about 10k 
 > compressed, 40k raw)
 > 
 > 
 > things that probably work, but I'm not doing something right
 > 
 > the camera is showing up, but I'm not getting usable images from it with 
 > the default kde tools
 > 
 > mic input (kmix sees the sound device, including DC input mode, which I 
 > didn't expect, but I haven't sucessfully recorded anything yet)
 > 
 > 
 > is there anything else that may need special handling?
 > 
 > David Lang

=---------------------
 paul fox, pgf at laptop.org