Re: 1.5 power management, input events, wakeup events
> > Would that mean that gnome-power-manager and DeviceKit-power > > would work as-is on the XO-1.5? > > I don't think we'd want to run gnome-power-manager because it would > attempt to do things like manage the backlight, which we want to do > ourselves as part of aggressive suspend/resume. But it would probably > mean that we could run it and it would be able to figure out what's > going on with our hardware, yes. Alot of the stuff that was in g-p-m is now moving to DeviceKit-power and its designed to be able to do also sorts of stuff with backlights etc and be more desktop agnostic and hence useful for servers and small devices. It might be worthwhile looking at that. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Jun 25 2009, at 09:49, Chris Ball was caught saying: > The complexity of implementation is real, but it turned out that Mitch > had to do the work of adding ACPI tables for Windows anyway. Being > able to suspend/resume on unmodified distro kernels (and not having to > constantly maintain and forward-port "the OLPC suspend/resume patch" > every release) will be a big win, worth some hours of our time in > setting up ACPI. I'd like to second Chris on the benefits of running something that is already well supported under Linux and allows us to use standard PM tools. One concern I have is whether ACPI provides the granular control over wakeup events that we desire. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
Hi, > Would that mean that gnome-power-manager and DeviceKit-power > would work as-is on the XO-1.5? I don't think we'd want to run gnome-power-manager because it would attempt to do things like manage the backlight, which we want to do ourselves as part of aggressive suspend/resume. But it would probably mean that we could run it and it would be able to figure out what's going on with our hardware, yes. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Thu, Jun 25, 2009 at 15:49, Chris Ball wrote: > Hi, > > > And we will pay the performance cost of ACPI? It was an > > oft-repeated thing that ACPI was evil because of complexity and > > slowness in the critical path to super smooth sleep-resume > > cycles. > > > Were we overestimating the impact? > > Yes, I believe so. We may even find that the slowness of some extra > indirection before making the same function call we would otherwise > make is not actually measurable. We'll find out in a week or two. > > The complexity of implementation is real, but it turned out that Mitch > had to do the work of adding ACPI tables for Windows anyway. Being > able to suspend/resume on unmodified distro kernels (and not having to > constantly maintain and forward-port "the OLPC suspend/resume patch" > every release) will be a big win, worth some hours of our time in > setting up ACPI. Would that mean that gnome-power-manager and DeviceKit-power would work as-is on the XO-1.5? Regards, Tomeu > - Chris. > -- > Chris Ball > ___ > 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
Re: 1.5 power management, input events, wakeup events
Hi, > And we will pay the performance cost of ACPI? It was an > oft-repeated thing that ACPI was evil because of complexity and > slowness in the critical path to super smooth sleep-resume > cycles. > Were we overestimating the impact? Yes, I believe so. We may even find that the slowness of some extra indirection before making the same function call we would otherwise make is not actually measurable. We'll find out in a week or two. The complexity of implementation is real, but it turned out that Mitch had to do the work of adding ACPI tables for Windows anyway. Being able to suspend/resume on unmodified distro kernels (and not having to constantly maintain and forward-port "the OLPC suspend/resume patch" every release) will be a big win, worth some hours of our time in setting up ACPI. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Wed, Jun 24, 2009 at 9:56 PM, Daniel Drake wrote: > The end-user interface for those is unlikely to change much (if we do > the ACPI tables right). And we will pay the performance cost of ACPI? It was an oft-repeated thing that ACPI was evil because of complexity and slowness in the critical path to super smooth sleep-resume cycles. Were we overestimating the impact? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 power management, input events, wakeup events
On Wed, 2009-06-24 at 15:08 -0400, Paul Fox wrote: > the input devices /dev/input/event[012] (which currently report > on power button, ebook, and lid events) are also implemented in > olpc-pm.c -- i'm not sure what their fate might be. The end-user interface for those is unlikely to change much (if we do the ACPI tables right). On any modern non-XO laptop run: cat /proc/bus/input/devices You'll usually see ACPI-backed input devices for the lid and power button. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
1.5 power management, input events, wakeup events
i was mildly surprised today in a conversation with chris ball when he implied that the contents of our current (gen1) /sys/power directory would probably be going away in 1.5. or, more specifically, he said that arch/x86/kernel/olpc-pm.c would be going away, and that the wakeup_events and wakeup_source mechanisms would be quite different. principally, the plan is apparently to rely on ACPI mechanisms where possible. the input devices /dev/input/event[012] (which currently report on power button, ebook, and lid events) are also implemented in olpc-pm.c -- i'm not sure what their fate might be. so: i'm hoping someone (deepak? chris?) can write up a sketch of how they think power management, those input devices, wakeup events, etc, will work on 1.5. direct comparison to 1.0 would be helpful. (and of course a tie-in to specific work-to-be-done and/or modules-to-be-written would be helpful too.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
