On a typical LCD, a black screensaver is actually worse for power
consumption than a normal screen, because it takes more energy to turn
the crystals opaque. Also, the intermediate DPMS states are essentially
useless and most monitors alias them to the 'off' state, so we may as
well do the same.
As a pleasant side effect, this brings the default DPMS timeouts in line
with the EnergyStar Program Requirements for Computers:
http://www.energystar.gov/index.cfm?c=revisions.computer_spec
which state that products must be "shipped with the display's Sleep mode
set to activate within 15 minutes of user inactivity".
These two defines were defined in C files but not used anywhere:
dix/window.c #define DeviceEventMasks (KeyPressMask | [...]
os/connection.c #define MAXFD 500
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This did access the wrong device's sync state, potentially freezing or not
thawing the actual device that was supposed to be thawed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is just for correctness. The server should return BadValue for anything
not in [-100, 100].
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replace multi-stage filtering with simple linear velocity,
tracked several instances backwards. A heuristic ensures
only approximately linear motion is considered, so velocity
remains valid in any case. Numerical stability is much
better, and nothing changes to people who didn't tune the
advanced features of the previous algorithm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
dixLookupResource attempted to automatically detect whether the caller
wanted a lookup by-type or by-class, unfortunately, it guessed wrong for
RT_NONE. Instead of trying to make the guess better, this patch just reverts
the unification and creates separate functions for each operation.
Only ever change the button map on the device we actually care about, not the
attached SDs, not the current MD of the device.
X.Org Bug 20122 <http://bugs.freedesktop.org/show_bug.cgi?id=20122>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Don't pass xEvent* and count through to processing, pass a single
InternalEvent.
Custom handlers are disabled for the time being. And for extra fun,
XKB's pointer motion emulation is disabled. But stick an error in there so
that we get reminded should we forget about it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the API change, we can now purge the XI conversion from POE.
Note: this commit breaks DGA even more.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
deviceGrab.sync.event is now an internal event, and CheckDeviceGrabs and
friends is changed over.
Note that this currently breaks some frozen grabs. See towards the end of
ComputeFreezes().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that we're only partially switched to internal events. The event in the
devices' event queue (dev->deviceGrab.sync.event) is still an XI event. The
events in syncEvents are InternalEvents only now.
This also implies fixing CheckVirtualMotion to work with internal events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Get rid of the deviceValuator processing and a few other things, but still
drop back into XI before checking device grabs or doing anything else.
NoticeEventTime now needs to take InternalEvents, and while we're at it,
change NoticeTime from a macro to a function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that this breaks DGA. Life is tough.
EnqueueEvent is a somewhat half-baked solution, we immediately drop back into
XI and store them. But it should in theory work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't let the dcce be random data.
Before dropping down into the DIX, convert back into XI events. This is a
temporary solution only, until the DIX is capable of handling InternalEvents
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
