The recalls for that broken batch of Sony batteries dates back from
2006. All the batteries that could have been recalled have now
been recalled, and somebody particularly interested in supporting
them can match the batteries using the old rules file, in a
user session or a separate daemon.
The full native sysfs path of wireless HID battery devices contains a lot of
jitter like USB tree layout or sequence numbers which change after every resume
from auto-suspend. Plus, there are kernel bugs which don't give proper remove
events for those: http://bugzilla.kernel.org/show_bug.cgi?id=62041
As device names within the same subsystem must be unique anyway, and we only
use the device name for constructing the D-BUS object path, only consider the
device name for the device list native → upower object lookup table, i. e. in
up_native_get_native_path().
This fixes the "A handler is already registered for <battery>" assertion crash
if a bluetooth device comes back from auto-suspend. This fixes the
test_bluetooth_mouse_reconnect() test case, drop the expected failure.
https://launchpad.net/bugs/1112907
When these power down, we don't get remove uevents for the original
power_supply devices from the kernel, but instead we get new devices with a
different sequence number, but the same name:
UDEV [6408.025124] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0001/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
UDEV [23785.90673] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12/0005:0D62:0558.0002/power_supply/hid-00:0f:f6:6d:8e:c0-battery (power_supply)
This circumvents the existing "treating add as change" check (as the native
path is different) but breaks later on when building and registering the
(supposedly) new object:
ERROR **: Failed to register GObject with DBusConnection: org.freedesktop.DBus.Error.ObjectPathInUse A handler is already registered for /org/freedesktop/UPower/devices/mouse_hid_000ff66d8ec0_battery
This reproduces https://launchpad.net/bugs/1112907
Don't just cover the test upowerd by umockdev-wrapper, but the test suite
itself as well, so that we can send uevents.
Do this by re-execing the test suite under umockdev-wrapper if it's not already
running under it.
Check the input subdevices of the bluetooth parent device of a battery, if
present. If there is mouse* input child device, is a mouse battery; otherwise,
it is a keyboard battery. This also fixes the PowerSupply attribute for these
to be false, as the batteries of wireless input devices don't power the system.
https://launchpad.net/bugs/1153488
Signed-Off-By: Martin Pitt <martin.pitt@ubuntu.com>
These should be detected with their proper type (5/6, not 2) and not count as
powering the system, i. e. their PowerSupply property should be False.
This reproduces https://launchpad.net/bugs/1153488
(1) If the K800 keyboard is charging via the USB cable, it will report
itself as Charging, but with a discharge level of 0 (which means
"unknown". In this case, the previous known value (before
connecting the cable) is always a better approximation than using
zero.
(2) When the K800 has fully charged (but with the cable still plugged
in), it will still report 0 as discharge level. "Full" is 100% by
definition, so let's fallback to that value.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
I previously followed the model example for copying part of the string,
but there is a much simpler way to build the name string using
g_strdup_printf. Note that a simple strdup() is not sufficient for model
since it does not have to be NUL terminated.
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Since "hidpp: split request read/write functions", the request buffer is
not used anymore while reading the response. Therefore the additional
buffer read_msg that was used for preserving the request buffer can be
discarded.
This patch also fixes printing the wrong response buffer (response would
always yield zeroes until the functions exits).
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
HidppMessage is currently of size 20 ("long message"). Since short
messages are always of size 7, do not bother printing the remaining 13
bytes. This code path is currently only used by hidpp-test (not
installed).
Reported-by: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Since commit b1f12feb1f ("Factor out the
Logitech Unifying support to support other devices"), the battery status
would always be reported as 1% for the K750 keyboard. Besides that, the
luminosity level was removed. This patch fixes the battery level and
re-adds the luminosity level.
To avoid negativity issues when reading light level into a double type,
make the HidppMessage params unsigned.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
When no report matches the report type or device, the previous code
did not terminate the loop early enough because the check was missed.
Now the timeout is always checked before attempting to poll.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
In preparation for reading notifications; the device index is now
also validated before using a message, this avoid matching the wrong
report.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
If read, wait or g_poll failed, it would return -1. This information is
not really useful, so print the error string instead where applicable.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Upon unplugging the USB receiver, the file descriptor of /dev/hidrawX is
not closed.
With commit "HID: hidraw: correctly deallocate memory on device
disconnect"[1] (queued for 3.12), this missing close() causes a
/dev/hidrawX devuce to persist until UPower is restarted.
On earlier kernels, never remove your USB receiver or you will
experience random errors resulting from data structures corruption[2]
(which occurs because UPower tries to poll() or read() an hidraw device
while the kernel has already released the memory for it). Not UPowers
fault, but UPower makes this bug more likely since it runs as daemon.
[1]: http://lkml.org/lkml/2013/7/22/248
[2]: http://lkml.org/lkml/2013/8/6/457
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Before this, history files were saved as history-rate-M525.dat. Since
multiple devices of the same model might be connected, this name is not
unique enough.
The serial number gives a more reliable path for the history files and
allows clients to distinguish their devices (an object path like
/org/freedesktop/UPower/devices/mouse_0003o046DoC52Bx0018 does not stay
the same).
Note: if a serial number cannot be read, instead of reverting this
patch, consider splitting the serial refresh from the version, kind and
model refresh.
- v2: Fix invalid return value when an invalid parameter is passed to
hidpp_device_get_serial.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
The device name and type can be queried from the receiver which does
not mind if a paired device is using HID++ 2.0 or 1.0. Therefore remove
the hidpp20-specific code which also removes indirection of an
uninitialised "map" variable.
The following code was buggy:
msg.feature_idx = map->idx;
...
map = ...;
if (map != NULL) {
...
}
...
priv->model = ...;
It should have become:
map = ...;
if (map != NULL) {
...
priv->model = ...;
}
... but since the HID++ 2.0 code is not necessary, just remove it.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
This includes "is-present" and "state" (which will be marked "unknown").
"percentage" is not touched since it is still an indication of the
battery level, changing it to zero is not helpful.
Previously, properties were never updated because the refresh would
fail when the battery refresh request failed.
- v2: fix invalid return value when an invalid parameter is passed to
hidpp_device_is_reachable.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Do not assume HID++ 1.0 when device is unreachable. This allows
up_device_unifying_refresh() to be optimized to stop sending a ping
message at every refresh for HID++ 1.0 devices.
priv->version will now always contain 0 when the real HID++ version of
a device is not (yet) known, comments are updated to reflect this.
Also fix an uninitialised msg variable that might confuse the error
handler in hidpp_device_refresh.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
When sending a ping request right after a device got paired, the ping
message gets lost (there is no response). Work around that by delaying
the initial packet exchange. 10 milliseconds seems to work, but let's
choose 30 ms to be fully safe.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
When the USB receiver is just plugged in, devices may not be active
("unreachable") and therefore return RESOURCE_ERROR on requests. This
causes upower to fail on picking up new devices. As a workaround, assume
that all discovered devices will eventually become reachable (even if
they don't, for example if the device was paired to another computer
while the computer carrying the receiver was powered off).
Actual removal of unpaired devices is done by the Logitech HID driver,
that should remove sysfs entries which can be detected by upower.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
The d7 battery register does not magically re-appear, therefore skip
this register once it is detected that the register is unusable.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
The HID++ 1.0 Illuminated Keyboard K800 does not support the d7
register, instead is uses 07. Its observed behaviour is documented in
the ltunify repository[1].
[1]: https://git.lekensteyn.nl/ltunify/tree/registers.txt
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Removed while refactoring hidpp_device_cmd, now that the message
validation is in place, introduce the 1.0 check again.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
This prevents the use of responses from other HID++ applications (such
as Solaar and ltunify).
- v2: do not hang in a loop when read() fails, e.g. when it returns EIO
because the device was unplugged.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
This prevents matching the wrong response packet, for example when
a mouse is moved while a packet is read. As a result, the reads are
more reliable and log spam is reduced.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Before this patch, there was no structure at all in the messages that
were passed around. Some issues:
- (debug) Every message of length 7 was considered a request (and
length 20 were seen as responses). This is not the case for HID++
1.0.
- The length of the message payload (ignoring the header) is fixed to 7
or 20, this was not considered in the previous code.
- The hidpp_device_cmd function contained special-case code for a HID++
1.0 response on a HID++ 2.0 ping request.
After this patch, the protocol message structure should be more
explicit. To be done:
- Test for HID++ 1.0 ping response (removed/broken by this patch).
- Validate responses, retry read if needed.
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Linux's power_supply class supports a temperature attribute, which is
supported by many battery drivers. Add a new property to export this
information and support this property in Linux.
https://bugs.freedesktop.org/show_bug.cgi?id=68338
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Martin Pitt <martinpitt@gnome.org>
