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>
This had support for Logitech devices working with an USB Unifying receiver.
This has been tested for at least the Logitech K750 solar keyboard, the M705
and the M505 mouses. Multiple receivers are also supported.
Signed-off-by: Julien Danjou <julien@danjou.info>
Signed-off-by: Richard Hughes <richard@hughsie.com>
This case was apparently overlooked when adding systemd support.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Richard Hughes <richard@hughsie.com>
When running under systemd, call into systemd for suspend and
hibernate instead of pm-utils. To capture resume events, install
a small script that gets executed by systemd after resume and
sends a dbus signal back to upower.
To make this work, the upower backends gain a new signal, ::resuming,
that they can optionally emit to signal that a resume happened.
Backends opt in to this by returning TRUE from up_backend_emits_resuming().
In this case, upower doesn't assume the sleep command to block until
resume, but instead waits for the ::resuming signal from the backend.
The only backend that uses this mechanism is the linux backend when
built with systemd support.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Fix NULL pointer comparison in up_device_supply_coldplug(). This caused
(lt-upowerd:5754): GLib-CRITICAL **: g_ascii_strcasecmp: assertion `s1 != NULL' failed
when a device does not have a "scope" sysfs attribute, and erroneously
considering that device to not power the system.
https://launchpad.net/bugs/1012578
Crash the daemon on any CRITICAL message, and also set WARNING and CRITICAL
messages to be fatal on the client side. On the server side we might have some
legitimate warnings, such as failing to load the config file from
/usr/local/etc (if you build a tree without passing correct --sysconfdir
options, etc.).
This exposes the current CRITICAL the daemon raises at startup. As with that
the daemon never starts up, fix the "wait for the daemon" loop to time out
after 10 seconds.
Some HID devices with batteries (like bluetooth keyboards) have been creating
power supply devices in sysfs since Linux 3.3.
UPower thinks that they are system devices and shuts down the system if they
get low. This is bad.
This is fixed in Linux 3.4, where there is a new 'scope' file that defines if
the device is powering the system.
Helpfully ACPI batteries don't populate the scope value, but soon will.
Add support for the scope attribute now, and default to system devices if it's
missing. Note, you need to be running a 3.4 kernel or a 3.3 with the patch
backported for this to work.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=806295
It's possible for the docked state of a laptop (i.e. the display
connectivity state) to change while the laptop is asleep.
Signed-off-by: Evan Broder <evan@ebroder.net>
Signed-off-by: Richard Hughes <richard@hughsie.com>
This reverts commit 14761c09d2.
The real reason for the failure is that Makefile.am calls the script with
"python" which is Python 2, but we need Python 3.
unittest.TestCase unfortunately does not have any public API to check whether
a test case succeeded, so we use the private self._outcomeForDoCleanups. This
does not seem to exist every time, so avoid a crash if it doesn't.
According to Anton Vorontsov (Linux power supply maintainer) power
supplies should not export a present property when they are not
hotpluggable and users of the properties should handle supplies
without present-property as always present.
This patch implements this feature using an additional
sysfs_file_exists call before sysfs_get_bool.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Spotted when running regression tests in KVM. There, initializing a HID device
causes a "could not initialize libusb: -99" warning, but the device is created
nevertheless. Do not crash in _finalize() by trying to call libusb_exit(NULL).
For hardware that has no rate data we use the differences in charge over a time
period to work out the effective rate. Using linear regression this estimation
is much more realistic.
To do this, introduce a simple circular buffer and use an index to calculate
the rate on each update.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Under Linux, regardless of the exit code of /usr/bin/pm-is-supported, it will
always set CanSuspend and CanHibernate to true due to a logic error in
up_backend_supports_sleep_state in src/linux/up-backend.c: The 'ret' variable
is re-used for the return code without being re-initialized to false after the
call to g_spawn_command_line_sync.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
So far the test cases only covered drivers which reported energy (µWh). Add
checks that the Energy* properties are correct, and add a test case for drivers
which report charge (µAh).
With nested Makefiles we can't depend on a generated file in a different
directory (breaks "make clean && make check"). Thus move the call of the Linux
integration test suite into src/Makefile.am, and only run it if we build the
Linux backend.
Implement get_{on,low}_battery() methods on HID devices for Linux. This will
treat discharging UPSes like batteries and set the "on-battery" and
"on-low-battery" properties accordingly.
This also fixes the test_ups_ac() case in the Linux integration tests.
Stop querying the global "on-battery" property when trying to guess the status
of a battery which reports as "unknown", as "on-battery" is itself defined in
terms of the states of the individual batteries. Instead, guess the state based
on whether we have any AC available; if so, we can reasonably assume
charging/discharging based on whether any AC is online. If no AC is present,
assume discharging (as we did before), but only if we have only one battery.
Stop guessing for the case where we don't have any AC device, "unknown" battery
state, and multiple batteries, as then we can't know which battery is currently
discharging.
https://bugs.freedesktop.org/show_bug.cgi?id=24371
If possible, run the tests under dbus-launch to ensure that there is a private
D-BUS session bus. This allows the tests to work in e. g. a clean package build
environment, and also avoids messing with the real user session bus.
Add src/linux/integration-test: This is a Python unittest based test suite
which provides methods for building a sandbox sysfs tree, runs upowerd
in it, and checks for correct properties.
As it is really hard to provide fake uevents, this currently only works for
properties which do not depend on dynamic system changes, i. e. you can
currently only check the status after coldplugging.
However, this already provides enough possibilities for functionality and
regression testing, and exposes some bugs with determining the "OnBattery"
property under certain conditions like the ones described in
<https://bugs.freedesktop.org/show_bug.cgi?id=24371>.
If any of the tests fails, the daemon log will be printed to stderr for easier
debugging.
With the previous commit that adds "upowerd --test", we can also run
the integration tests as non-root. If they are called as root, start upowerd
normally on the system bus, otherwise on the session bus with --test.
If a HID device is marked with the UPOWER_FAKE_DEVICE udev property, don't send
ioctl commands to it, but instead read status and percentage from udev
properties as well (UPOWER_FAKE_HID_CHARGING and UPOWER_FAKE_HID_PERCENTAGE).
This allows developers or a test suite to test the behaviour of UPSes without
actually having one.
More cleanly support batteries that report both energy and charge,
but do not report power_now. One battery driver in drivers/power
(bq20z75) supports reporting energy and charge natively from the
fuel gauge, but does not report power_now. The previous legacy behavior
would ignore the existence of charge and treat current_now as
being in units of power.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Richard Hughes <richard@hughsie.com>
Annoyingly, the device used in the Watts Up Pro device seems to be a generic
USB->serial adaptor, which means it doesn't have a unique vendor and product
ID. If we try to probe for the WUP device, we can actually upset other devices
that are not expecing to be probed. This fixes#33846 although we actually
still need to be more strict in detecting a true WUP device.
The GUdev API was declared stable in udev release 147.
Bump the version in the configure check and drop the
G_UDEV_API_IS_SUBJECT_TO_CHANGE defines.
Signed-off-by: Richard Hughes <richard@hughsie.com>
In up_input_coldplug(), some checks are done on the input device found in order
to detect if it's a lid switch or not.
The following one is problematic :
/* convert to a bitmask */
num_bits = up_input_str_to_bitmask (contents, bitmask, sizeof (bitmask));
if (num_bits != 1) {
g_debug ("not one bitmask entry for %s", native_path);
ret = FALSE;
goto out;
}
Checking if there's only 1 bit set is wrong. It's nice if you have a x86 with
acpi using 1 input device for the lid switch but it's not always nice.
One can create input devices with gpios-keys like this:
static struct gpio_keys_button keys[] = {
{
.code = SW_LID,
.gpio = ...,
.type = EV_SW,
.desc = "Lid Switch",
},
{
.code = SW_RFKILL_ALL,
.gpio = ...,
.type = EV_SW,
.desc = "rfkill",
},
};
The resulting SW bitmap will be 9 and thus there are 2 bits sets and due to the
mentionned check, the device is ignored by upower.
As a fix, I'm checking if the number of bits is between 0 and SW_CNT
bits.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Richard Hughes <richard@hughsie.com>
