Am Freitag, den 20.11.2009, 14:46 +0000 schrieb Graeme Gregory: > On Fri, 20 Nov 2009 15:39:41 +0100 > Michael 'Mickey' Lauer <[email protected]> wrote: > > > Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz: > > > Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth > > > napisał(a): > > > > > > > Better suggestions on how to achieve this are welcome. > > > > > > In distro config: > > > > > > MACHINE_FEATURES_om-gta01 = "this that those butnoapm" > > > > > > This way your distro has what you want and others have what was set > > > in machine config. > > > > Good idea. > > > > For the records though, I would consider it being the machine > > maintainer's call to define the machine config. If he decides that apm > > is very misleading on said machine, perhaps because without taking > > special care about the peripheral devices there will no be proper > > suspend in the first place, then I might be inclined to follow this > > reasoning and leave apm out there... > > > > That indicates to me that FSO is broken.
On the contrary, dearest friend. FSO is actually one of the few things which get suspend and resume right on these machines. > The last I checked any > application which has opened /dev/apm_bios can choose to hold off > the suspend until it has finished doing stuff(tm) It's not about /dev/apm_bios, it about cooperation with userland that needs to do certain things like configuring the modem and the gps devices to get the suspend to work in a deterministic way. If someone wants to write apm.d script that do the same, they can go for it and then enable apm per DISTRO or as Koen indicated, per TASK_APM. :M: _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
