[no description] http://git.sigexec.com/cgit.cgi/i3status.git/atom?h=2.12 2018-01-28T14:37:51+00:00 2018-01-28T14:37:51+00:00 johcgt 35880934+johcgt@users.noreply.github.com 2018-01-28T14:37:51+00:00 urn:sha1:d5c69a9d60a0bf9b6fbbaff7e122042410bfe44a `print_battery_info` computes `batt_info.percentage_remaining` by dividing batt_info.remaining by `full`. If `full` is `0` then the battery remaining will be reported as "inf". Before this, it tries to set `full` to either the design capacity or to the last known good charge. It determines if these values are available by checking whether their fields in `batt_info` are non-negative. As it initialized `batt_info` with values of `-1`, a non-negative value implies that something has provided a value. `slurp_all_batteries` and `add_battery_info` however initialize these fields to zero, so if these functions are called then `batt_info.full_design` will always be used. This means that on systems that don't provide a value for design capacity the percentage remaining will be reported as "inf", unless the user has set `last_full_capacity` to `true` in their `i3status.conf`. This patch changes `print_battery_info` to expect values for the battery capacity to be strictly greater than zero. This seems reasonable as a battery with a capacity of zero isn't useful. An alternative solution would be to change `slurp_all_batteries` and `add_battery_info` to initialize `batt_info` with `-1`, as `print_battery_info` does. This is less appealing as `add_battery_info` is accumulating the values, so using `-1` would introduce off-by-one errors without additional code to avoid them. 2017-11-20T18:51:48+00:00 Emeric Planet emeric.planet@datadoghq.com 2017-11-20T18:51:48+00:00 urn:sha1:6464ae2df9f784e7b657ed5e36923f2a3062356e 2017-08-29T17:01:30+00:00 Emeric Planet emeric.planet@datadoghq.com 2017-08-29T17:01:30+00:00 urn:sha1:884e4da6730a31fc7a5ef892fb9cb061baaf5f6c Support any amount of available cores on testing machine. 2017-04-13T19:46:21+00:00 Emeric Planet emeric.planet@gmail.com 2017-04-13T19:46:21+00:00 urn:sha1:c7dea747519f99584002084df3dce546f37df8b5 The Linux power supply class defines three entries to provide battery status. One of them wasn't used: POWER_SUPPLY_CAPACITY. https://www.kernel.org/doc/Documentation/power/power_supply_class.txt 2017-03-26T10:54:07+00:00 eplanet emeric.planet@gmail.com 2017-03-26T10:54:07+00:00 urn:sha1:94651257cea4ff419f9cf2143d93193d5a5ccb96 This change addresses the issue #199 asking for multiple CPU support. It takes an arbitrary CPU number and outputs its usage using the same arithmetics as for CPU aggregation. It currently doesn't support FreeBSD. 2016-11-19T14:02:10+00:00 eplanet emeric.planet@gmail.com 2016-11-19T14:02:10+00:00 urn:sha1:6f7724ec6425944a09ba6bd14828d1e2fd5b3467 2016-11-16T21:45:59+00:00 Michael Stapelberg stapelberg@users.noreply.github.com 2016-11-16T21:45:59+00:00 urn:sha1:b91e2a4b71911bf2767865580e519c93b26390e8 Provide format_above_threshold/format_below_threshold options 2016-11-15T11:34:06+00:00 Mihai Coman mihai.cmn@gmail.com 2016-11-15T11:34:06+00:00 urn:sha1:562f6e383d84e16ad3ff9d9c777c89e8150a924f 2016-11-14T21:33:09+00:00 eplanet emeric.planet@gmail.com 2016-11-14T21:33:09+00:00 urn:sha1:9c472405234789bec8ce522ecab025a208481fbe The valid test case assumes pid 1 exists, which should always be true on Unix environment. 2016-11-14T21:24:16+00:00 eplanet emeric.planet@gmail.com 2016-11-14T21:24:16+00:00 urn:sha1:243d08e1adc48898b3fb53484f00b68978fd685b