Multitouch devices in hybrid mode are reporting multiple times the
same collection. We should accommodate for this in our handling
of priorities by defining the slots they belong to.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID_QUIRK_INVERT is kind of complex to deal with and was bogus.
Furthermore, it didn't make sense to use a global per struct hid_device
quirk for something dynamic as the current state.
Store the current tool information in the report itself, and re-order
the processing of the fields to enforce having all the tablet "state"
fields before getting to In Range and other input fields.
This way, we now have all the information whether a tool is present
or not while processing In Range.
This new behavior enforces that only one tool gets forwarded to userspace
at the same time, and that if either eraser or invert is set, we enforce
BTN_TOOL_RUBBER.
Note that the release of the previous tool now happens in its own EV_SYN
report so userspace doesn't get confused by having 2 tools.
These changes are tested in the following hid-tools regression tests:
https://gitlab.freedesktop.org/libevdev/hid-tools/-/merge_requests/127
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When a device exposes both Invert and InRange, Invert must be processed
before InRange. If we keep the order of the device and we process them
out of order, InRange will first set BTN_TOOL_PEN, and then Invert will
set BTN_TOOL_RUBBER. Userspace knows how to deal with that situation,
but fixing it in the kernel is now easier.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This will be used in a later commit:
we build a list of input fields (and usage_index) that is ordered based
on a usage priority.
Changing the usage priority allows to re-order the processed list, meaning
that we can enforce some usages to be process before others.
For instance, before processing InRange in the HID tablets, we need to
know if we are using the eraser (side or button). Enforcing a higher
(lower number) priority for Invert allows to force the input stack to
process that field before.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is a preparatory patch for being able to process the usages
out of order. We split the retrieval of the data in a separate function
and also split out the processing of the usages depending if the field
is an array or a variable.
No functional changes from this patch.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is a preparation patch for rethinking the generic processing
of HID reports.
We can actually pre-allocate all of our memory instead of dynamically
allocating/freeing it whenever we parse a report.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- support for USI style pens (Tero Kristo, Mika Westerberg)
- quirk for devices that need inverted X/Y axes (Alistair Francis)
- small core code cleanups and deduplication (Benjamin Tissoires)
- patch series that ensures that hid-multitouch driver disables touch and
button-press reporting on hid-mt devices during suspend when the device is
not configured as a wakeup-source, from Hans de Goede
- device unbinding locking fix from Dmitry Torokhov
- support for programmable buttons (mapping to KEY_MACRO# event codes)
from Thomas Weißschuh
- various other small fixes and code style improvements
Add a hid_hw_may_wakeup() function, which is the equivalent of
device_may_wakeup() for hid devices.
In most cases this just returns device_may_wakeup(hdev->dev.parent), but for
some ll-drivers this is not correct. E.g. usb_hid_driver instantiated hid
devices have their parent set to the usb-interface to which the usb_hid_driver
is bound, but the power/wakeup* sysfs attributes are part of the usb-device,
which is the usb-interface's parent.
For these special cases a new may_wakeup callback is added to
hid_ll_driver, so that ll-drivers can override the default behavior.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Map them to KEY_MACRO# event codes.
These buttons are defined by HID as follows:
"The user defines the function of these buttons to control software applications or GUI objects."
This matches the semantics of the KEY_MACRO# input event codes that Linux supports.
Also add support for HID "Named Array" collections.
Also add hid-debug support for KEY_MACRO#.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In hid_submit_ctrl(), the way of calculating the report length doesn't
take into account that report->size can be zero. When running the
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
calculate transfer_buffer_length as 16384. When this urb is passed to
the usb core layer, KMSAN reports an info leak of 16384 bytes.
To fix this, first modify hid_report_len() to account for the zero
report size case by using DIV_ROUND_UP for the division. Then, call it
from hid_submit_ctrl().
Reported-by: syzbot+7c2bb71996f95a82524c@syzkaller.appspotmail.com
Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is the capacity in percentage, relative to design capacity.
Specifically, it is present in Apple Magic Mouse 2.
In contrast, usage 00850064 is also the capacity in percentage, but is
relative to full capacity. It is not mapped here because I don't have
such device.
Signed-off-by: John Chen <johnchen902@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice
for each volume key press. This patch adds a quirk to hid-plantronics
for this product ID, which will ignore the second volume key press if
it happens within 5 ms from the last one that was handled.
The patch was tested on the mentioned model only, it shouldn't affect
other models, however, this quirk might be needed for them too.
Auto-repeat (when a key is held pressed) is not affected, because the
rate is about 3 times per second, which is far less frequent than once
in 5 ms.
Fixes: 81bb773fae ("HID: plantronics: Update to map volume up/down controls")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently the maximum HID report size which can be buffered by the kernel is
8KB. This is sufficient for the vast majority of HID devices on the market, as
most HID reports are fairly small.
However, some unusual devices such as the Elgate Stream Deck exist which use a
report size slightly over 8KB for the image data that is sent to the device.
Reports these large cannot be buffered by the regular HID subsystem currently,
thus the only way to use such device is to bypass the HID subsystem entirely.
This increases the maximum HID report size to 16KB, which should cover all
sanely designed HID devices.
Signed-off-by: Dean Camera <dean@fourwalledcubicle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
