When requesting fewer history elements than we actually have, fix the
interpolation loop to not reverse the returned elements; this already does not
happen if we request more elements than available, which led to the returned
list order depending on the history size.
Now the first array element is always the most recent one. Update documentation
accordingly.
Add test case to reproduce the problem. We now add three sample points to be
able to request a subset and still assert its correct order, and make the
charge values be further apart to ensure correct interpolation.
https://bugs.freedesktop.org/show_bug.cgi?id=68384
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>
Many Android devices only export charge_full and capacity, but not charge_now
or energy_now. In that case, directly read the percentage (from the capacity
attribute) and calculate current energy from that.
Thanks to Seth Forshee for the original patch!
https://bugs.freedesktop.org/show_bug.cgi?id=68337
Udev rules may live in either /lib/udev/rules.d or /usr/lib/udev/rules.d depending on the distro.
Remove the heuristic for deciding the dir, use pkgconfig to detect the location and allow it to be
set manually.
v2: fix specifying --with-udevrulesdir
Signed-off-by: Richard Hughes <richard@hughsie.com>
For non unifying receiver we were trying to locate receiver hiddraw
device by looking into INTERFACES property. This doesn't work well
for non-unifying devices from keyboard+mouse sets (which use single
dongle for 2 devices but are still non-unifying).
The only thing that's different between hiddraw receiver and other
devices (mouse, keyboard etc) is that receiver also exposes hiddev
interface.
Use that fact to reliably locate receiver.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
We are back to using HIDPP_FEATURE_ROOT_FN_PING for detecting protocol
since it's the official way described in [1].
Unfortunately unreachable devices ("disconnected" in logitech
terminology) don't respond to this v1 ping query as described in docs.
Seems that docs cover only reachable state reply for version checking.
Thus we have to consider HIDPP_ERROR_CODE_UNSUPPORTED to also be v1
(since we actually got some v1 valid answer - error reply).
Introduce HIDPP_REFRESH_FLAGS_FEATURES for checking features provided
by v2 device. This recheck is triggered when we upgrade from any
protocol to v2 in HIDPP_REFRESH_FLAGS_VERSION. This allows us to
properly upgrade from v0/v1 to v2 and also we don't send v2 queries
when we know that the device is v1.
[1] logitech_hidpp10_specification_for_Unifying_Receivers.doc
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Protocol version detection isn't very reliable (especially for
hid++ v1).
Version 1 checking was potentially happening in every hidpp_device_cmd()
call and not only when requested. Improve that to do version checking
and priv->version manipulation only when requested by using
HIDPP_REFRESH_FLAGS_VERSION.
When doing version checking first try v2 protocol command and if it
succeeds assume version 2 device. Otherwise try v1 protocol query
and if that successds assume version 1 device.
v2 devices in unreachable/sleep mode seem to do not respond to v2
queries but they respond to v1 queries! Still we want best protocol
possible. To do that we are rechecking version when current protocol
version is below 2 and we are doing up_device_unifying_refresh() and if
recheck succeeds we upgrade protocol to v2.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
There are Logitech Wireless devices similar to Unifying ones with the
difference that device is paired with single dongle and dongle doesn't
support pairing multiple devices.
Add support for these. Tested with Wireless Mouse M187 and M185/M225.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Set proper vendor via udev rules for unifying devices and handle
that in code.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Add support for checking device model name for hid++ v1 protocol
version.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Version 1 hid++ HIDPP_REFRESH_FLAGS_BATTERY packets were incorrect.
Response packets were incorrectly thrown away as invalid. These
packets have HIDPP_HEADER_REQUEST (and not HIDPP_HEADER_RESPONSE as code
expexted). Fix that by allowing both types.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
HIDPP_REFRESH_FLAGS_KIND action puts result into 7 bytes buffer and
later tries to access 8th element (with index 7). Make buffer bigger,
so 8th element will fit.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
HID++ version 1 was properly detected but that information wasn't
reaching caller.
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
udev v196 libraries changed behaviour of g_udev_device_get_sysfs_attr()
by stopping following symlinks for "device" attribute [1]. That change
broke hiddev finding for unifying devices. Fix that by getting sysfs
path from parent hiddev device.
1. http://cgit.freedesktop.org/systemd/systemd/commit/?id=5ae18ddc0d86673520c0dd6b59ccac8afc8aa605
Signed-off-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Richard Hughes <richard@hughsie.com>
logind is now being detected at runtime (see previous commit ff39d23), so we do
not need to link against libsystemd-daemon any more. Drop --enable-systemd
configure option as well.
Drop the two modes depending on whether or not the test gets run as root or
not. Set up a fake system bus and always use that. This also eliminates the
need for upowerd's --test option.
Drop usage of dbus-launch, as this leaves dbus-daemon running after the tests.
Use GioTestDBus instead, which cleans up properly.
Setting $SYSFS_PATH does not work any more with recent libudev versions, our
homwbrew sysfs sandbox building limits us to coldplug tests only. umockdev
works with both old and new libudevs and can also emulate uevents for future
hotplugging tests.
Skip the test if umockdev is not available, so that check and distcheck don't
bail out.
Over the years we've moved all the quirks to the kernel (and fixed most of the
issues properly) so on Fedora we've not actually been shipping any rules in
pm-utils for a couple of releaes now.
Dropping this functionality allows us to finally drop the pm-utils dep for upower.
This is turned off by default. If this is not set, then any calls to Suspend(),
SuspendAllowed(), Hibernate() or HibernateAllowed() will fail with an error.
The error mesage tells the user what new method to port to in logind.
I'm expecting to set --enable-deprecated for Fedora 17 and 18, but turn it off
for Fedora 19, so other distributions probably want to follow suit to find out
what other stuff needs to be ported to the new APIs early. GNOME should already
be fine, but KDE will need some solid porting as I understand it.
See http://lists.freedesktop.org/archives/devkit-devel/2013-January/001339.html
for more information on future plans and for rationale.
This can easily be done by doing #define UPOWER_ENABLE_DEPRECATED before
"#include <upower.h>" or adding -DUPOWER_ENABLE_DEPRECATED to the cflags line in
Makefile.am
See http://lists.freedesktop.org/archives/devkit-devel/2013-January/001339.html
for more information on future plans and for rationale.
In the days of low-power ARM devices and large laptop batteries, imposing a 20
hour plausibility limit on "time to full" is not appropriate any more. Bump it
to 240 hours to still keep a plausibility check against "factor 1000" errors.
https://bugs.freedesktop.org/show_bug.cgi?id=60110
The condition should be for energy_full, not energy, since we aim to find some
way of finding energy_full and energy_full_design irrespective of the way we
find energy.
https://bugs.freedesktop.org/show_bug.cgi?id=60104
Signed-off-by: Alex Hornung <alex@alexhornung.com>
I've recently got access to some spec on this, so I'm now able to document
his a bit better. Also, change the 0x78 value for the function sending
BattLightMeasureBroadcastEvent to 0x1 since this is the number of event we
want, and one is enough.
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Richard Hughes <richard@hughsie.com>
In recent kernels, hiddev* devices now have class "usbmisc", rather
than "usb" (see http://www.spinics.net/lists/linux-usb/msg62276.html).
This change translates into a change in SUBSYSTEM matching for hiddev*
devices. This fix addresses this for recent kernels while retaining
existing behavior. For reference, here is an attribute-walk for a
CyberPower CPS 1500C on kernel 3.7.0:
[Ubuntu bug #1091702: udev rules fail to match hid devices with new kernels]
udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/usbmisc/hiddev0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0/usbmisc/hiddev0':
KERNEL=="hiddev0"
SUBSYSTEM=="usbmisc"
DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0':
KERNELS=="4-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="usbhid"
ATTRS{bInterfaceClass}=="03"
ATTRS{bInterfaceSubClass}=="00"
ATTRS{bInterfaceProtocol}=="00"
ATTRS{bNumEndpoints}=="01"
ATTRS{supports_autosuspend}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"
looking at parent device '/devices/pci0000:00/0000:00:1d.2/usb4/4-1':
KERNELS=="4-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="0764"
ATTRS{speed}=="1.5"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="8"
ATTRS{busnum}=="4"
ATTRS{devnum}=="2"
ATTRS{configuration}==""
ATTRS{bMaxPower}==" 50mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="c0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bcdDevice}=="0001"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{version}==" 1.10"
ATTRS{urbnum}=="36"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="CPS"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="0501"
ATTRS{bDeviceClass}=="00"
ATTRS{product}==" CP 1500C"
looking at parent device '/devices/pci0000:00/0000:00:1d.2/usb4':
KERNELS=="usb4"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="0"
ATTRS{idVendor}=="1d6b"
ATTRS{speed}=="12"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{authorized_default}=="1"
ATTRS{busnum}=="4"
ATTRS{devnum}=="1"
ATTRS{configuration}==""
ATTRS{bMaxPower}==" 0mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="2"
ATTRS{bcdDevice}=="0307"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="0000:00:1d.2"
ATTRS{version}==" 1.10"
ATTRS{urbnum}=="50"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Linux 3.7.0-030700-generic uhci_hcd"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="0001"
ATTRS{bDeviceClass}=="09"
ATTRS{product}=="UHCI Host Controller"
looking at parent device '/devices/pci0000:00/0000:00:1d.2':
KERNELS=="0000:00:1d.2"
SUBSYSTEMS=="pci"
DRIVERS=="uhci_hcd"
ATTRS{irq}=="18"
ATTRS{subsystem_vendor}=="0x1028"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x0c0300"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,000000ff"
ATTRS{device}=="0x268a"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-7"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x021e"
ATTRS{numa_node}=="-1"
ATTRS{d3cold_allowed}=="0"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Richard Hughes <richard@hughsie.com>
