Bug 202711 - MX3/T3 airmouse stopped working after updating to 4.18
Summary: MX3/T3 airmouse stopped working after updating to 4.18
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-28 18:34 UTC by Tomasz C.
Modified: 2019-11-07 22:43 UTC (History)
5 users (show)

See Also:
Kernel Version: 4.18 - 5.2.2 (current)
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Tomasz C. 2019-02-28 18:34:33 UTC
Airmouse MX3 (T3) it does not work correctly after upgrading the kernel to 4.18, and the latest stable version (4.20.12).

Device ID USB: 2389:00a8
lsusb does not show the device name, only vendor and product ID.

After connecting and activating the airmouse option, the Xorg pact ceases to respond, the system load increases. It looks like it would loop.
On the kernel in version 4.17 everything worked fine.

The git bisect method showed the first bad commit:

190d7f02ce8ef6774a69d3ec18c288c8a9601a4e is the first bad commit
commit 190d7f02ce8ef6774a69d3ec18c288c8a9601a4e
Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Fri Dec 8 15:28:18 2017 +0100

    HID: input: do not increment usages when a duplicate is found
    
    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>

:040000 040000 e308544fb6e4a6d97b1647b5b3591a0dc4285202 7bc232235db62d2445ef7b61095d888fac73b917 M      drivers
:040000 040000 0a1d0d7aa39f7e907961883aeee8e376fe0daa41 0c0d5e242544074400ac7284512f462770888fce M      include

Additional information:
https://forum.libreelec.tv/thread/13994-problem-with-t3-airmouse-on-versions-8-90-006-and-later-including-8-95-001-rpi3/
https://www.spinics.net/lists/linux-input/msg57789.html
Comment 1 Vladimir Jicha 2019-11-07 22:05:56 UTC
Is there any workaround available? Would it be possible to force the correct driver for the air mouse? Thank you.
Comment 2 mybigspam 2019-11-07 22:43:15 UTC
Maybe we should try HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE first?

Note You need to log in before you can comment on or make changes to this bug.