Hello Jasmine, Please see responses in-line.
On Sunday 21 October 2012 04:13 PM, Jasmine Hassan wrote:
> On Sun, Oct 21, 2012 at 11:07 AM, Ritesh Raj Sarraf <r...@researchut.com>
> wrote:
>> The problem seemed to be caused because we were exiting if LMT was disabled
>> in the config file. Attached patch should help improve your use case.
>>
> Yes, that is one of the problems. If I may suggest, to be more user-proof:
> change:
> echo "$ENABLE_LAPTOP_MODE" |grep y
> to:
> echo "$ENABLE_LAPTOP_MODE" | egrep -i "(y|1)"
Done. THanks.
>
> Though, there's no /etc/default/laptop-mode installed on debian by LMT 1.61-1
Yes. I noticed that too. It seems to be an old leftover. And I see no
reference of it being installed in the distro-neutral install.sh file also.
> I had more issues with the default udev rules file added by LMT.
> For that, I had overridden it in
> /etc/udev/rules.d/99-laptop-mode.rules, with comments, as I intended
> to report this to you as well (way back) and totally forgot.
>
> # /lib/udev/power-lmt-udev runs both lmt & pm-powersave
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0",
> RUN+="/lib/udev/power-lmt-udev"
> SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1",
> RUN+="/lib/udev/power-lmt-udev"
>
> # Laptop-mode-tools default rules below, and reasons for disabling them
>
> # This generates 2 events, running script(s) twice. No good!
I am aware that udev generates too many events for the same subsystem.
Not just that, imagine different subsystems (power, hardware etc)
generating events that interest LMT, all at one go. We do not want to
honor every event.
The way LMT works, at any given time it will only honor 2 events in a
window on 10 seconds. There are 2 locks that LMT uses. A request lock
and an invocation lock. Every invocation first needs to acquire the
request lock, then try to acquire the invocation lock for the actual
invocation. When the invocation lock is acquired, the request lock is
released to honor further events. But only 2 locks. While the 1st event
is busy with the invocation lock and the 2nd events has acquired the
request lock, no further events will work. They will try to acquire the
request lock and fail.
>
> => LMT is also adding hooks for acpid in /etc/acpi/(actions|events)
> and hooks for upower in (/etc/power/scripts.d|events.d) and even hooks
> for the antiquated apmd in /etc/apm/event.d/ , even though it's not
> even installed on my system.
>
> i.e. All over the place. This caused me some grief.
> udev+acpid+upowerd. Quite excessive I must say.
> I had to edit each of the three lm_* files in /etc/acpi/events/, and
> comment out the two lines in each of them.
Yes. That's because we have multiple ways of being invoked. We started
with acpid, then later added support for pm-utils resume, and now are
totally independent with the help of udev. But we don't want to break
compatibility with older tools.
On my box, both acpid and pm-utils are uninstalled. I don't see this to
be a problem. Even if they are installed, like I mentioned above, not
all invocations will be honored.
>
> So, can't this be better managed via a postinst script? Say it would:
> 1. detect available facilities (pm-utils/udev/acpid/upowerd/apmd),
> pick one and only one, based on an ordered LMT preference list. Warn
> the user if none of the recommended facilities are installed/enabled.
> This could be later fixed by the user via dpkg-reconfigure
> laptop-mode-tools, or whatever.
What about scenarios where acpid/pm-utils etc are installed after LMT ?
Also, as upstream, it is simpler to just install the hooks and let the
installed daemons do the interpretation.
> 2. create symlinks to a common startup directory, say
> /usr/share/laptop-mode-tools/startup-hooks/*, for event/script hooks
> applicable to the chosen, available facility.
>
>> With ENABLE_LMT=1, we get
>>
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode enabled
>> active [unchanged]
> N.B. in my pre-last email I attached a little patch that amends this
> output. I really disliked getting two separate lines for each LMT
> invocation in my pm-* logs, for only a few words.
I will fix this.
> The warning about board-specific conf is also quite annoying. What use
> is "board-specific", as a (non-existent by default) sub-directory of
> "conf.d", if "conf.d" itself already serves the purpose of a dynamic
> user-configuration-include directory? There's also no mention of it in
> the laptop-mode.conf manpage.
This one too.
>> With "enabled" file removed, it shows:
>>
>> rrs@champaran:~$ sudo rm /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> disabled,
>> not active [unchanged]
>>
>> So it just disabled LMT because it was not "enabled".
>>
>>
>> And if "enabled" is set again, things go right.
>>
>> rrs@champaran:~$ sudo touch /var/run/laptop-mode-tools/enabled
>> rrs@champaran:~$ sudo /usr/sbin/laptop_mode auto
>>
>> Warning: Configuration file /etc/laptop-mode/conf.d/board-specific/*.conf is
>> not readable, skipping.
>> Laptop mode
>> enabled, active
>>
> Doesn't this fundamentally conflict with the purpose of "auto"?
> Per the laptop_mode man-page:
> auto Enable or disable laptop mode based on the current power
> state. Note that this will not do anything if the laptop-mode service
> has not been started!
I would prefer this change some time. The init service assumption is not
serving much.
>> There are 2 items to fix.
>>
>> * Invocation
>> * Status
>>
>> If you have time, you can review the patch and do some tests. Let me know.
>>
> And laptop_mode cleanups.. At the very least, lots of very old,
> deprecated "backwards-compatibility" stuff needs to go.
>
> I'm sorry, but overall, I really don't like the current state of LMT.
> And although I have all power-management stuff scripted in a pm-utils
> power.d script, I still find LMT useful for the disabling of
> data-sensitive feature and the (system-level) auto-hibernate at
> configurable low and critical battery levels (without polling)
> feature.
>
> LMT needs much more love than the patch you propose.
>
> Hope I'm not being too harshly critical.
>
>
:-)
Not really. If you have the interest, you can submit a patch too.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
