debxo 0.3 release

[Ian Daniher]

RE Suspend / Resume : talk to CJB(Chris Ball) about OHM. I spoke with him a
few weeks ago and, if I recall correctly, all one needs to do is use the
official OLPC Kernel and install the OHM packages.

On Mon, Nov 3, 2008 at 1:20 AM, <david at lang.hm> wrote:

> On Mon, 3 Nov 2008, James Cameron wrote:
>
> > On Sun, Nov 02, 2008 at 09:27:52PM -0800, david at lang.hm wrote:
> >> On Mon, 3 Nov 2008, James Cameron wrote:
> >>> The TODO file in the xodist git repository has a hardware enablement
> >>> section that I added last week, which covers some of the things this
> >>> thread has discussed.
> >>
> >> link to xodist please?
> >
> > xodist is the git repository name for the scripts that generate debxo
> > images.
>
> sorry, I missed that (and I even have that repository cloned, shame on me
> :-)
>
> > git://lunge.mit.edu/git/xodist (per Andres' mail of 28th Oct)
> > or
> > http://dev.laptop.org/~quozl/xodist.git/<http://dev.laptop.org/%7Equozl/xodist.git/>(my repo, sync'ed)
> >
> >> do you have the direction and rotate game keys working?
> >
> > I don't know.
>
> they do not in the 0.3 build
>
> >>> brightness control keys (conflicts with function key usage)
> >>> volume control keys (conflicts with function key usage)
> >>
> >> these don't need system changes, just deciding which function those keys
> >> should do, the brightness and volume functions are strictly in software
> >> (and done via X hooks, as can be shown by the fact that these do not
> work
> >> in a console, and in fact crash the system if you hit them there)
> >
> > Seems more logical to handle these keys in the kernel.
>
> I don't think so. since the hardware produces the function keys, if the
> kernel does the functions instead of userspace, you loose the flexibility
> to use these as normal function keys.
>
> the tendancy is to push more of this sort of thing to userspace anyway.
> the volume keys onthe thinkpads recently changed from being handled by the
> hardware to be intercepted by the kernel and treated as normal keys (with
> the default bindings being to control the volume) a few months ago this
> worked in Gnome, but not KDE, with the ubuntu release a few days ago it
> works in both (I don't use sound enough to have tried it outside of X)
>
> >>> turn off backlight on suspend or hibernate
> >>
> >> I don't use suspend or hibernate enough to help, but now that we have
> the
> >> script to control the backlight this should be fairly easy (although you
> >> really want to turn off the entire screen, not just the backlight, at
> >> least for hibernate, don't you?)
> >
> > If you're saying "the OLPC XO build also turns off the screen hardware",
> > then the next question is "how?" ... presumably this can be found by
> > examining it.
>
> the thought just hit me that we don't always want to turn off the screen
> on suspend, unlike normal systems the XO is designed to be able to run the
> display when the main processor is suspended (although I remember being
> told that this isn't working due to software limitations today)
>
> >>> The latter method is how xodist's initchroot.sh script does some
> >>> features ... like setting up /etc/modules, xorg.conf, and so forth.
> >>
> >> I'm actually not happy with how the OLPC currently handles these things,
> >> they are too X (and sugar) specific. we need to get a layer lower if we
> >> can.
> >
> > Good.  But the general purpose solutions in Debian are perhaps too
> > general for this situation.  Things like the discover package.
>
> ideally I want to figure out how to get these keys into the kernel, at
> that point any userspace can deal with them.
>
> David Lang
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
Ian Daniher
--
OLPC Support Volunteer
OLPCinci Repair Center Coordinator
--
it.daniher at gmail.com
Skype : it.daniher
irc.freenode.net: Ian_Daniher
--
c: 513.290.4942
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20081103/5dc26629/attachment.html>