]> org.freedesktop.UPower.QoS is a DBus interface implimented by UPower. It allows applications to request latencies, for example a couple of seconds for an IM application, or a few hundred microseconds for a multiplayer game. Use cases: I want my IM application to request 0.5s latency for messages. I'm running an OpenGL simulation and want maximum performance, even when on battery power. I'm running an SQL server for a credit card company, and want the server to request low latency CPU and network as any delay costs money. I'm an admin, and want to change the power consumption vs. latency from cron scripts so it uses high latency during the night for maximum power saving, and low latency during business hours. I want high throughput when copying files, but want low throughput for downloading updates in the background. I want my power manager to set all latencies to lowest when on AC power. I don't want my users messing with latency settings. I'm and admin and I want to be able to override all latency settings on my machines. Why don't applications use the PMQoS interface directly? By providing a framework we can override requests by policy, and also control requests from random services. You also can't set latencies unless you're the root user, which is not suitable for the desktop use case. Of course, you can do if you really want, but then you loose the benefits of the query interface and the policy override, and have to run your application as root. The type of latency to control, cpu_dma or network. The value, in microseconds or kilobits per second. The value -1 means unset and the default is used. Set the minimum acceptable latency of the system. Setting this value tells the system to not attempt latencies below this setting. This may be useful in a data center or server room, when you want to override the latency requests from applications. This may be required if the server room is operating outside a standard thermal or power envelope, and an override is required. You do not have to use this method during normal operation. Callers need the org.freedesktop.upower.qos.set-minimum-latency authorization if an error occured while setting the latency The type of latency to control, cpu_dma or network. The value, in microseconds or kilobits per second. The value -1 means remove all latency requirements. If the latency request outlives the connection. When the application issuing the request disconnects from the system bus, the latency request is automatically cleaned up. By setting this flag to TRUE, the request is not cleaned up when the client disconnects, and the cookie is preserved acress reboots. A cookie that identifies the request. This allows an application or service to request multiple latency settings from one process, and for other processes to cancel requests. Set the required latency of an application or service. Callers need the org.freedesktop.upower.qos.request-latency-persistent authorization if persistent is TRUE, or org.freedesktop.upower.qos.request-latency otherwise. if an error occured while setting the latency A cookie that identifies the request. This allows an application or serivice to request multiple latency settings from one process. Cancel the latency request from the application or service. Callers need the org.freedesktop.upower.qos.cancel-request authorization if they were not the one issuing the request. if an error occured while clearing the latency The type of latency to return, cpu_dma or network. The value, in microseconds or kilobits per second. The value -1 means not set or unavailable. Get the lowest latency state on the system at the current time. if an error occured while getting the latency The type of latency that changed, cpu_dma or network. The value, in microseconds or kilobits per second. The value -1 means not set or unavailable. Some latency value has changed. The request lists, where each application can request different latency types. cookie The random cookie that identifies the request. uid The user ID that issued the request. pid The process ID of the application. exec The executable that issued the request. timespec The number of seconds since the epoch. persistent If the request is persistent and outlives the connection lifetime. type The type of the request, cpu_dma or network. value The value, in microseconds or kilobits per second. Gets all the system requests from all services and applications. The latency requests on the system have changed.