Re: Game keys

[david]

On Sun, 2 Nov 2008, Mitch Bradley wrote:

> David Lang wrote:
>> ideally I want to figure out how to get these keys into the kernel, at
>> that point any userspace can deal with them.
>
> The game keys produce scancodes that are folded into the keyboard data
> stream.  The kernel sees them interspersed with ordinary keyboard scan
> codes.  What it does with them depends on a lot of factors that I
> haven't bothered to understand in detail.  I think there are several
> different ways that scancodes can be mapped into ASCII or other events,
> depending on whether you are using a console or X or whatever.  I
> respectfully submit that getting the codes from the kernel to "any
> userspace" is quite a bit more complicated in practice than the above
> assertion seems to imply.

let me try again.

I want to find out what the scancodes are, so that I can then document how 
to get them mapped to keystokes via some mechanism similar to the kernel 
keymaps (for console stuff) and xkb (for X stuff). the idea being that 
once these are mapped to be keystrokes, exactly what keystrokes they are 
mapped to can be tweaked, and things can be configured to take action on 
those keystrokes.

the current situation seems to be that the scancodes don't map to 
anything, the OLPC Sugar build is grabbing and processing the raw 
scancodes and taking action on them.

having a config file for the kernel or X to make use of the keys doesn't 
bother me, requireing a specific desktop to make use of the keys does.

> Here is an OFW recipe you can use to see the scancode sequences:
>
> ok disable-interrupts
> ok stdin @ iselect
> ok  20 0 do  begin get-data? until .  loop
>
> they type some keys or press some game buttons.
>
> That will display 32 (0x20) scancodes.  You can re-execute it (up-arrow,
> enter) to see more.
>
> OFW uses "scan set 1", so the codes that you will see are from that
> set.  It turns out that the game keys codes are always from scan set 1;
> they don't change if you tell the keyboard to use scan set 2, and they
> don't change if you tell the EC to translate or not translate from set 2
> to set 1.
>
> The general form of scanset 1 is:
>
> [ optional 0xe0 prefix ]  make-code
> [ optional 0xe0 prefix ]  break-code
>
> For a given key, break-code is 0x80 | make-code
>
> The 0xe0 prefix is generally used to distinguish between multiple copies
> of the "same" key.  For example, a full sized keyboard has two "1" keys,
> one in the row above the alpha keys and one in the numeric keypad.  If
> you try the above program with the game keys, you will see that the left
> and right game key clusters use the same base codes, but the right
> cluster has prefixes.

how do these codes map to what I read about for dumpkeys/loadkeys 
(console) or xkb map files (for X)?

> It's also possible to ask the embedded controller to tell you which game
> keys are currently depressed; the return value is a bitmask of which
> ones are down.  That's useful for early firmware tests before the
> keyboard event stream is initialized, but not particularly useful in the
> Linux event-driven regime.

this can be extremely useful for games (no worry about events getting 
buffered, you can find out exactly what the status is _now_), but it's not 
what I'm looking for.

I'm trying to figure out a way to improve the usefulness of the XO in 
tablet mode by being able to configure what the keys do.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[James Cameron]

On Mon, Nov 03, 2008 at 12:07:30AM -0800, [EMAIL PROTECTED] wrote:
> I want to find out what the scancodes are, so that I can then document how 
> to get them mapped to keystokes via some mechanism similar to the kernel 
> keymaps (for console stuff) and xkb (for X stuff). the idea being that 
> once these are mapped to be keystrokes, exactly what keystrokes they are 
> mapped to can be tweaked, and things can be configured to take action on 
> those keystrokes.

Good.

> the current situation seems to be that the scancodes don't map to 
> anything, the OLPC Sugar build is grabbing and processing the raw 
> scancodes and taking action on them.

Certainly not.  The kernel is receiving scancodes, translating them to
keycodes, X is translating them to keysyms, and Sugar is acting on them.

You can see what the kernel receives with "showkey --scancodes", see
what it translates them to with "showkey", and see what X thinks about
it with "xev".

> how do these codes map to what I read about for dumpkeys/loadkeys 
> (console) or xkb map files (for X)?

scancodes in OFW are the same as scancodes in the kernel, as far as I
can tell.  I ran the OFW and the "showkey --scancodes" command, and
could not find any difference in a quick survey.

Some scancodes have no mapping to keycodes in the kernel on debxo, yet
they have a mapping on the OLPC OS build.  The debxo kernel dutifully
prints out a warning from atkbd.c when it sees a scancode it doesn't
know about:

[  832.249013] atkbd.c: Unknown key pressed (translated set 2, code 0x65 on 
isa0060/serio0).
[  832.249013] atkbd.c: Use 'setkeycodes 65 ' to make it known.
[  832.420977] atkbd.c: Unknown key released (translated set 2, code 0x65 on 
isa0060/serio0).
[  832.420977] atkbd.c: Use 'setkeycodes 65 ' to make it known.

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[david]

On Mon, 3 Nov 2008, James Cameron wrote:

>
>> the current situation seems to be that the scancodes don't map to
>> anything, the OLPC Sugar build is grabbing and processing the raw
>> scancodes and taking action on them.
>
> Certainly not.  The kernel is receiving scancodes, translating them to
> keycodes, X is translating them to keysyms, and Sugar is acting on them.
>
> You can see what the kernel receives with "showkey --scancodes", see
> what it translates them to with "showkey", and see what X thinks about
> it with "xev".

right now nothing shows up if I run this from an xterm

>> how do these codes map to what I read about for dumpkeys/loadkeys
>> (console) or xkb map files (for X)?
>
> scancodes in OFW are the same as scancodes in the kernel, as far as I
> can tell.  I ran the OFW and the "showkey --scancodes" command, and
> could not find any difference in a quick survey.
>
> Some scancodes have no mapping to keycodes in the kernel on debxo, yet
> they have a mapping on the OLPC OS build.  The debxo kernel dutifully
> prints out a warning from atkbd.c when it sees a scancode it doesn't
> know about:
>
> [  832.249013] atkbd.c: Unknown key pressed (translated set 2, code 0x65 on 
> isa0060/serio0).
> [  832.249013] atkbd.c: Use 'setkeycodes 65 ' to make it known.
> [  832.420977] atkbd.c: Unknown key released (translated set 2, code 0x65 on 
> isa0060/serio0).
> [  832.420977] atkbd.c: Use 'setkeycodes 65 ' to make it known.

I hadn't been checking in the logs.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[Ignacio Vazquez-Abrams]

On Mon, 2008-11-03 at 19:45 +1100, James Cameron wrote:
> [many poignant words]

If you'll allow me to barge in on this conversation for but a moment...

https://bugzilla.redhat.com/show_bug.cgi?id=468744

-- 
Ignacio Vazquez-Abrams <[EMAIL PROTECTED]>

PLEASE don't CC me; I'm already subscribed


signature.asc
Description: This is a digitally signed message part
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[James Cameron]

On Mon, Nov 03, 2008 at 07:45:07PM +1100, James Cameron wrote:
> Some scancodes have no mapping to keycodes in the kernel on debxo, yet
> they have a mapping on the OLPC OS build.

Because the mapping has not gone upstream yet.

On OLPC OS build 757, loadkeys is run by /etc/init.d/olpc-configure,
which is provided by package olpc-utils.  It uses the manufacturing tag
data or reads /dev/nvram to pick a keyboard layout.  This is not what
you are looking for.

Here is what you are looking for ... /usr/sbin/setolpckeys provided by
the olpc-utils-0.84.29.20080820git1d35c4-1.olpc3.i386 package defines a
set of translations via a udev rule, see
/etc/udev/rules.d/96-olpc-keyboard.rules

ACTION=="add", SYSFS{name}=="AT Translated Set 2 keyboard", KERNEL=="event*", 
RUN+="/usr/sbin/setolpckeys /dev/input/%k"

The udev rule is courtesy of package initscripts-8.76.2-1.olpc3.7.i386

I'll ponder adding this into debxo.  I was able to retrofit it just
fine now, by copying across the udev rule file and the binary.

git://dev.laptop.org/projects/olpc-utils

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[James Cameron]

On Mon, Nov 03, 2008 at 04:28:15AM -0500, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-11-03 at 19:45 +1100, James Cameron wrote:
> > [many poignant words]

Poignant?  That's a new one.  ;-)

> If you'll allow me to barge in on this conversation for but a moment...
> https://bugzilla.redhat.com/show_bug.cgi?id=468744

By all means.  Thanks.  hal-info is version 20080508+git20080601-1 on
debxo, and does not contain this fix.  The existence of this bug
suggests it will be eventually fixed.

olpc-utils/TODO also lists the desire to abandon setolpckeys.  ;-)

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[david]

On Mon, 3 Nov 2008, Ignacio Vazquez-Abrams wrote:

> On Mon, 2008-11-03 at 19:45 +1100, James Cameron wrote:
> > [many poignant words]
> 
> If you'll allow me to barge in on this conversation for but a moment...
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=3D468744

thanks, that looks like exactly the type of thing I was looking for.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[Jeremy Katz]

On Mon, 2008-11-03 at 06:27 -0500, Ignacio Vazquez-Abrams wrote:
> On Mon, 2008-11-03 at 20:57 +1100, James Cameron wrote:
> > On Mon, Nov 03, 2008 at 04:28:15AM -0500, Ignacio Vazquez-Abrams wrote:
> > > If you'll allow me to barge in on this conversation for but a moment...
> > > https://bugzilla.redhat.com/show_bug.cgi?id=468744
> > 
> > By all means.  Thanks.  hal-info is version 20080508+git20080601-1 on
> > debxo, and does not contain this fix.  The existence of this bug
> > suggests it will be eventually fixed.
> 
> Unfortunately a patch to hal-info isn't enough. See the bug it blocks
> for a few details. Fortunately Richard Hughes is on it, and a fix should
> show up in hal... soonish (OFW on x86 being a new thing and all).

Also, this is problematic because the OFW patches being used in the OLPC
kernel aren't upstream either.  Which means yet more[1] stuff in
upstream projects that is dependent on not upstreamed kernel
functionality.

All of the efforts underway to use the XO outside of the original narrow
path makes it that much more clear that kernel changes need to be
aggressively being pushed upstream, not having that done far later... :/

Jeremy

[1] The battery do-not-poll stuff that already made its way into hal I
found out on Friday late afternoon is dependent on bits of the olpc
battery and power management code which aren't upstream at all :(

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Project name : GCompris has been set up

[Henry Edward Hardy]

Sun, 12 Oct 2008 01:17:14 +0200, Bruno Coudoin <[EMAIL PROTECTED]>
wrote:

1. Project name : GCompris
Done. Your tree is here:
git+ssh://[EMAIL PROTECTED]/git/activities/gcompris

Please follow instructions here for importing your project:
http://wiki.laptop.org/go/Importing_your_project

Let us know if you have any problems with your tree. Happy hacking.

Cheers,

--
Henry Edward Hardy
[EMAIL PROTECTED]


-- 
βλεπομεν γαρ αρτι δι εσοπτρου εν αινιγματι
-- שאול התרסי , First Letter to the Corinthians 1:13
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Project name : GCompris has been set up

[Bruno Coudoin]

Le lundi 03 novembre 2008 à 10:39 -0500, Henry Edward Hardy a écrit :
> Sun, 12 Oct 2008 01:17:14 +0200, Bruno Coudoin <[EMAIL PROTECTED]>
> wrote:
> 
> 1. Project name : GCompris
> Done. Your tree is here:
> git+ssh://[EMAIL PROTECTED]/git/activities/gcompris
> 
> Please follow instructions here for importing your project:
> http://wiki.laptop.org/go/Importing_your_project
> 
> Let us know if you have any problems with your tree. Happy hacking.
> 
Thanks for the git but I don't really need this. What is important for
me is a place to put my 100 bundles.

-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[Ignacio Vazquez-Abrams]

On Mon, 2008-11-03 at 20:57 +1100, James Cameron wrote:
> On Mon, Nov 03, 2008 at 04:28:15AM -0500, Ignacio Vazquez-Abrams wrote:
> > If you'll allow me to barge in on this conversation for but a moment...
> > https://bugzilla.redhat.com/show_bug.cgi?id=468744
> 
> By all means.  Thanks.  hal-info is version 20080508+git20080601-1 on
> debxo, and does not contain this fix.  The existence of this bug
> suggests it will be eventually fixed.

Unfortunately a patch to hal-info isn't enough. See the bug it blocks
for a few details. Fortunately Richard Hughes is on it, and a fix should
show up in hal... soonish (OFW on x86 being a new thing and all).

-- 
Ignacio Vazquez-Abrams <[EMAIL PROTECTED]>

PLEASE don't CC me; I'm already subscribed


signature.asc
Description: This is a digitally signed message part
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 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, <[EMAIL PROTECTED]> wrote:

> On Mon, 3 Nov 2008, James Cameron wrote:
>
> > On Sun, Nov 02, 2008 at 09:27:52PM -0800, [EMAIL PROTECTED] 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/(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@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
Ian Daniher
--
OLPC Support Volunteer
OLPCinci Repair Center Coordinator
--
[EMAIL PROTECTED]
Skype : it.daniher
irc.freenode.net: Ian_Daniher
--
c: 513.290.4942
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Sucrose 0.83.1 Development Release

[Simon Schampijer]

Tomeu Vizoso wrote:
> On Fri, Oct 31, 2008 at 9:30 PM, S Page <[EMAIL PROTECTED]> wrote:
>> Simon Schampijer wrote:
>>> This is our first Development Release in the 0.84 cycle. The code base
>>> has seen many refactoring efforts to improve the platform.
>> Will OLPC joyride builds pick up the new Sucrose?
> 
> Sure. Hopefully soon.
> 
>>> Furthermore the datastore has been rewritten, to simplify and improve
>>> maintainability. The API has been kept in place.
>> What happens when you upgrade an XO with the old datastore?
> 
> The old datastore will be updated to the new format.
> 
>> What happens if you then downgrade it?
> 
> You lose.
> 
>>> Sugar moved to use Gconf as a back end to store the profile.
>> When you upgrade an XO, does it import your old profile
>> (~olpc/.sugar/default/config)?
> 
> Yup.
> 
>> What happens if you then downgrade?
> 
> You will be prompted to enter again a name, choose a color, etc.

Right when we upgrade the old profile is ported to gconf and the 
.sugar/default/config file is erased - so when we downgrade we check for 
the presence of that file and will create the config like we do on first 
boot.

>>> An ABI policy has been figured out and modules have been marked as
>>> STABLE / UNSTABLE / DEPRECATED.
>> Where are they marked, in the .py files?
> 
> Yes, in the docstrings so it should make it to places like
> http://api.sugarlabs.org
> 
>>> == Fructose news ==
>>> ...
>> Are the new activity versions backwards-compatible with 8.2?  If so, the
>> maze of Activity lists should be updated.
> 
> Most of them yes, a notable exception is Browse because depends on
> xulrunner and hulahop. Read has the same issue, but evince hasn't been
> updated (yet) so for now it should work.
> 
>> Currently http://wiki.laptop.org/go/Activities/Joyride pulls in
>> Activities/G1G1 , as does Activities/G1G1/8.2, and that list still
>> references old versions -- Browse 98 not 100, Read 52 not 60, etc. --
>> even though the links say "Browse (latest)".
> 
> Who could take care of this?

Activities/G1G1/8.2 is right to pull in Browse 98 - since the latest 
browse is dependent on the latest hulahop. The others should be updated 
I guess.

Best,
Simon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: debxo 0.3 release

[Erik Garrison]

This sounds right.  The OHM packages aren't in any debian repo afaik, so
we'll have to package them.  Then we'd need a debian repository for
these packages.

On Mon, Nov 03, 2008 at 11:53:40AM -0500, Ian Daniher wrote:
> 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, <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, 3 Nov 2008, James Cameron wrote:
> >
> > > On Sun, Nov 02, 2008 at 09:27:52PM -0800, [EMAIL PROTECTED] 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/(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@lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
> >
> 
> 
> 
> -- 
> Ian Daniher
> --
> OLPC Support Volunteer
> OLPCinci Repair Center Coordinator
> --
> [EMAIL PROTECTED]
> Skype : it.daniher
> irc.freenode.net: Ian_Daniher
> --
> c: 513.290.4942

> ___
> 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

Issue with build 767 or new firmware, fail keyboard test

[John Mark]

Hi guys,

I run a support gang member and I run a XO repair in Miami, FL.

I don't know if it's a known issue already but whenever I do a XO self test
on new build or firmware (I don't know if it runs from firmware or build) it
doesn't get to the keyboard test.

After the mouse test passes, it gives me an error
"Invalid opcode" and the XO shuts down.

Just thought I'll let you guys know. Feel free to reply to me with any
information regarding this error I'm having. Whether it's known or wasn't.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

ACPI on XO (was: Re: [Techteam] Weekend 10/31)

[Deepak Saxena]

[cc:ing devel]

My understanding of cpuidle is that it is designed to be fairly CPU/system
agnostic with a clean driver interface to allow for tweaking the CPU/SOC
idle control. There is even an ARM port [1] but as you will see in that
email, the nomenclature for CPU idle states has been heavily borrowed from 
the ACPI definition (C-states) as that is what the X86 world uses
everywhere.  If we dont' want to use ACPI (my vote), I'm thinking we can 
write a a low level driver that talks directly to the HW to move us between 
"C-states".  Looking at the Geode documentation [2], it only seems to 
support running, halt, and sleep state (Jordan, is this correct?) and
I can't imagine it being difficult to write a driver to switch between
these if the raw HW is documented.

I want to make sure everyone understand what CPUIdle does as I've heard
some comments that lead me to believe people expect more out of it.
It is meant as a framework to help move the CPU between high and low latency 
idle states based on recent CPU usage patterns, latency requiremenents and 
any other things that we care about in the heureistic algorithm (the governor).

We still have to things like keep track of how long it has been since a user 
interacted with the device and whether the audio devide is open, etc to 
determine 
whether we want to do a full system suspend or not. While we could push all 
that into the governor, I think it would be massively overiding the framework. 
I 
want to clarify this b/c I recall someone saying something along the lines
that cpuidle will help us figure when to suspend and that is not the
case. It is meant only for CPU idle state management, In our case, when the
system is fairly idle, we want to put the whole system to sleep, not just
the CPU.

~Deepak

[1] 
https://lists.linux-foundation.org/pipermail/linux-pm/2008-February/016546.html
[2] May 2008 version, Page 599, Power State Parameter Definitions

On Nov 03 2008, at 10:11, Adam M Belay was caught saying:
> Hi Richard,
>
> That's correct, there shouldn't be any hard dependencies with ACPI.   
> However, it
> was the first interface supported, so there could be some cruft  
> remaining.  I'd
> be interested in hearing more about the issue.
>
> Thanks,
> Adam
>
> Quoting "Richard A. Smith" <[EMAIL PROTECTED]>:
>
>> Jim Gettys wrote:
>>> CPU idle shouldn't be entangled with ACPI.  People on non-x86 will care.
>>>
>>> So think your proposed "fix" is wrong; but should go into trac against
>>> the kernel, and a patch for the fundamental kernel fix developed
>>> - Jim
>>>
>>
>> I hope that indeed I'm incorrect on this but when I tried to follow  
>> the code init/working path for cpuidle thats where I wound up.
>>
>> If the kernel hackers can give me a quick 2nd opinion I'll be happy to 
>> file a bug with the results.
>>
>> -- 
>> Richard Smith  <[EMAIL PROTECTED]>
>> One Laptop Per Child
>>
>

-- 
 Deepak Saxena - Kernel Developer, One Laptop Per Child
   _   __o   (o>
---\<,  Give One Laptop, Get One Laptop  //\
 - ( )/ ( )  http://www.amazon.com/xoV_/_

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Project name : GCompris has been set up

[Morgan Collett]

On Mon, Nov 3, 2008 at 18:06, Bruno Coudoin <[EMAIL PROTECTED]> wrote:
> Le lundi 03 novembre 2008 à 10:39 -0500, Henry Edward Hardy a écrit :
>> Sun, 12 Oct 2008 01:17:14 +0200, Bruno Coudoin <[EMAIL PROTECTED]>
>> wrote:
>>
>> 1. Project name : GCompris
>> Done. Your tree is here:
>> git+ssh://[EMAIL PROTECTED]/git/activities/gcompris
>>
>> Please follow instructions here for importing your project:
>> http://wiki.laptop.org/go/Importing_your_project
>>
>> Let us know if you have any problems with your tree. Happy hacking.
>>
> Thanks for the git but I don't really need this. What is important for
> me is a place to put my 100 bundles.

ssh to dev.laptop.org, and put them in your public_html folder. They
will show up at http://dev.laptop.org/~bdoin/

Regards
Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] Weekend 10/31

[Deepak Saxena]

On Nov 03 2008, at 12:45, Richard A. Smith was caught saying:
>
> drivers/acpi/processor_core.c:
>   result = cpuidle_register_driver(&acpi_idle_driver);
>
> looking at this file I see that its called from
>
> static int __init acpi_processor_init(void)
>
> This is the same routine that creates a /proc/acpi directory which does  
> not exist on the XO so that plus the fact that I know we have ACPI  
> disabled I'm assuming that this routine is not called.
>
> Further greping for 'cpuidle_' I find that the only places cpuidle_  
> functions are called is in drivers/acpi/processor_core.c and  
> driver/acpi/processor_idle.c .
>
> If its used in another archs besides x86 can you point me to the code?  
> Perhaps I'm not grepping for the right thing?


drivers/acpi/processor_idle.c:acpi_processor_power_init() calls 
driver/cpuidle/cpuidle.c:cpuidle_register_device(). This in turn
calls cpuidle_install_idle_handler() which sets the pm_idle
pointer to cpuidle_idle_call(). pm_idle() is called by 
arch.x86/kernel/proccess_32.c:cpu_idle().

cpu_idle_call() calls the governor's select() function which 
pokes at various the bits int the cpuidle_device structure and 
the current system state to determine the next state and returns an 
index into the cpuidle_device's state table. We then index into the 
state table, and call the state's enter() function to perform the 
actual CPU swtich.

It looks like to make it work with a non-x86 arch, one would have
to hook the pm_idle() call into the the cpu_idle() routine, for example 
arch/arm/kernel/process.c:cpu_idle() on ARM. In our case, we would want 
to register an olpc_idle_driver and an olpc_idle_device that exports 
the known states. Once those are in place, the generic x86 cpu_idle() 
call will call into them via the framework.

> [1] cpuidle is very hard to google for usage info. There is  lots of  
> unrelated hits that use the term cupidle.  Is there a good reference for  
> the stuff thats exposed to userspace other than whats in the kernel docs?

I haven't found anything super useful except for reading the code. 
linux-pm list is probably the  best place to go for more details.

~Deepak

-- 
 Deepak Saxena - Kernel Developer, One Laptop Per Child
   _   __o   (o>
---\<,  Give One Laptop, Get One Laptop  //\
 - ( )/ ( )  http://www.amazon.com/xoV_/_

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[James Cameron]

On Mon, Nov 03, 2008 at 01:24:00AM -0800, [EMAIL PROTECTED] wrote:
> right now nothing shows up if I run this from an xterm

Works for me.  I was doing it on debxo KDE.  What were you trying it on?
xev is /usr/bin/xev, provided by the x11-utils package.

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)

[Jordan Crouse]

On 03/11/08 09:31 -0800, Deepak Saxena wrote:
> [cc:ing devel]
> 
> My understanding of cpuidle is that it is designed to be fairly CPU/system
> agnostic with a clean driver interface to allow for tweaking the CPU/SOC
> idle control. There is even an ARM port [1] but as you will see in that
> email, the nomenclature for CPU idle states has been heavily borrowed from 
> the ACPI definition (C-states) as that is what the X86 world uses
> everywhere.  If we dont' want to use ACPI (my vote), I'm thinking we can 
> write a a low level driver that talks directly to the HW to move us between 
> "C-states".  Looking at the Geode documentation [2], it only seems to 
> support running, halt, and sleep state (Jordan, is this correct?) and
> I can't imagine it being difficult to write a driver to switch between
> these if the raw HW is documented.

Yes, in classic ACPI terminology, we only support C1 through the 'hlt'
instruction).

> I want to make sure everyone understand what CPUIdle does as I've heard
> some comments that lead me to believe people expect more out of it.
> It is meant as a framework to help move the CPU between high and low latency 
> idle states based on recent CPU usage patterns, latency requiremenents and 
> any other things that we care about in the heureistic algorithm (the 
> governor).
> 
> We still have to things like keep track of how long it has been since a user 
> interacted with the device and whether the audio devide is open, etc to 
> determine 
> whether we want to do a full system suspend or not. While we could push all 
> that into the governor, I think it would be massively overiding the 
> framework. I 
> want to clarify this b/c I recall someone saying something along the lines
> that cpuidle will help us figure when to suspend and that is not the
> case. It is meant only for CPU idle state management, In our case, when the
> system is fairly idle, we want to put the whole system to sleep, not just
> the CPU.

The concept of suspend is muddled greatly with kernel and userspace folks
both participating in the discussion and coming at the problem from
different directions.  As Deepak says, the dream is to put the whole system
to sleep on a very long idle interval where other processors would be in a
deeper C state.  To do this, we need to know certain kernel timing
information that we can compare to our worse case suspend/resume time and
make a reasonable choice to attempt to enter a suspended state.  So in
that regard, it does help us determine if we want to try to sleep, but its
only one of a number of inputs into the black box - some of which are 
determined in userspace through OHM, and others which are determined
by the kernel.

Presumably the cpuidle code would kick into XO specific code at some point
which would check that all of the other suspend inputs are green before
doing the deed.  The funny thing is that this isn't so dissimilar from how
ACPI works.

Jordan

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)

[Deepak Saxena]

On Nov 03 2008, at 13:41, Jordan Crouse was caught saying:
> The concept of suspend is muddled greatly with kernel and userspace folks
> both participating in the discussion and coming at the problem from
> different directions.  As Deepak says, the dream is to put the whole system
> to sleep on a very long idle interval where other processors would be in a
> deeper C state.  To do this, we need to know certain kernel timing
> information that we can compare to our worse case suspend/resume time and
> make a reasonable choice to attempt to enter a suspended state.  So in
> that regard, it does help us determine if we want to try to sleep, but its
> only one of a number of inputs into the black box - some of which are 
> determined in userspace through OHM, and others which are determined
> by the kernel.
> 
> Presumably the cpuidle code would kick into XO specific code at some point
> which would check that all of the other suspend inputs are green before
> doing the deed.  The funny thing is that this isn't so dissimilar from how
> ACPI works.

Right, and at that point, we're not doing "cpuidle", we're doing full
system state assesment and I don't think doing that in the kernel in
the middle of the idle loop is the best thing to do and we would probably
have to add a lot of interfaces into the kernel to manage all that
information. We could alternative add a callback into a userpsace helper
in an OLPC-specific cpuidle governer but jumping back into userspace
from this deep in the idle path is probably very unsafe to do. The
simplest thing to do would be to have our device present a state that
has a very long latency value corresponding to full system suspend
so that the existing framework can just work. I'm not sure how
well the kernel would handle us triggering a suspend from within
the kernel either, but only one way to find out. :)

~Deepak

-- 
 Deepak Saxena - Kernel Developer, One Laptop Per Child
   _   __o   (o>
---\<,  Give One Laptop, Get One Laptop  //\
 - ( )/ ( )  http://www.amazon.com/xoV_/_

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO (was: Re: [Techteam] Weekend 10/31)

[Jordan Crouse]

On 03/11/08 13:12 -0800, Deepak Saxena wrote:
> On Nov 03 2008, at 13:41, Jordan Crouse was caught saying:
> > The concept of suspend is muddled greatly with kernel and userspace folks
> > both participating in the discussion and coming at the problem from
> > different directions.  As Deepak says, the dream is to put the whole system
> > to sleep on a very long idle interval where other processors would be in a
> > deeper C state.  To do this, we need to know certain kernel timing
> > information that we can compare to our worse case suspend/resume time and
> > make a reasonable choice to attempt to enter a suspended state.  So in
> > that regard, it does help us determine if we want to try to sleep, but its
> > only one of a number of inputs into the black box - some of which are 
> > determined in userspace through OHM, and others which are determined
> > by the kernel.
> > 
> > Presumably the cpuidle code would kick into XO specific code at some point
> > which would check that all of the other suspend inputs are green before
> > doing the deed.  The funny thing is that this isn't so dissimilar from how
> > ACPI works.
> 
> Right, and at that point, we're not doing "cpuidle", we're doing full
> system state assesment and I don't think doing that in the kernel in
> the middle of the idle loop is the best thing to do and we would probably
> have to add a lot of interfaces into the kernel to manage all that
> information. We could alternative add a callback into a userpsace helper
> in an OLPC-specific cpuidle governer but jumping back into userspace
> from this deep in the idle path is probably very unsafe to do. The
> simplest thing to do would be to have our device present a state that
> has a very long latency value corresponding to full system suspend
> so that the existing framework can just work. I'm not sure how
> well the kernel would handle us triggering a suspend from within
> the kernel either, but only one way to find out. :)

I said that we needed to walk down a decision tree, but I didn't say
that the idle detection needed to be the first branch.  Certainly,
we can do much of the math in userspace, and perhaps we can turn it
into a binary (allow_suspend && enough_time) in the idle loop or
appropriate hook.  But if we want to suspend on idle, then we need to
do it while are... you know... idle - so something  has to live there.

I think we are basically saying the same thing here - userspace needs
to give us the go-ahead to suspend, and we need to have the right
latency programmed so that if all is well, we just suspend.  Or at least,
we'll try to suspend and hope like heck it works.

Jordan

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Greg Smith Weekly Report, Week Ending 10/31

[Greg Smith]

The technical miniconference (AKA XO Camp) has been rescheduled from
November, 2008 to early January, 2009. The agenda and exact dates are
under construction at: http://wiki.laptop.org/go/XOcamp_2

Future feature requests and roadmap goals are being collected at:
http://wiki.laptop.org/go/Feature_roadmap

This page collects all well motivated feature ideas without regard to
priority. After a period of brainstorming and discussion, we will choose
the most important and update them with more detail (i.e. requirements
and specifications). Then we will scope the work effort for each and
pick target releases. Some features will take longer than one release to
deliver.

Feature requests by country are tracked at:
http://wiki.laptop.org/go/Feature_requests

The two pages will be tied together so that every feature has one or
more countries identified as target users.

*

Status of last weeks goals:

1 - Update Feature Roadmap page: http://wiki.laptop.org/go/Feature_roadmap
Get everything on the page (especially field input gathered this week).
Work with engineers to move their stuff up to main requirements section
and start adding specifications. Add more details in countries section.
Prepare to link country requests to requirements.

GS - Partially done. Thanks to Eben, the feature roadmap page was
redesigned! Many features were added and country requests were updated
with input from people who spent time in Ethiopia, Rwanda, Haiti, and
Peru. Please add your well defined and/or user motivated feature
requests to the page. For engineers, please move your ideas up from the
Priorities_from_Engineering section so that every piece of work has a
place in the roadmap. Include links to e-mail threads or other web pages
as needed and try to separate requirements (what it should do for the
user) and design/specification (what it actually will do in terms of
interface and how it can be coded).

2 - Make first pass agenda for Mini-conference. Update proposals page as
needed: http://wiki.laptop.org/go/XOcamp_2

GS - Partially done. The miniconference has been postponed to early
January. We reviewed 1/2 the conference proposals and will do the rest
next week.

3 - Update deployments page. http://wiki.laptop.org/go/Deployments

GS - Done. I updated the status of all the large deployments. Smaller
ones are still listed but not updated.

4 - Start writing detailed use cases, complete ideas for using XO/XS
(probably a requirements definition for supporting "learning projects"),
and presentations for mini-conference.

GS - Not done. Started a brief thread on asynchronous collaboration but
haven't gotten to real requirements or use cases yet.

*
Goals for next week.
1 - Continue prioritization of Mini-conference proposals and start
filling in next level of detail for each.

2 - Update roadmap page: http://wiki.laptop.org/go/Feature_roadmap
Follow up with deployments to verify priorities. Get a second level of
detail from deployments on what they need.

3 - Start writing detailed use cases, complete ideas for using XO/XS
(probably a requirements definition for supporting "learning projects"),
and presentations for mini-conference.

Thanks,

Greg S

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: GCompris bundle download is disabled

[Bruno Coudoin]

I have now an account at dev.laptop.org and moved the bundles there.
The olpc GCompris wiki page now direct downloads there.

Thanks everybody for your help and patience.


-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO

[Richard A. Smith]

Jordan Crouse wrote:

> appropriate hook.  But if we want to suspend on idle, then we need to
> do it while are... you know... idle - so something  has to live there.
> 
> I think we are basically saying the same thing here - userspace needs
> to give us the go-ahead to suspend, and we need to have the right
> latency programmed so that if all is well, we just suspend.  Or at least,
> we'll try to suspend and hope like heck it works.

I appear to have completely the wrong idea of what cpuidle would do for 
us then wrt suspend decisions.  I thought that cpuidle had the ability 
to report that the _system_ was idle.  For example if we are doing lots 
of DMA the cpu usage is very low but the system is far from idle.  Only 
the kernel has the proper knowledge of everything thats going on under 
the hood.

Where the ultimate decision to suspend is made doesn't seem to so 
important as the getting the inputs to that decision correct.  We don't 
appear to have a plan on how to get all the inputs.  Do we?

Thats what I'm proposing as one of the first steps and I was starting 
with cpuidle (perhaps incorrectly).  Replacing the current simplistic 
decision with something that we can mold into the Right way.  If cpuidle 
can't give us all the kernel info then we need start thinking about what 
can.

-- 
Richard Smith  <[EMAIL PROTECTED]>
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO

[Deepak Saxena]

On Nov 03 2008, at 17:11, Richard A. Smith was caught saying:
> Jordan Crouse wrote:
>
>> appropriate hook.  But if we want to suspend on idle, then we need to
>> do it while are... you know... idle - so something  has to live there.
>>
>> I think we are basically saying the same thing here - userspace needs
>> to give us the go-ahead to suspend, and we need to have the right
>> latency programmed so that if all is well, we just suspend.  Or at least,
>> we'll try to suspend and hope like heck it works.
>
> I appear to have completely the wrong idea of what cpuidle would do for  
> us then wrt suspend decisions.  I thought that cpuidle had the ability  
> to report that the _system_ was idle.  For example if we are doing lots  
> of DMA the cpu usage is very low but the system is far from idle.  Only  
> the kernel has the proper knowledge of everything thats going on under  
> the hood.

So CPUIdle can theoretically do things like change cpu idle states 
based on DMA latency requirements that are programmed via the
new PM QOS interface; however, that interface is not too well 
defined. 

I just had a conversation with one of the TI-OMAP Linux developers 
and they have hooks in their CPUidle code to detect bus master 
activity to determine what state they can be in. On their end
this is done by using the clock framework in the kernel to see
if any bus master devices are in use and whether it is safe to 
go into full idle state (C6, which on their chip is == OFF).

We could do something similar by having a C state that is full suspend
and doing simple checks like "is the audio device open", but this requires 
trusting applications to not open a device and just keep it open while it 
is not in use. Or we could add a "cpuidle" state to /sys/power/state 
and when OHM knows that it is safe for us to suspend on idle, it can write 
that to the file.

> Where the ultimate decision to suspend is made doesn't seem to so  
> important as the getting the inputs to that decision correct.  We don't  
> appear to have a plan on how to get all the inputs.  Do we?

No we don't and I really need to help out with the kernel side of things 
but I'm not sure I knows all the requirements and use cases which is the 
first step.  We need to list out all the decision criteria then figure out:

1. Where that information is currently stored
2. Where it needs to go for the suspend decision (OHM, an in-kernel structure, 
?)
3. How to get it there (uevent, in-kernel callback, userspace helper, ?)

~Deepak

-- 
 Deepak Saxena - Kernel Developer, One Laptop Per Child
   _   __o   (o>
---\<,  Give One Laptop, Get One Laptop  //\
 - ( )/ ( )  http://www.amazon.com/xoV_/_

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: ACPI on XO (or rather, how to use cpuidle on XO)

[John Gilmore]

Last time I took a deep look at this stuff, my design for using cpuidle
on the XO was for the kernel cpuidle framework to awaken a user daemon
at appropriate times.  The daemon would decide whether to suspend.

The interface I was designing would have a cpuidle kernel file that
ohm could write a number of nanoseconds into.  Ohm would then block
(or select, or poll) on a read from a cpuidle file that would only
return data when no process was scheduled to awaken in fewer than that
many nanoseconds.  It would return the actual delay until the next
kernel or process timer wakeup.

Thus:

  echo 20 >/sys/cpuidle/nslatency
  cat 
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Measuring and using CPU idleness in Ohm
Date: Tue, 11 Dec 2007 22:25:02 -0800
From: John Gilmore <[EMAIL PROTECTED]>

Before you started in on ohm, I had cherry-picked the Linus cpuidle
patches into the OLPC kernel with minimal trouble, and had it
compiling.  But the hard part was trying to hook it into the existing
OLPC suspend infrastructure; I never got even close to making that work.

Now that Ohm is being the "management" that decides when to suspend, I
suggest it'd be easy to write a little cpuidle interface that would
let Ohm measure demand for the CPU.  This would let it make reasonable
decisions about suspending and awakening, in the presence of CPU load.
Cpuidle wouldn't need to suspend; it would just need to inform Ohm.

I suggest an interface like this:

  /sys/.../cpuidle/latency

Write a value to "latency" to tell cpuidle the shortest delays you care
to hear about, in nanoseconds.

  /sys/.../cpuidle/idle

Read this when you want to sleep until the system is idle for a minimum
of "latency" nanoseconds.  It will return you the actual delay until the
next scheduled timer event.

So, merely looping reading "idle" will let you report or log the periods of
idleness that occur.  This will tell you what kind of performance tuning
needs to happen to other parts of the system to reduce wakeups.

Note that if any process has a read pending on "idle", the CPU will
not actually go idle; it will schedule that process.  When that process
goes idle (assuming nothing else happens in the meantime), then the system
will truly be idle.

This interface doesn't generalize well to multiple processes using it.
For example, say you want to have a process that scrubs memory for
ECC, (or scrubs the flash for ECC), but only takes idle cycles.  You'd
like to be able to have a few such things that wouldn't interfere with
each other.

Each would need a separate latency setting.  They'd all be sleeping,
awaiting idleness; the kernel would run one of them.  If-and-when it
goes idle again, re-evaluate which one to wake next.  You obviously
don't want it to run the same one again and again.  Hmm...  If it goes
idle by re-entering a read() of "idle", then you go on to a different
one (you won't reawaken the same process that just said "I want to
wait til the system is idle").  If it goes idle any other way (e.g. by
writing to /sys/power/state, or by sleep(), a network read, or
exit()), it's no longer in the chain of processes hung awaiting
"idle", so naturally cpuidle would trigger a different one.  

Perhaps the API should be that each process merely opens a single file
descriptor ("idle"), writes a latency to it, and reads from it to
await idleness and view the available latency.

It's not clear to me what decision the kernel should make if, say, it
has three processes waiting, with latency settings of 100, 1000, and
5000 ms.  If the next timer event is 6000 ms away, do you trigger the
lowest, the highest, or one at random?  For ohm's purposes it won't
matter (it'll be just one process), but the kernel developers can haggle
over this as it goes upstream.

In order to make ohm's automatic suspends work with the timer queue, I
think there should also be an additional value that can be written to
/sys/power/state.  Besides "mem", there should be "timed".  This will
suspend the system only until the next wakeup in the timer queue.
(The kernel would have to ask the EC to wake it, since the RTC is
almost useless, and the normal timers are powered down; but I think
Richard has already implemented that.)  Having the next timer event be
queried directly in the suspend code would eliminate race conditions
and other forms of wasted time.  (Of course, if Ohm itself wants to be
awakened at any particular interval or absolute time, it just needs a
thread that sleeps for that period of time; then Ohm will be in the
timer queue along with everything else.)

These low-impact kernel changes should allow Ohm to decide when to
suspend the CPU when truly idle; and do so safely.

(We'd still eventually want a whole pile of improvements to the
900+-ms kernel suspend code, but that's already known and in trac.)

John





Message-Id: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Fixing suspend
Date: Tue, 11 Mar 2008 01:5

Re: ACPI on XO

[John Gilmore]

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Game keys

[Richard A. Smith]

[EMAIL PROTECTED] wrote:

> 
> I want to find out what the scancodes are, so that I can then document how 
> to get them mapped to keystokes via some mechanism similar to the kernel 

http://wiki.laptop.org/go/Ec_specification#KeyCodes_for_Buttons

-- 
Richard Smith  <[EMAIL PROTECTED]>
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Issue with build 767 or new firmware, fail keyboard test

[Mitch Bradley]

> From: "John Mark" <[EMAIL PROTECTED]>
> Subject: Issue with build 767 or new firmware, fail keyboard test
> To: [EMAIL PROTECTED]
> Message-ID:
>   <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys,
>
> I run a support gang member and I run a XO repair in Miami, FL.
>
> I don't know if it's a known issue already but whenever I do a XO self test
> on new build or firmware (I don't know if it runs from firmware or build) it
> doesn't get to the keyboard test.
>
> After the mouse test passes, it gives me an error
> "Invalid opcode" and the XO shuts down.
>   

http://dev.laptop.org/ticket/8451 , particularly comment # 5.

It's fixed now, as of Q2E19 (but don't use that version; go directly to 
Q2E21, which is better in every way).

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel