© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Ok, "here's a patch from an unmerged branch abandoned a year ago" isn't particularly reassuring. However, investigation reveals that an equivalent commit was merged to trunk and exists in 2.5.1: https:/
So, reverse-engineering the problem this is fixing:
* there exists a laptop with a firmware thermal table that contains a "motion" condition in each of its entries
* To determine the policy to apply thermald checks against each condition in each of the table entries. If it encounters a condition it does not understand, the check returns THD_ERROR (and presumably the check fails?)
* Since each entry of the firmware table on this laptop contains a "motion" condition, they are all rejected, and thermald instead applies the default "max power" policy.
* The patch implements a stub motion condition check - if the table specifies "motion = 0" then the condition is satisfied.
Am I correct in that understanding?
So the risk of regression here is mostly that thermald will *start working* on such laptops. Or, alternatively, if there is a laptop where *some, but not all* table entries contain a "motion" condition then this will be enabling extra policy options, which might be inappropriate?