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>
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 adds the luminosity property for devices able to recharge using light.
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.
GLib 2.33 and further deprecates GValueArray. However, we still need it as long
as we are using dbus-glib, so selectively disable the deprecation warnings for
the three functions that use GValueArray. This allows us to continue to build
with -Werror.
CancelRequest() never worked because the method signature in D-Bus
introspection data didn't match the actual function signature.
Since the 'type' parameter isn't needed by the implementation (cookies
are unique across all requests, not just requests of a certain type),
we drop it from the public API. This makes it easier for clients to
use the API as they only have to remember the cookie, not both cookie
and type. Since it never worked in the first place, there are no
backwards compatibility issues.
Signed-off-by: Richard Hughes <richard@hughsie.com>
up_qos_init() registers a destroyer callback for the qos item array,
so the current item will be gone after the calls to
g_ptr_array_remove(). By storing the item kind in a local variable we
can pass it to up_qos_latency_perhaps_changed() later. Delaying the
removal from the array is not an option as
up_qos_latency_perhaps_changed() scans that array to re-evaluate the
target latency.
Signed-off-by: Richard Hughes <richard@hughsie.com>
The type of the 'value' parameter of the LatencyChanged signal is
integer, not boolean. Fixing this causes the signal to actually be
emitted.
Signed-off-by: Richard Hughes <richard@hughsie.com>
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>
