[CC'ing [email protected] because it touches operation of low-level software components on OLPC OS]
Paul Fox <[email protected]> writes: > the problem is that there's no good operating system mechanism that > powerd can use to know that audio is truly in use. > > it's possible to know that the audio device has been opened, and i > have tried using that in the past. but most applications that use > audio open the device once, and then leave it open. so even when > they're playing nothing but silence, the device appears to be in use. While there could (and maybe should) be a distinction between the audio device being a) opened by a process and b) in actual use for playback or recording, ALSA doesn't make that distinction [1] and a lot of commonplace hardware doesn't support more than one substream. As long as the device is open, no other process will be able to use the device. Whether we like it or not, this is the kernel-level ALSA API and if applications don't obey their side of the contract (closing the device to de-allocate resources) it's simply an application bug. I haven't dug into GStreamer enough to tell what its API looks like w.r.t. resource acquisition and how that translates into ALSA device usage, but powerd is only concerned about the kernel level and a number of well-behaving Activities show that there's no major roadblock ahead; in fact a close look at the Record source doesn't even reveal any obvious kind of hack. > regarding the other elements of this thread: it may be that system > mechanisms for inhibiting suspend via upowerd or gnome are now mature > enough to be of some use. this has never seemed to be the case in the > past. plus -- they're all, as far as i can tell, just as specific to the > power-manager-du-jour as the current powerd interfaces are. i.e., no > one has created a generic set of interfaces which can be implemented > in various ways behind the scenes. Yes, many of the Gnome APIs (remember, Sugar is built on Gnome components) are annoyingly specific to Gnome components. There are a number of cross-desktop environment APIs being worked on at freedesktop.org [2], but nothing related to session or power management is among them. The inhibit support of XSMP [3] is claimed [4] to be problematic, so no common base there either. When it comes to power management, we're living in a constantly changing world. Like with any standardisation effort, it will take a) someone to drive it and b) considerable time and effort to design and get people to agree on a common API. I've tried looking at what the APIs KDE uses for power management, but only hit a number of partially [5,6] or completely [7-9] broken API docs pages. What I've seen so far doesn't like any better or more cross-desktop environment than what Gnome does. Sascha [1] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver.pdf page 28 (page 21 using in-pdf numbering) [2] http://www.freedesktop.org/wiki/Specifications [3] http://www.x.org/releases/X11R7.6/doc/libSM/xsmp.html [4] http://live.gnome.org/SessionManagement/GnomeSession#Problems_and_Goals [5] http://www.purinchu.net/kdelibs-apidocs/solid/html/namespaceSolid_1_1PowerManagement.html [6] http://www.purinchu.net/kdelibs-apidocs/solid/html/powermanagement_8cpp_source.html [7] http://api.kde.org/ [8] http://api.kde.org/4.x-api/kdelibs-apidocs/ [9] http://api.kde.org/4.8-api/kdelibs-apidocs/ -- http://sascha.silbe.org/ http://www.infra-silbe.de/
pgpbhYCGjhnAG.pgp
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
