Sascha Silbe <si...@activitycentral.com> writes: > The type of the 'value' parameter of the LatencyChanged signal is > integer, not boolean. Fixing this causes the signal to actually be > emitted.
CancelRequest is broken in a similar way; calling it will cause UPower
to segfault.
The documented interface [1] is to pass the latency "type" along with
the cookie:
CancelRequest (in 's' type,
in 'u' cookie)
However, UPower internally uses only the cookie value (and generates
cookies unique across all latency types, not just a single one) and
doesn't expect the type to be passed:
void
up_qos_cancel_request (UpQos *qos, guint cookie, DBusGMethodInvocation *context)
The most straightforward way to fix this would be to add the type string
to the up_qos_cancel_request() signature and simply ignore it in the
body. However I wonder whether it wouldn't be better to change the
public API, dropping the type parameter from the CancelRequest
signature. AFAICT it never worked, even in DeviceKit-Power, so there are
no compatibility issues.
Sascha
[1] http://upower.freedesktop.org/docs/QoS.html#QoS.CancelRequest
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
pgpkSDzFaLBnM.pgp
Description: PGP signature
_______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
