Hi Jonas,
> > [...]
> > For that last point, I'd rather use:
> >
> > * does not guarantee that events sent to this client are continuous,
> > a compositor may change and reroute keyboard events while the grab
> > is nominally active.
> >
> > > hmm, and thinking about the last po
Some devices do not use dmi at all (this is the case on most non-x86
platforms, such as arm and arm64) but should able to select specific
quirks based on the input device name too.
This adds name-based input device detection without dmi to support
these devices.
Signed-off-by: Paul Kocialkowski
This series both introduces support for I2C Elan touchpads, thanks to
dmi-independent name-based input device detection and fixes the pressure
range on Elan touchpads (both PS/2 and I2C).
It applies on top of: touchpad: move the pressure range to a hwdb entry
from Peter Hutterer.
The initial prob
The high pressure value for Elantech touchpads (both PS/2 and I2C) is
not adapted to various devices, on which the touchpad is barely usable.
Decreasing the high value makes those devices usable again, while not
introducing any major drawback for other devices.
Signed-off-by: Paul Kocialkowski
-
This adds support for I2C Elan touchpads, such as the ones found in
various ARM CrOS devices. These devices do not use dmi.
The pressure range is copied as-is from the current Elantech PS/2
touchpads entry. It is not adapted to every touchpad configuration.
Signed-off-by: Paul Kocialkowski
---
On 9/9/16 10:16 PM, Bryce Harrington wrote:
Instead of creating a single global fade surface across all outputs,
create a separate surface for each output. This will permit
e.g. individual fades for each output (or blocking the fade-outs if
inhibiting idling as will come in a later patch.)
This
