The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.
Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Commit 1ff2e1a44e ("HID: input: Create a utility class for counting
scroll events") created the helper function
hid_scroll_counter_handle_scroll()
to handle high-res scroll events and also expose them as regular wheel
events.
But the resulting algorithm was unstable, and causes scrolling to be
very unreliable. When you hit the half-way mark of the highres
multiplier, small highres movements will incorrectly translate into big
traditional wheel movements, causing odd jitters.
Simplify the code and make the output stable.
NOTE! I'm pretty sure this will need further tweaking. But this at
least turns a unusable mouse wheel on my Logitech MX Anywhere 2S into
a usable one.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Harry Cutts <hcutts@chromium.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes and new features for driver core. Highlights:
- maximum global item tag report size gets increased to 256
- improved INPUT_PROP reporting for Digitizer devices
Some system may want to know if a detected digitizer device is either an
integrated or an external device. In order to distinguish such condition,
setting either INPUT_PROP_DIRECT or INPUT_PROP_POINTER is required,
checking the member, "application", in "hid_field" structure.
Signed-off-by: Tatsunosuke Tobita <tobita.tatsunosuke@wacom.co.jp>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
To avoid code duplication, this class counts high-resolution scroll
movements and emits the legacy low-resolution events when appropriate.
Drivers should be able to create one instance for each scroll wheel that
they need to handle.
Signed-off-by: Harry Cutts <hcutts@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Or it creates some weird input names like:
"MI Dongle MI Wireless Mouse Mouse"
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make sure to free the custom input node name on disconnect.
Cc: stable@vger.kernel.org # v4.18+
Fixes: c554bb0455 ("HID: input: append a suffix matching the application")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Dell Canvas 27 has a tool that can be put on the surface and acts
as a dial. The firmware processes the detection of the tool and forward
regular HID reports with X, Y, Azimuth, rotation, width/height.
The firmware also exports Contact ID, Countact Count which may hint that
several totems can be used at the same time (the FW only supports one).
We can tell that MT_TOOL_DIAL will be reported by setting the min/max
of ABS_MT_TOOL_TYPE to MT_TOOL_DIAL.
This tool is aimed at being used by the system and not the applications,
so the user space processing should not go through the regular touch
inputs.
We set INPUT_PROP_DIRECT which applies ID_INPUT_TOUCHSCREEN to this new
type of devices, but we will counter this for the time being with the
special udev hwdb entry mentioned above.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
- improvement of duplicate usage handling in hid-input from Benjamin Tissoires
- Win 8.1 precisioun touchpad spec implementation from Benjamin Tissoires
Given that we create one input node per application, we should name
the input node accordingly to not lose userspace.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is not a good idea to try to fit all types of applications in the
same input report. There are a lot of devices that are needing
the quirk HID_MULTI_INPUT but this quirk doesn't match the actual HID
description as it is based on the report ID.
Given that most devices with MULTI_INPUT I can think of split nicely
the devices inputs into application, it is a good thing to split the
devices by default based on this assumption.
Also make hid-multitouch following this rule, to not have to deal
with too many input created.
While we are at it, fix some checkpatch complaints about converting
'unsigned' to 'unsigned int'.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We were only storing the report in case of QUIRK_MULTI_INPUT.
It is interesting for the upcoming HID_QUIRK_INPUT_PER_APP to also
store the full list of reports that are attached to it.
We need the full list because a device (Advanced Silicon has some)
might want to use a different report ID for the Input reports and
the Output reports. Storing the full list allows the drivers to
have all the data.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This is something that bothered us from a long time. When hid-input
doesn't know how to map a usage, it uses *_MISC. But there is something
else which increments the usage if the evdev code is already used.
This leads to few issues:
- some devices may have their ABS_X mapped to ABS_Y if they export a bad
set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
HID driver)
- *_MISC + N might (will) conflict with other defined axes (my Logitech
H800 exports some multitouch axes because of that)
- this prevents to freely add some new evdev usages, because "hey, my
headset will now report ABS_COFFEE, and it's not coffee capable".
So let's try to kill this nonsense, and hope we won't break too many
devices.
I my headset case, the ABS_MISC axes are created because of some
proprietary usages, so we might not break that many devices.
For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
is created and can be applied to any device that needs this behavior.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The commit 581c448476 ("HID: input: map digitizer battery usage")
assumed that devices having input (qas opposed to feature) report for
battery strength would report the data on their own, without the need to
be polled by the kernel; unfortunately it is not so. Many wireless mice
do not send unsolicited reports with battery strength data and have to
be polled explicitly. As a complication, stylus devices on digitizers
are not normally connected to the base and thus can not be polled - the
base can only determine battery strength in the stylus when it is in
proximity.
To solve this issue, we add a special flag that tells the kernel
to avoid polling the device (and expect unsolicited reports) and set it
when report field with physical usage of digitizer stylus (HID_DG_STYLUS).
Unless this flag is set, and we have not seen the unsolicited reports,
the kernel will attempt to poll the device when userspace attempts to
read "capacity" and "state" attributes of power_supply object
corresponding to the devices battery.
Fixes: 581c448476 ("HID: input: map digitizer battery usage")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin van Es <martin@mrvanes.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no real point of registering an empty input node.
This should be default, but given some drivers need the blank input
node to set it up during input_configured, we need to postpone
the check for hidinput_has_been_populated().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Follow the change of return type u32 of hid_report_len,
fix all the types of variables those get the return value of
hid_report_len to u32, and all other code already uses u32.
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some tablets report eraser usage to indicate the eraser tool tip
is touching the surface. But, hidinput_configure_usage didn't
support the usage, which led it falls into default as ABS_MISC.
Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The power_supply subsystem tends to emit uevent every time
power_supply_changed() is called, so we should call this API only when battery
strength reported by the device is actually different from the previous
readings, otherwise we'll drown the system in uevents.
Fixes: 581c448476 ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Manufacturers do not always populate serial number in their devices, so
let's fall back to device ID when forming the battery device name. As a
result, batteries in devices without serial number will be named like
this:
hid-0018:2D1F:510E.0001-battery
(as opposed to hid--battery for the first one, and failing to create
batteries for the subsequent ones).
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
We already mapped battery strength reports from the generic device
control page, but we did not update capacity from input reports, nor we
mapped the battery strength report from the digitizer page, so let's
implement this now.
Batteries driven by the input reports will now start in "unknown" state,
and will get updated once we receive first report containing battery
strength from the device.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Benjamin Tissoires
Benson Leung
Linus Torvalds
Jiri Kosina
Tatsunosuke Tobita
Harry Cutts
Stefan Agner
Dmitry Torokhov
Aaron Ma
Ping Cheng