linux-toradex.git/include/linux/hid.h, branch v6.7-rc1

HID: core: remove #ifdef CONFIG_PM from hid_driver

2023-10-25T16:33:42+00:00

Allow HID drivers to pass ->suspend, ->resume and ->reset_resume via
pm_ptr().
Through the usage of pm_ptr() the CONFIG_PM-dependent code will always be
compiled, protecting against bitrot.
The linker will then garbage-collect the unused function avoiding any overhead.

The only overhead in the final kernel image and at runtime are a few
extra bytes in 'struct hid_driver'.

The same approach is chosen by 'struct usb_driver' and other subsystems.

Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20231012-hid-pm_ptr-v1-1-0a71531ca93b@weissschuh.net
Signed-off-by: Benjamin Tissoires

Merge branch 'for-6.6/doc' into for-linus

2023-08-31T08:38:03+00:00

Some docs explaining how HID works by Marco Morandini

HID: Reorder fields in 'struct hid_input'

2023-08-14T09:21:22+00:00

Group some variables based on their sizes to reduce hole and avoid padding.
On x86_64, this shrinks the size of 'struct hid_input'
from 72 to 64 bytes.

It saves a few bytes of memory and is more cache-line friendly.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Jiri Kosina

HID: input: Support devices sending Eraser without Invert

2023-08-14T09:19:10+00:00

Some digitizers (notably XP-Pen Artist 24) do not report the Invert
usage when erasing.  This causes the device to be permanently stuck with
the BTN_TOOL_RUBBER tool after sending Eraser, as Invert is the only
usage that can release the tool.  In this state, Touch and Inrange are
no longer reported to userspace, rendering the pen unusable.

Prior to commit 87562fcd1342 ("HID: input: remove the need for
HID_QUIRK_INVERT"), BTN_TOOL_RUBBER was never set and Eraser events were
simply translated into BTN_TOUCH without causing an inconsistent state.

Introduce HID_QUIRK_NOINVERT for such digitizers and detect them during
hidinput_configure_usage().  This quirk causes the tool to be released
as soon as Eraser is reported as not set.  Set BTN_TOOL_RUBBER in
input->keybit when mapping Eraser.

Fixes: 87562fcd1342 ("HID: input: remove the need for HID_QUIRK_INVERT")
Co-developed-by: Nils Fuhler 
Signed-off-by: Nils Fuhler 
Signed-off-by: Illia Ostapyshyn 
Signed-off-by: Jiri Kosina

HID: Add introduction about HID for non-kernel programmers

2023-08-07T11:24:36+00:00

Add an introduction about HID meant for the casual programmer
that is trying either to fix his device or to understand
what is going wrong.

Signed-off-by: Marco Morandini 
Co-authored-by: Peter Hutterer 
Signed-off-by: Jiri Kosina

HID: ensure timely release of driver-allocated resources

2023-05-26T18:45:39+00:00

More and more drivers rely on devres to manage their resources, however
if bus' probe() and release() methods are not trivial and control some
of resources as well (for example enable or disable clocks, or attach
device to a power domain), we need to make sure that driver-allocated
resources are released immediately after driver's remove() method
returns, and not postponed until driver core gets around to releasing
resources.

In case of HID we should not try to close the report and release
associated memory until after all devres callbacks are executed. To fix
that we open a new devres group before calling driver's probe() and
explicitly release it when we return from driver's remove().

This is similar to what we did for I2C bus in commit 5b5475826c52 ("i2c:
ensure timely release of driver-allocated resources"). It is tempting to
try and move this into driver core, but actually doing so is challenging,
we need to split bus' remove() method into pre- and post-remove methods,
which would make the logic even less clear.

Reported-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20230505232417.1377393-1-swboyd@chromium.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: Recognize "Digitizer" as a valid input application

2023-03-30T15:35:42+00:00

"Digitizer" is a generic usage that may be used by various devices but
which is particularly used by non-display pen tablets. This patch adds the
usage to the list of values matched by the IS_INPUT_APPLICATION() macro
that determines if an input device should be allocated or not.

Signed-off-by: Jason Gerecke 
Reviewed-by: Ping Cheng 
Link: https://lore.kernel.org/r/20221019151832.44522-1-jason.gerecke@wacom.com
Signed-off-by: Benjamin Tissoires

HID: add KEY_CAMERA_FOCUS event in HID

2023-03-10T14:21:11+00:00

Our HID device need KEY_CAMERA_FOCUS event to control camera,
but this event is non-existent in current HID driver.
So we add this event in hid-input.c.

Signed-off-by: fengqi 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Kosina

HID: core: Provide new max_buffer_size attribute to over-ride the default

2023-02-23T10:51:56+00:00

Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k).  However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.

In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k).  Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.

This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.

Signed-off-by: Lee Jones 
Signed-off-by: Jiri Kosina

Merge branch 'for-6.3/hid-bpf' into for-linus

2023-02-22T09:44:31+00:00

Initial support of HID-BPF (Benjamin Tissoires)

The history is a little long for this series, as it was intended to be
sent for v6.2. However some last minute issues forced us to postpone it
to v6.3.

Conflicts:
* drivers/hid/i2c-hid/Kconfig:
  commit bf7660dab30d ("HID: stop drivers from selecting CONFIG_HID")
  conflicts with commit 2afac81dd165 ("HID: fix I2C_HID not selected
  when I2C_HID_OF_ELAN is")
  the resolution is simple enough: just drop the "default" and "select"
  lines as the new commit from Arnd is doing