USB PD 3.1 allows up to 240W (48V, 5A) and some proprietary supplies
already delivered more than 100W over USB-C (USB PD 3.0 limit).
Closes: #147
Reported by StefanBruens
If we want the computer to be able to take useful action about the low
battery, we should have a slightly higher "low" percentage level so that
power saving made really makes a difference in runtime.
Also bump "critical" slightly so that doom isn't quite as near but in the
distance nonetheless.
The "action" level stays the same, as 1% is too close to some batteries'
actual switch off point, eg. the computer might brown out before we see
1%.
The code in up_device_notify() will still eventually be reached when the
up_device_coldplug() implementations are called, and properties are set
for the device type for the first time (rather than during instance
construction).
Before, the low level for changing the battery icon was hardcoded.
However, as the `low_percentage` property is settable by the user using
`PercentageLow` option. That can lead to inconsistencies when PercentageLow
is not the default. For example, if PercentageLow is set higher than 10,
the Low Battery level warning will be sent at the user-set level, but the
battery icon would not be updated to "caution" until the percentage
drops below 10%.
This issue is solved in this commit by using the `low_percentage` property
for the comparison instead of hardcoding the default.
Make sure that the issue reported in #7 and #44 is fixed.
The mocked battery has a zero power_now attribute and a non-zero legacy
current_now attribute on purpose, to detect if upowerd tries to read
current_now if the power_now value is small.
Currently, if a power supplies' power_now sysfs file reports discharge
rates < 0.01 W, the code will try to calculate the discharge rate from
the legacy sysfs files. On new kernels where those don't exist, this
produces wrong results.
For example, on a dual-battery Thinkpad T450s, while the external
battery is discharging, the internal battery reports power_now = 0,
but the corresponding upower energy-rate field incorrectly reads
about 2.3 W.
This patch fixes the issue by falling back to the legacy code only if
the legacy current_now sysfs file exists.
Closes: #7, #44
Make Bluetooth devices for which we can't guess the "kind" or form
factor be "generic Bluetooth" devices, rather than "unknown" devices.
That should make it clearer in UIs that the devices are Bluetooth rather
than connected to the computer somehow.
Closes: #137
capacity is supposed to be the running battery percentage, not a
representation of its current state of the factory capacity (which
isn't something that's ever shown in Linux or macOS).
Use the new "ignore-system-percentage" property to work-around that
problem.
Closes: #141, #103
On some hardware, the "capacity" sysfs contains the capacity of the
battery when full compared to when it was new, instead of the percentage
of battery available.
Make it possible to ignore the "capacity" with this new property.
Those devices date back from the mid-2000s. If they still work, and
somebody is still interested in having them export their battery status,
we would recommend moving this information to the appropriate kernel
drivers.
It's really confusing seeing "not a switch [...]" when we actually
managed to find a switch, so throw 2 errors in the debug when both
checks fail, rather than as things are being tested.
src/up-input.c:294:3: warning: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Wimplicit-function-declaration]
294 | close (input->eventfp);
| ^~~~~
| pclose
Despite what the comments say, the device is indeed a valid input
device, it's just not one we want to add to the power devices,
as done in up-daemon.c's up_daemon_device_added_cb().
Rather than using the type of the first sibling device we find, which is
usually the pointing device portion, make sure that keyboard/pointing
device combo devices are identified as keyboards.
If an external keyboard with a backlight gets unplugged then
up_kbd_backlight_event_io would constantly get called, burning 100% CPU.
To make things worse, up_kbd_backlight_event_io would also constantly post
DBUS events, causing gnome-shell to also become very unresponsive.
This commit fixes this by returning FALSE from up_kbd_backlight_event_io
on unplug.
While at it also fix calling up_kbd_backlight_emit_change with a negative
brightness value in other error scenarios. Specifically this fixes
calling up_kbd_backlight_emit_change with -1 on the initial
up_kbd_backlight_event_io call in which case up_kbd_backlight_brightness_read
will typically fail with ENODATA.
