[PATCH AUTOSEL 6.18] HID: elecom: Add support for ELECOM M-XT4DRBK (018E)

[Sasha Levin <sashal@kernel.org>]

From: Berke Durak <berke.durak@gmail.com>

[ Upstream commit f3c2b266b8fd7cf816d36168d19f67e716f2c080 ]

The 2025 revision of the left-handed EX-G wireless trackball
(M-XT4DRBK-G) reports USB ID 056e:018e instead of 056e:00fd. Its report
descriptor declares an 8-bit button field (Report Count 8) but only five
usages (Usage Maximum 5), so the sixth (Fn) button ends up as a
duplicate of button 5 and is unusable.

The report descriptor has the same layout as the M-XT3DRBK 018C
(button usage maximum at offset 16, button report count at 22, button
report size at 24, padding report size at 30), so reuse that fixup.

Rename the existing M_XT4DRBK define to M_XT4DRBK_00FD to match the
convention used for the other EX-G revisions.

Tested on a Raspberry Pi 5 with the same fixup in an
out-of-tree module on 6.12 (6.12.96+rpt-rpi-2712);
all six buttons are reported after the fix, and they
work (tested with xev as well).

Report descriptor as sent by the device, pre-fix (056e:018e,
215 bytes):

 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
 29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
 95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
 08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
 08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
 85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
 05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
 3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
 03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
 01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
 01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
 75 08 95 07 B1 02 C0

Assisted-by: LLM
Signed-off-by: Berke Durak <berke.durak@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.18.57** (`v6.18.57-155-gcdf239ca885b2`). The
question is whether this HID/elecom USB-ID + report-descriptor fixup
should be backported here. The driver, the existing
`mouse_button_fixup()` helper, and the sibling 018C fixup are all
already present in 6.18.57.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: `[HID / elecom] [Add support] [USB ID 056e:018e for the 2025
M-XT4DRBK-G trackball, plus the existing button report-descriptor
fixup]`

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- No `Fixes:` tag (expected for this review)
- No `Reported-by:` / `Tested-by:` / `Reviewed-by:` / `Acked-by:`
- No `Link:`
- No `Cc: stable@vger.kernel.org` (expected; not a negative)
- `Assisted-by: LLM`
- `Signed-off-by: Berke Durak <berke.durak@gmail.com>` (author)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID maintainer)
- Ignore pipeline `Signed-off-by: Sasha Levin` and `[Upstream commit
  ...]`

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- Bug: 2025 left-handed EX-G wireless trackball (M-XT4DRBK-G) uses USB
  ID `056e:018e` instead of the old `056e:00fd`.
- Descriptor claims an 8-bit button field (`Report Count 8`) but only
  five usages (`Usage Maximum 5`), so the sixth (Fn) button is a
  duplicate of button 5 and is unusable.
- Root cause: same broken descriptor layout as M-XT3DRBK 018C (offsets
  16/22/24/30).
- Symptom: extra button does not work; mouse otherwise enumerates.
- Author tested on Raspberry Pi 5, 6.12 (`6.12.96+rpt-rpi-2712`), via an
  out-of-tree module; all six buttons work (`xev`).
- Full 215-byte pre-fix descriptor is included.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a disguised cleanup. It is a device-ID addition plus an
existing HID report-descriptor quirk. The rename `M_XT4DRBK` →
`M_XT4DRBK_00FD` is local naming only.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- `drivers/hid/hid-ids.h`: +1 ID (`0x018e`), rename existing `0x00fd`
  define
- `drivers/hid/hid-elecom.c`: +1 case in `elecom_report_fixup()`, +1
  `elecom_devices[]` entry, rename 00FD references
- `drivers/hid/hid-quirks.c`: +1 `hid_have_special_driver[]` entry,
  rename 00FD
- Scope: 8 insertions, 4 deletions across 3 files. Surgical, existing
  driver only.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- Before: `056e:018e` is not in hid-elecom, so hid-generic binds and the
  stock descriptor is used (Usage Maximum 5 / Count 8). Old `056e:00fd`
  still uses the 6-button fixup via `USB_DEVICE_ID_ELECOM_M_XT4DRBK`.
- After: `018e` is claimed by hid-elecom and runs
  `mouse_button_fixup(..., 22, 30, 24, 16, 6)` (same as 018C). Old 00FD
  device still hits the same 6-button fixup through the renamed define.
  `hid_have_special_driver` keeps hid-generic from binding 018E.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: `[Hardware workaround / device ID + HID descriptor quirk]`
- Broken HID report descriptor: Usage Maximum 5 vs Report Count 8.
- Fix reuses the proven 018C path: set count and usage max to 6, padding
  to 2.

Verified against the included descriptor (first 32 bytes):
```
offset 16: 29 05  Usage Maximum (5)
offset 22: 95 08  Report Count (8)
offset 24: 75 01  Report Size (1)
offset 30: 75 00  padding Report Size (0)
```
Those match `mouse_button_fixup(hdev, rdesc, *rsize, 22, 30, 24, 16,
6)`. The helper then writes count=6, usage max=6, padding=2. The 018C
commit in this tree used the identical dump.

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: new ID, existing helper, offsets match the dump.
- Minimal: no new APIs, no new helper, no behavior change for 00FD.
- Rename is kernel-internal (`hid-ids.h`); grep shows no leftover
  `USB_DEVICE_ID_ELECOM_M_XT4DRBK` users.
- Regression risk is low: `mouse_button_fixup()` bails out unless the
  expected HID items are at those offsets, so a mismatched 018E
  descriptor would be left unchanged.
- `hid-quirks.c` update is required so hid-generic does not steal the
  device (`HID_QUIRK_HAVE_SPECIAL_DRIVER`).

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Original M-XT4DRBK 00FD support: `fbb77e88f08ce` (2018, Tomasz
  Kramkowski), already in 6.18.57.
- Parameterized `mouse_button_fixup()`: `68d09380a6278` (2020), already
  in 6.18.57.
- 018C sibling layout this patch reuses: `da1880c7b6b83` (Arnoud
  Willemsen), already in 6.18.57 (`git merge-base --is-ancestor`
  returned 0).

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. Not a regression in previously working 018E
support; 018E was never in this tree. The bug is the device’s
descriptor, same class as 00FD/018C.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: Recent `hid-elecom.c` history is the same pattern of “new USB ID
+ existing fixup”:
- `cdcbb8e8d10f6` M-XT3URBK 018F (in 6.18.57)
- `da1880c7b6b83` M-XT3DRBK 018C (in 6.18.57)
- `a36e053b16804` HUGE Plus M-HT1MRBK (in 6.18.57)
Standalone; not patch X/Y.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Berke Durak has only this hid-elecom commit here. Jiri Kosina
(HID maintainer) signed off and applied it.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: Needs `mouse_button_fixup()` and the 018C case. Both exist at
v6.18.57. No new functions. Can apply standalone. `patch --dry-run` of
this diff onto the v6.18.57 copies of the three files succeeded.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c a6dbbf8a1601a`:
  https://patch.msgid.link/20260907184719.25042-1-berke.durak@gmail.com
- `b4 dig -a`: single revision (v1 only), 2026-09-07
- lore.kernel.org fetches returned 403; discussion confirmed via patchew
  and openwall mirrors
- Jiri Kosina: “Applied, thanks.” No NAK, no requested respin, no
  stable-risk comments

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`): To/Cc Jiri Kosina, Benjamin Tissoires, linux-
input, linux-kernel. HID maintainer applied it.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No bugzilla/syzbot link. The author is the reporter and tester,
with a full descriptor dump and xev confirmation. Same failure mode as
018C, which is already in this tree.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Standalone v1. Closely related 018C/018F/HUGE Plus ID+fixup
patches are already in 6.18.57.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: UNVERIFIED. `lore.kernel.org/stable/?q=M-XT4DRBK` returned 403.
No evidence of a prior rejection. Does not change the technical verdict.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `elecom_report_fixup()` (switch cases / id table);
`mouse_button_fixup()` called but not modified; ID tables in `hid-
elecom.c` and `hid_have_special_driver[]`.

**Step 5.2: TRACE CALLERS**
Record:
- `elecom_report_fixup` ← `elecom_driver.report_fixup` ← `hid-core.c`
  `hid_open_report()` (`device->driver->report_fixup(...)` at line 1305)
- `hid_have_special_driver` match ← `hid_gets_squirk()` sets
  `HID_QUIRK_HAVE_SPECIAL_DRIVER` ← `hid_generic_match()` returns false
  so hid-generic does not bind

**Step 5.3: TRACE CALLEES**
Record: `mouse_button_fixup()` only mutates three descriptor bytes after
pattern checks; `hid_info()` log. No allocation, locking, or I/O.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Plug USB receiver → usbhid → hid parse → `report_fixup` → input
events. Userspace-reachable on plug. Unprivileged users then use the
extra button via evdev. Not a security bug; it is a functional hardware
bug.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Same pattern already used for 018C, 018F, DT2, HUGE, etc. in
this file. This is the left-handed 2025 wireless counterpart of 018C.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: Yes. v6.18.57 has hid-elecom, `mouse_button_fixup()`, and 018C’s
layout, but **not** ID `0x018e`. Without this patch, 018E is a generic
HID mouse with a broken sixth button. The 00FD model is already quirked.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Clean apply onto v6.18.57 (`patch --dry-run` rc 0). Parent vs
v6.18.57 differs only by an unrelated ITE keyboard ID later in `hid-
ids.h`.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No 018E fix in v6.18.57. 018C/018F/HUGE Plus ID+fixup patches
**are** already in 6.18.57, which is the same stable-accepted class of
change.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: `[drivers/hid/hid-elecom.c] [PERIPHERAL / driver-specific]`,
gated by `CONFIG_HID_ELECOM`. Important for owners of this trackball;
not core MM/VFS.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature driver (2010–); recent work is additional ELECOM IDs and
descriptor fixups, several of which already landed in 6.18.y.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Driver-specific / config-specific: users of ELECOM M-XT4DRBK-G
2025 (`056e:018e`) with `CONFIG_HID_ELECOM`. 00FD users are unchanged.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every plug-in of that dongle. Not a race. Unprivileged users see
a missing/duplicated Fn button.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: `[Broken extra mouse button on specific hardware] [MEDIUM
functional / hardware-quirk]`. Not a crash, UAF, or corruption issue.
This is the documented stable exception for USB IDs and hardware quirks.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- Benefit: 2025 left-handed EX-G trackball gets a working sixth button
  on 6.18.y, matching what 018C already got.
- Risk: very low (8/4 line change, existing helper, pattern-gated,
  maintainer-applied, tested).
- Ratio: high benefit for affected hardware, negligible regression risk.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- USB ID + existing HID quirk on an existing driver (stable exceptions 1
  and 2)
- Real user-visible bug: sixth button unusable; author tested the fix
- Descriptor offsets verified against the dump and against 018C already
  in this tree
- Small, obviously correct, no new APIs
- HID maintainer applied v1 with no objections
- Same class of patch (018C/018F/HUGE Plus) already in 6.18.57
- Applies cleanly to this tree

AGAINST:
- Not a crash/security/corruption fix
- Affects one consumer trackball model
- Author is not a regular HID contributor; patch notes `Assisted-by:
  LLM` (mitigated by maintainer apply + dump + test)

UNRESOLVED:
- Could not fetch lore.kernel.org (403) or search stable@ archives
  directly; discussion recovered from b4/patchew/openwall

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — offsets match; author
   tested; maintainer applied
2. Fixes a real bug that affects users? **PASS** — Fn button unusable
   without the quirk
3. Important issue? **PASS** under the hardware-quirk / new-ID exception
   (severity MEDIUM, not CRITICAL)
4. Small and contained? **PASS** — 8 insertions / 4 deletions, 3 files
5. No new features or APIs? **PASS** — ID + existing fixup only
6. Can apply to the local tree? **PASS** — clean apply to v6.18.57;
   prerequisites present

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Device ID addition to existing driver** and **hardware
quirk/workaround**. Both qualify for stable.

**Step 9.4: MAKE YOUR DECISION**
YES. This is the same HID-elecom USB-ID + report-descriptor quirk 6.18.y
has already taken for 018C. It does not add a driver or API; it makes a
current ELECOM trackball’s sixth button work.

What the commit solves: the 2025 M-XT4DRBK-G (`056e:018e`) ships a
descriptor that only declares five button usages, so Linux reports the
Fn button as a duplicate of button 5. The fix binds that ID to hid-
elecom and reuses the 018C `mouse_button_fixup()`.

Risk vs benefit: benefit is a working extra button on real hardware;
risk is a few table entries and a pattern-checked 3-byte descriptor
edit. 00FD behavior is unchanged.

No extra prerequisites; 018C’s helper and case are already in this tree.

Verification:
- [Phase 1] Parsed tags: author + Jiri Kosina SOB; no Fixes/Cc
  stable/Reported-by; LLM-assisted
- [Phase 1] Body: 056e:018e, Usage Maximum 5 vs Count 8, sixth button
  unusable; tested on Pi 5 / 6.12
- [Phase 2] Diff: +8/-4 in hid-elecom.c, hid-ids.h, hid-quirks.c; rename
  00FD define; add 018E to 018C fixup
- [Phase 2] Descriptor offsets 16/22/24/30 verified against the dump
- [Phase 3] `git describe HEAD` / Makefile: local tree is 6.18.57
- [Phase 3] `git merge-base --is-ancestor a6dbbf8a1601a v6.18.57` → not
  in v6.18.57 (exit 1)
- [Phase 3] 00FD support `fbb77e88f08ce` and 018C `da1880c7b6b83` are
  ancestors of v6.18.57
- [Phase 3] v6.18.57 still uses `USB_DEVICE_ID_ELECOM_M_XT4DRBK` only;
  no 018E
- [Phase 3] Author has no other hid-elecom commits here
- [Phase 4] `b4 dig -c`: msgid
  20260907184719.25042-1-berke.durak@gmail.com; v1 only
- [Phase 4] `b4 dig -w`: Kosina + Tissoires + linux-input; Kosina
  applied
- [Phase 4] lore.kernel.org 403; patchew/openwall used instead
- [Phase 4] UNVERIFIED: stable@ archive search (403)
- [Phase 5] Callers: hid-core `report_fixup` on probe; hid-generic skips
  via `HID_QUIRK_HAVE_SPECIAL_DRIVER`
- [Phase 6] `patch --dry-run` onto v6.18.57 files: success
- [Phase 6] Related 018C/018F/HUGE Plus ID patches already in 6.18.57
- [Phase 8] Failure mode: extra button unusable, not a kernel crash
- UNVERIFIED: original lore HTML (403); does not affect the decision

**YES**

 drivers/hid/hid-elecom.c | 6 ++++--
 drivers/hid/hid-ids.h    | 3 ++-
 drivers/hid/hid-quirks.c | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-elecom.c b/drivers/hid/hid-elecom.c
index 37d88ce57f671..d21ead40bb076 100644
--- a/drivers/hid/hid-elecom.c
+++ b/drivers/hid/hid-elecom.c
@@ -79,7 +79,7 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 	case USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB:
 	case USB_DEVICE_ID_ELECOM_M_XT3URBK_018F:
 	case USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC:
-	case USB_DEVICE_ID_ELECOM_M_XT4DRBK:
+	case USB_DEVICE_ID_ELECOM_M_XT4DRBK_00FD:
 		/*
 		 * Report descriptor format:
 		 * 12: button bit count
@@ -104,6 +104,7 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		mouse_button_fixup(hdev, rdesc, *rsize, 12, 30, 14, 20, 8);
 		break;
 	case USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C:
+	case USB_DEVICE_ID_ELECOM_M_XT4DRBK_018E:
 		/*
 		 * Report descriptor format:
 		 * 22: button bit count
@@ -148,7 +149,8 @@ static const struct hid_device_id elecom_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK_00FD) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK_018E) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT2DRBK) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index a10b4ae0e3d8e..ca5c62f29aebe 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -466,7 +466,8 @@
 #define USB_DEVICE_ID_ELECOM_M_XT3URBK_018F	0x018f
 #define USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC	0x00fc
 #define USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C	0x018c
-#define USB_DEVICE_ID_ELECOM_M_XT4DRBK	0x00fd
+#define USB_DEVICE_ID_ELECOM_M_XT4DRBK_00FD	0x00fd
+#define USB_DEVICE_ID_ELECOM_M_XT4DRBK_018E	0x018e
 #define USB_DEVICE_ID_ELECOM_M_DT1URBK	0x00fe
 #define USB_DEVICE_ID_ELECOM_M_DT1DRBK	0x00ff
 #define USB_DEVICE_ID_ELECOM_M_DT2DRBK	0x018d
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 8d2ac32c5ac12..debd00ed9062a 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -431,7 +431,8 @@ static const struct hid_device_id hid_have_special_driver[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK_00FD) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK_018E) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT2DRBK) },
-- 
2.53.0