Both changes illustrate why a peripheral’s model name alone can be an unreliable guide to Linux compatibility. Connection mode matters for the Logitech mouse; the USB product identifier and report layout matter for the ELECOM trackball. Neither change establishes parity with the manufacturers’ configuration software.
Linux 7.3 targets two different gaps in peripheral support
Phoronix reports that the September 22 HID subsystem pull request includes both additions and is expected to reach Linux 7.3-rc5 on Sunday, September 27. That is development-kernel timing, not confirmation that a stable release or a distribution update is available. No second outlet in the available reporting independently confirms that merge schedule.
HID means Human Interface Device, the device class involved here. These changes work within existing Linux HID drivers: hid-logitech-hidpp for Logitech’s HID++ protocol and hid-elecom for the trackball’s device-specific handling. They do not introduce replacement configuration applications.
The documented boundaries are different enough to keep separate:
| Device | Targeted configuration | Documented change |
|---|---|---|
| Logitech G502 X Lightspeed | Mouse connected directly over USB | Adds identification needed for the existing Logitech HID++ driver, according to Phoronix. |
| ELECOM M-XT4DRBK-G | 2025 left-handed EX-G wireless trackball reporting 056e:018e | Applies an existing descriptor correction so the sixth button can be reported separately. |
The ELECOM patch provides the firmer before-and-after evidence. Submitted by Berke Durak on September 7, it identifies the newer product ID as 018e and preserves the older M-XT4DRBK identifier, 00fd, under a more specific constant name. This is support for an additional revision, not the first appearance of the M-XT4DRBK family in the driver.
Logitech G502 X Lightspeed gains a USB driver match, not a new software suite
According to Phoronix, the G502 X Lightspeed addition supplies the identifiers needed when the wireless mouse is used through a direct USB connection. The intended result is to bring that connection under the existing Logitech HID++ driver’s handling.
That scope is important. A report about the cable-connected mouse does not establish a fault in its wireless-receiver path, nor does it promise a change to wireless behavior. Owners whose problem occurs only through a receiver should not assume that this particular addition addresses it.
The Linux driver describes itself as supporting devices that rely on Logitech’s HID++ specification. Its implementation already contains protocol handling and capability-dependent functions. Adding another hardware match therefore allows an existing implementation to handle the relevant device; it does not mean every function implemented somewhere in that driver becomes available on every supported mouse.
For the G502 X Lightspeed, the available reporting does not enumerate a verified feature-by-feature result. It would consequently be premature to promise particular battery, scrolling, profile, or button-configuration capabilities solely from the new match. Basic pointer operation and access to device-specific driver functions also should not be treated as the same test.
The defensible expectation is HID++ driver recognition for the direct-USB connection. Nothing in this change establishes Linux availability of Logitech G HUB or complete support for its settings.
ELECOM M-XT4DRBK’s new revision needs a different descriptor correction
Durak’s patch explains the ELECOM fault precisely. The 2025 M-XT4DRBK-G reports USB identity 056e:018e, rather than the older 056e:00fd. Its HID report descriptor declares an eight-bit button field but describes only five button usages. As a result, the sixth, or Fn, button is interpreted as a duplicate of button five.
A report descriptor tells the operating system how to interpret the data a device sends. Here, the mismatch is between the space allocated to button information and the number of distinct buttons described. That explains how a trackball can provide useful pointer input while still failing to expose one control independently.
The patch routes the new identifier through a correction already used for the ELECOM M-XT3DRBK revision identified as 018c. The two revisions share the relevant descriptor layout. In that layout, the button usage maximum is at offset 16, the button count at 22, the button report size at 24, and the padding report size at 30.
Those locations differ from the older M-XT4DRBK’s handling. The distinction prevents an easy misreading of the change: recognizing the marketing name is insufficient if the newer hardware describes its input differently.
The existing correction sets the descriptor to represent six buttons and adjusts the remaining padding accordingly. It operates on the descriptor used by Linux; the patch does not describe a trackball firmware update or an installation of ELECOM’s configuration utility.
Durak reports testing the same fixup in an out-of-tree module on a Raspberry Pi 5 running a 6.12-based kernel. In that test, all six buttons were reported and worked, with xev also used for verification. This is the patch author’s reported result, not a WindowsForum test or confirmation across every Linux desktop configuration.
Match your device and symptom before changing kernels
Wait for a kernel containing the relevant change unless you have a specific reason to test development code. For the ELECOM device, the strongest match is the newer USB identity together with a sixth button that duplicates button five. For the Logitech mouse, the relevant boundary is a direct USB connection and the existing HID++ driver.
- Treat the G502 X Lightspeed update as a direct-USB change; it does not establish a wireless-receiver fix.
- For the ELECOM trackball, distinguish
056e:018efrom the older056e:00fdrevision before attributing a button problem to this patch. - Judge the ELECOM improvement by whether the sixth button produces a separate input, rather than merely whether the pointer moves.
- Treat Linux 7.3-rc5 as a reported development milestone, not evidence that your distribution has already delivered either change.
- Do not assume kernel recognition includes the manufacturers’ graphical configuration tools, macros, or profile-management features.
These are modest compatibility changes with concrete value for the affected configurations. The ELECOM patch has a documented symptom, a targeted correction, and an author-reported successful test; the Logitech addition closes a reported driver-identification gap for cable use. The useful next milestone for owners is delivery of those changes in the kernel they actually run, with expectations tied to the specific connection or hardware revision being fixed.