<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pm-Utils on RESEARCHUT</title><link>https://researchut.com/tags/pm-utils/</link><description>Recent content in Pm-Utils on RESEARCHUT</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>rrs@researchut.com (Ritesh Raj Sarraf)</managingEditor><webMaster>rrs@researchut.com (Ritesh Raj Sarraf)</webMaster><lastBuildDate>Tue, 15 Feb 2011 10:41:23 -0500</lastBuildDate><atom:link href="https://researchut.com/tags/pm-utils/index.xml" rel="self" type="application/rss+xml"/><item><title>laptop-mode-tools</title><link>https://researchut.com/post/158/</link><pubDate>Tue, 15 Feb 2011 10:41:23 -0500</pubDate><author>rrs@researchut.com (Ritesh Raj Sarraf)</author><guid>https://researchut.com/post/158/</guid><description>&lt;p>I just released &lt;strong>laptop-mode-tools&lt;/strong> version 1.56.&lt;/p>
&lt;p>This release adds many goodies. We now have a better calling application to
rely upon, &lt;strong>udev&lt;/strong>. The linux kernel generates many events based on
conditions. udev is a framework that acts on those events and can call-in
applications based on conditions. This is something I wanted to do for laptop-
mode-tools.&lt;/p>
&lt;p>&lt;strong>Power State&lt;/strong>&lt;/p>
&lt;p>First was power state. The power_supply subsystem can sense changes and
generate events. We simply act on the &lt;strong>change&lt;/strong> action here and call in
laptop-mode-tools because we want laptop-mode-tools run on both &lt;strong>ON_AC&lt;/strong> and
&lt;strong>ON_BAT&lt;/strong>&lt;/p>
&lt;p>&lt;strong>Suspend/Resume&lt;/strong>&lt;/p>
&lt;p>Suspend/Resume was my bigger concern. pm-utils no more likes us. In fact it
now has direct Conflict: defined in the Package Managers. For laptop-mode-
tools, on suspend, there was not much to care about. But I did want to ensure
that we act on resume because:&lt;/p>
&lt;ul>
&lt;li>User could suspend when &lt;strong>ON_AC&lt;/strong>&lt;/li>
&lt;li>Go back home&lt;/li>
&lt;li>Resume when &lt;strong>ON_BAT&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>The &lt;strong>machinecheck&lt;/strong> subsystem helped here. I hope my assumption that this
event in only seen during suspend/resume stands true.&lt;/p>
&lt;p>&lt;strong>Multi Events and Locking&lt;/strong>&lt;/p>
&lt;p>Acting on events is good but can be challenging because the kernel can
generate a large number of events and we have a danger of ending up spawning
just too many instances. &lt;strong>flock&lt;/strong> came to the rescue there.&lt;/p>
&lt;p>So overall, by depending on events, we are better now. We can cut down on many
dependencies. Especially the &lt;strong>Power Management Daemon&lt;/strong> dependency because
different arches had diffrerent managers.&lt;/p>
&lt;p>pm-utils conflict is disappointing especially for the fact that that conflict
is inherited in Debian too. I hope the pm-utils maintainer
&lt;a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710">reconsiders&lt;/a>.
Uninstalling pm-utils has the challenge that the DEs lose the suspend
functionality. Does anyone know how the DEs call them? Can a minor hacky
workaround be provided?&lt;/p></description></item></channel></rss>