Input: document the units for resolution of size axes

Today, the resolution of size axes is not documented. As a result, it's
not clear what the canonical interpretation of this value should be. On

Input: document the units for resolution of size axes

Today, the resolution of size axes is not documented. As a result, it's
not clear what the canonical interpretation of this value should be. On
Android, there is a need to calculate the size of the touch ellipse in
physical units (millimeters).

After reviewing linux source, it turned out that most of the existing
usages are already interpreting this value as "units/mm". This
documentation will make it explicit. This will help device
implementations with correctly following the linux specs, and will
ensure that the devices will work on Android without needing further
customized parameters for scaling of major/minor values.

Signed-off-by: Siarhei Vishniakou <[email protected]>
Reviewed-by: Jeff LaBundy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

HID: amd_sfh: Move bus declaration outside of amd-sfh

This should allow external drivers to reference this bus ID
reservation and detect data coming from amd-sfh.

Signed-off-by: Mario Limonciello <

HID: amd_sfh: Move bus declaration outside of amd-sfh

This should allow external drivers to reference this bus ID
reservation and detect data coming from amd-sfh.

Signed-off-by: Mario Limonciello <[email protected]>
Signed-off-by: Basavaraj Natikar <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

include/linux: remove repeated words

Drop the doubled word "for" in a comment. {firewire-cdev.h}
Drop the doubled word "in" in a comment. {input.h}
Drop the doubled word "a" in a comment. {mdev.h}
D

include/linux: remove repeated words

Drop the doubled word "for" in a comment. {firewire-cdev.h}
Drop the doubled word "in" in a comment. {input.h}
Drop the doubled word "a" in a comment. {mdev.h}
Drop the doubled word "the" in a comment. {ptrace.h}

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Stefan Richter <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Kirti Wankhede <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

Input: input_event - fix struct padding on sparc64

Going through all uses of timeval, I noticed that we screwed up
input_event in the previous attempts to fix it:

The time fields now match between

Input: input_event - fix struct padding on sparc64

Going through all uses of timeval, I noticed that we screwed up
input_event in the previous attempts to fix it:

The time fields now match between kernel and user space, but all following
fields are in the wrong place.

Add the required padding that is implied by the glibc timeval definition
to fix the layout, and use a struct initializer to avoid leaking kernel
stack data.

Fixes: 141e5dcaa735 ("Input: input_event - fix the CONFIG_SPARC64 mixup")
Fixes: 2e746942ebac ("Input: input_event - provide override for sparc64")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: input_event - fix the CONFIG_SPARC64 mixup

Arnd Bergmann pointed out that CONFIG_* cannot be used in a uapi header.
Override with an equivalent conditional.

Fixes: 2e746942ebac ("Input: inpu

Input: input_event - fix the CONFIG_SPARC64 mixup

Arnd Bergmann pointed out that CONFIG_* cannot be used in a uapi header.
Override with an equivalent conditional.

Fixes: 2e746942ebac ("Input: input_event - provide override for sparc64")
Fixes: 152194fe9c3f ("Input: extend usable life of event timestamps to 2106 on 32 bit systems")
Signed-off-by: Deepa Dinamani <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: input_event - provide override for sparc64

The usec part of the timeval is defined as
__kernel_suseconds_t tv_usec; /* microseconds */

Arnd noticed that sparc64 is the only architecture that

Input: input_event - provide override for sparc64

The usec part of the timeval is defined as
__kernel_suseconds_t tv_usec; /* microseconds */

Arnd noticed that sparc64 is the only architecture that defines
__kernel_suseconds_t as int rather than long.

This breaks the current y2038 fix for kernel as we only access and define
the timeval struct for non-kernel use cases. But, this was hidden by an
another typo in the use of __KERNEL__ qualifier.

Fix the typo, and provide an override for sparc64.

Fixes: 152194fe9c3f ("Input: extend usable life of event timestamps to 2106 on 32 bit systems")
Reported-by: Arnd Bergmann <[email protected]>
Signed-off-by: Deepa Dinamani <[email protected]>
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

input: add MT_TOOL_DIAL

A dial is a tool you place on a multitouch surface which reports its
orientation or a relative angle of rotation when rotating its knob.

Some examples are the Dell Totem (on

input: add MT_TOOL_DIAL

A dial is a tool you place on a multitouch surface which reports its
orientation or a relative angle of rotation when rotating its knob.

Some examples are the Dell Totem (on the Canvas 27"), the Microsoft Dial,
or the Griffin Powermate, though the later can't be put on a touch surface.

We give some extra space to account for other types of fingers if we need
(MT_TOOL_THUMB)

Slightly change the documentation to not make it mandatory to update each
MT_TOOL we add.

Reviewed-by: Peter Hutterer <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

Input: extend usable life of event timestamps to 2106 on 32 bit systems

The input events use struct timeval to store event time, unfortunately
this structure is not y2038 safe and is being replaced

Input: extend usable life of event timestamps to 2106 on 32 bit systems

The input events use struct timeval to store event time, unfortunately
this structure is not y2038 safe and is being replaced in kernel with
y2038 safe structures.

Because of ABI concerns we can not change the size or the layout of
structure input_event, so we opt to re-interpreting the 'seconds' part
of timestamp as an unsigned value, effectively doubling the range of
values, to year 2106.

Newer glibc that has support for 32 bit applications to use 64 bit
time_t supplies __USE_TIME_BITS64 define [1], that we can use to present
the userspace with updated input_event layout. The updated layout will
cause the compile time breakage, alerting applications and distributions
maintainers to the issue. Existing 32 binaries will continue working
without any changes until 2038.

Ultimately userspace applications should switch to using monotonic or
boot time clocks, as realtime clock is not very well suited for input
event timestamps as it can go backwards (see a80b83b7b8 "Input: evdev -
add CLOCK_BOOTTIME support" by by John Stultz). With monotonic clock the
practical range of reported times will always fit into the pair of 32
bit values, as we do not expect any system to stay up for a hundred
years without a single reboot.

[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Deepa Dinamani <[email protected]>
Acked-by: Peter Hutterer <[email protected]>
Patchwork-Id: 10148083
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

License cleanup: add SPDX license identifier to uapi header files with a license

Many user space API headers have licensing information, which is either
incomplete, badly formatted or just a shortha

License cleanup: add SPDX license identifier to uapi header files with a license

Many user space API headers have licensing information, which is either
incomplete, badly formatted or just a shorthand for referring to the
license under which the file is supposed to be. This makes it hard for
compliance tools to determine the correct license.

Update these files with an SPDX license identifier. The identifier was
chosen based on the license information in the file.

GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license
identifier with the added 'WITH Linux-syscall-note' exception, which is
the officially assigned exception identifier for the kernel syscall
exception:

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".

This exception makes it possible to include GPL headers into non GPL
code, without confusing license compliance tools.

Headers which have either explicit dual licensing or are just licensed
under a non GPL license are updated with the corresponding SPDX
identifier and the GPLv2 with syscall exception identifier. The format
is:
((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE)

SPDX license identifiers are a legally binding shorthand, which can be
used instead of the full boiler plate text. The update does not remove
existing license information as this has to be done on a case by case
basis and the copyright holders might have to be consulted. This will
happen in a separate step.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne. See the previous patch in this series for the
methodology of how this patch was researched.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

HID: sony: Report DS4 motion sensors through a separate device

The DS4 motion sensors are currently mapped by the hid-core driver
to non-existing axes in between ABS_MISC and ABS_MT_SLOT, because
th

HID: sony: Report DS4 motion sensors through a separate device

The DS4 motion sensors are currently mapped by the hid-core driver
to non-existing axes in between ABS_MISC and ABS_MT_SLOT, because
the device already exhausted ABS_X-ABS_RZ. For a part the mapping
by hid-core is accomplished by a fixup in hid-sony as the motion
axes actually use vendor specific usage pages.

This patch makes the DS4 use a separate input device for the motion
sensors and reports acceleration data through ABS_X-ABS_Z and
gyroscope data through ABS_RX-ABS_RZ. In addition it extends the
event spec to allow gyroscope data through ABS_RX-ABS_RZ when
INPUT_PROP_ACCELEROMETER is set. This change was suggested by
Peter Hutterer during a discussion on linux-input.

[[email protected]: rebase onto slightly newer codebase]
Signed-off-by: Roderick Colenbrander <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

HID: intel-ish-hid: ISH HID client driver

This driver is responsible for implementing ISH HID client, which
gets HID description and report. Once it has completely gets
report descriptors, it regist

HID: intel-ish-hid: ISH HID client driver

This driver is responsible for implementing ISH HID client, which
gets HID description and report. Once it has completely gets
report descriptors, it registers as a HID LL drivers. This implements
necessary callbacks so that it can be used by HID sensor hub driver.

Original-author: Daniel Drubin <[email protected]>
Reviewed-and-tested-by: Ooi, Joyce <[email protected]>
Tested-by: Grant Likely <[email protected]>
Tested-by: Rann Bar-On <[email protected]>
Tested-by: Atri Bhattacharya <[email protected]>
Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

Input: add BUS_CEC type

Inputs can come in over the HDMI CEC bus, so add a new type for this.

Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gm

Input: add BUS_CEC type

Inputs can come in over the HDMI CEC bus, so add a new type for this.

Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: synaptics-rmi4 - add support for Synaptics RMI4 devices

Synaptics uses the Register Mapped Interface (RMI) protocol as a
communications interface for their devices. This driver adds the core

Input: synaptics-rmi4 - add support for Synaptics RMI4 devices

Synaptics uses the Register Mapped Interface (RMI) protocol as a
communications interface for their devices. This driver adds the core
functionality needed to interface with RMI4 devices.

RMI devices can be connected to the host via several transport protocols
and can supports a wide variety of functionality defined by RMI functions.
Support for transport protocols and RMI functions are implemented in
individual drivers. The RMI4 core driver uses a bus architecture to
facilitate the various combinations of transport and function drivers
needed by a particular device.

Signed-off-by: Andrew Duggan <[email protected]>
Signed-off-by: Christopher Heiny <[email protected]>
Tested-by: Benjamin Tissoires <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Tested-by: Bjorn Andersson <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: evdev - add event-mask API

Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on

Input: evdev - add event-mask API

Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on the same kernel interface.

However, user-space is often only interested in specific sets of events.
For instance, daemons dealing with system-reboot (like systemd-logind)
listen for KEY_POWER, but are not interested in any main keyboard keys.
Usually, power keys are reported via separate interfaces, however,
some i8042 boards report it in the AT matrix. To avoid waking up those
system daemons on each key-press, we had two ideas:
- split off KEY_POWER into a separate interface unconditionally
- allow filtering a specific set of events on evdev FDs

Splitting of KEY_POWER is a rather weird way to deal with this and may
break backwards-compatibility. It is also specific to KEY_POWER and might
be required for other stuff, too. Moreover, we might end up with a huge
set of input-devices just to have them properly split.

Hence, this patchset implements the second idea: An event-mask to specify
which events you're interested in. Two ioctls allow setting this mask for
each event-type. If not set, all events are reported. The type==0 entry is
used same as in EVIOCGBIT to set the actual EV_* mask of filtered events.
This way, you have a two-level filter.

We are heavily forward-compatible to new event-types and event-codes. So
new user-space will be able to run on an old kernel which doesn't know the
given event-codes or event-types.

Signed-off-by: David Herrmann <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: document and check on implicitly defined FF_MAX_EFFECTS

There is an undocumented upper bound for the total number of ff effects:
FF_GAIN (= 96).
This can be found as follows:
- user: writ

Input: document and check on implicitly defined FF_MAX_EFFECTS

There is an undocumented upper bound for the total number of ff effects:
FF_GAIN (= 96).
This can be found as follows:
- user: write(EV_FF, effect_id, iterations)
calls kernel: ff->playback(effect_id, ...): starts effect "effect_id"
- user: write(EV_FF, FF_GAIN, gain)
calls kernel: ff->set_gain(gain, ...): sets gain

A collision occurs when effect_id equals FF_GAIN.
According to input_ff_event(),
FF_GAIN is the smallest value where a collision occurs.
Therefore the greatest safe value for effect_id is FF_GAIN - 1,
and thus the total number of effects should never exceed FF_GAIN.

Define FF_MAX_EFFECTS as FF_GAIN and check on this limit in ff-core.

Signed-off-by: Elias Vanderstuyft <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: fix EVIOCSFF macro inconsistency by using _IOW()

Just like the EVIOCSABS(abs) macro, use the more compact
_IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type))
for the EVIOCSFF macro

Input: fix EVIOCSFF macro inconsistency by using _IOW()

Just like the EVIOCSABS(abs) macro, use the more compact
_IOW(..., type) instead of _IOC(_IOC_WRITE, ..., sizeof(type))
for the EVIOCSFF macro.

Signed-off-by: Elias Vanderstuyft <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: add input-event-codes header file

Add input-event-codes header file and move all type and axis defines
there.

The purpose of this new header file is to have a single canonical source
for eve

Input: add input-event-codes header file

Add input-event-codes header file and move all type and axis defines
there.

The purpose of this new header file is to have a single canonical source
for event-codes which can be used outside of C-code too. One example of
such usage is the use of event-codes in devicetree source files.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: add MT_TOOL_PALM

Currently there are only two "tools" that can be specified by a multi-touch
driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch
vendor) and discussing the

Input: add MT_TOOL_PALM

Currently there are only two "tools" that can be specified by a multi-touch
driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch
vendor) and discussing their next-gen devices it seems that it will be
useful to have more tools so that their devices can give the upper layers
of the stack hints as to what is touching the sensor.

In particular they have new experimental firmware that can better
differentiate between palms vs fingertips and would like to plumb a patch
so that we can use their hints in higher-level gesture soft- ware. The
firmware on the device can reasonably do a better job of palm detection
because it has access to all of the raw sensor readings as opposed to just
the width/pressure/etc that are exposed by the driver. As such, the
firmware can characterize what a palm looks like in much finer-grained
detail and this change would allow such a device to share its findings with
the kernel.

Signed-off-by: Charlie Mooney <[email protected]>
Acked-by: Peter Hutterer <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

Input: rename KEY_DIRECTION to KEY_ROTATE_DISPLAY

The new name better reflects intended usage (but we are keeping the old
name as an alias for compatibility).

Signed-off-by: Stefan Brüns <stefan.br

Input: rename KEY_DIRECTION to KEY_ROTATE_DISPLAY

The new name better reflects intended usage (but we are keeping the old
name as an alias for compatibility).

Signed-off-by: Stefan Brüns <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

HID: map telephony usage page

Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which

HID: map telephony usage page

Currently HID code maps usages from telephony page into BTN_0, BTN_1, etc
keys which get interpreted by mousedev and userspace as left/right/middle
button clicks, which is not really helpful.

This change adds mappings for usages that have corresponding input event
definitions, and leaves the rest unmapped. This can be changed when
there are userspace consumers for more telephony usages.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

HID: wacom: add support for Cintiq 27QHD and 27QHD touch

These devices have accelerometers. To report accelerometer coordinates, a new
property, INPUT_PROP_ACCELEROMETER, is added.

Signed-off-by: P

HID: wacom: add support for Cintiq 27QHD and 27QHD touch

These devices have accelerometers. To report accelerometer coordinates, a new
property, INPUT_PROP_ACCELEROMETER, is added.

Signed-off-by: Ping Cheng <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

HID: add keyboard input assist hid usages

Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf

Signed-off-by:

HID: add keyboard input assist hid usages

Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf

Signed-off-by: Olivier Gay <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

Input: add INPUT_PROP_POINTING_STICK property

It is useful for userspace to know that there not dealing with a regular
mouse but rather with a pointing stick (e.g. a trackpoint) so that
userspace ca

Input: add INPUT_PROP_POINTING_STICK property

It is useful for userspace to know that there not dealing with a regular
mouse but rather with a pointing stick (e.g. a trackpoint) so that
userspace can e.g. automatically enable middle button scrollwheel
emulation.

It is impossible to tell the difference from the evdev info without
resorting to putting a list of device / driver names in userspace, this is
undesirable.

Add a property which allows userspace to see if a device is a pointing
stick, and set it on all the pointing stick drivers.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Benjamin Tissoires <[email protected]>
Acked-by: Peter Hutterer <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...

HID: add missing hid usages

Add some missing hid usages from consumer page, add
some display brightness control usages from approved hid usage
table request HUTTR41:
http://www.usb.org/developers/hi

HID: add missing hid usages

Add some missing hid usages from consumer page, add
some display brightness control usages from approved hid usage
table request HUTTR41:
http://www.usb.org/developers/hidpage/HUTRR41.pdf
and add voice command usage from approved request HUTTR45:
http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf

[[email protected]: removed KEY_BRIGHTNESS_TOGGLE / KEY_DISPLAYTOGGLE
conflict from hid-debug.c]

Signed-off-by: Olivier Gay <[email protected]>
Signed-off-by: Mathieu Meisser <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

Input: Add INPUT_PROP_TOPBUTTONPAD device property

On some newer laptops with a trackpoint the physical buttons for the
trackpoint have been removed to allow for a larger touchpad. On these
laptops

Input: Add INPUT_PROP_TOPBUTTONPAD device property

On some newer laptops with a trackpoint the physical buttons for the
trackpoint have been removed to allow for a larger touchpad. On these
laptops the buttonpad has clearly marked areas on the top which are to be
used as trackpad buttons.

Users of the event device-node need to know about this, so that they can
properly interpret BTN_LEFT events as being a left / right / middle click
depending on where on the button pad the clicking finger is.

This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers
for such buttonpads will use to signal to the user that this buttonpad not
only has the normal bottom button area, but also a top button area.

Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

show more ...