[f-o-o-g-s]

With the X3 on its cable and the 1K dongle still plugged in, the DPI button stopped reaching the app after a swap to the cable. find_hidraw() in x2a.py only checks the VID, and the Fusion2 mice and the 1K dongle all share 3710, so it returned the dongle's interface 1 (hidraw1 sorts before hidraw11).

This copies the VID+PID match nordic.py already does. It covers the X2A, Xlite v4, X3 and the 1K dongle since they all inherit it.

Tested with my X3 and 1K dongle, app running as my user:

• cabled, dongle still in: before, the listener sat on hidraw1 and presses went nowhere. After, it's on hidraw11 and presses come through (800, 1600)
• dongle after unplugging the cable: listener on hidraw1, all 6 presses heard
• check-drivers.py: 7/7

feinmann8k.py's find_hidraw() has the same VID-only match. I don't have that dongle so I left it out, but it's the same change if you want it.

[packerlschupfer]

Merged, thanks — and it was latent on the X2A too: 3710:1404 shares the VID with the whole Fusion2 line, so the only reason it never bit here is that mine is the only Pulsar device on this machine.

I took the match up into PulsarDevice.find_hidraw() afterwards, because feinmann8k.py had the same bug — it matched the VID as a substring of the whole uevent file — and a third copy of the loop seemed the wrong direction. Each driver now declares which interface carries its reports:

_HIDRAW_INTERFACE = '/input1'

find_hidraw() takes a root, which is what made your collision testable without your hardware: check-drivers.py now builds a sysfs tree holding every declared VID:PID at once — a mouse, its dongle, and someone else's Pulsar — and asserts each driver picks its own device's node. The numbering keeps the lexicographic sort the bug relied on (hidraw1 before hidraw11), and each device gets an input0 node too, so a driver that stopped checking the interface fails as well. Restoring the VID-only match fails it on seven drivers, which is the only reason I trust it. The feinmann8k part stays untested — neither of us has that mouse — and the comment there says where to look if its events ever stop arriving.

On the stage byte: the X2A is 0-based, so the +1 is right for it and your X3 is the one that differs. Five presses here, against a 6-stage table of 400/800/1600/3200/6400/12800:

byte2=0x02  dpi=1600   -> stage 3
byte2=0x03  dpi=3200   -> stage 4
byte2=0x04  dpi=6400   -> stage 5
byte2=0x05  dpi=12800  -> stage 6
byte2=0x00  dpi=400    -> stage 1

So this wants an override in x3.py, not a change to the shared parser. Before I write that on one sample, could you run tools/hidraw-listen.py (read-only, never writes to the mouse — close the GUI first so the reports come to it) and press the DPI button once per stage through the whole loop? The 05 05 ... lines next to your stage table settle it. If it's 1-based the whole way round, the override is two lines.

[f-o-o-g-s]

Ran it on both connections. It's 1-based the whole way round on both. Six presses each, same table (400/800/1600/3200/6400/12800):

dongle (3710:5402, hidraw1)        cable (3710:3409, hidraw12)
byte2=0x04  dpi=3200   stage 4     byte2=0x04  dpi=3200   stage 4
byte2=0x05  dpi=6400   stage 5     byte2=0x05  dpi=6400   stage 5
byte2=0x06  dpi=12800  stage 6     byte2=0x06  dpi=12800  stage 6
byte2=0x01  dpi=400    stage 1     byte2=0x01  dpi=400    stage 1
byte2=0x02  dpi=800    stage 2     byte2=0x02  dpi=800    stage 2
byte2=0x03  dpi=1600   stage 3     byte2=0x03  dpi=1600   stage 3

So the dongle passes the same 1-based byte through, which means xlite_v4_wireless.py needs the override too, at least with an X3 behind it. I can't tell you what an Xlite V4 sends through the same dongle. The X3 has no profile button. Full logs: https://gist.github.com/f-o-o-g-s/486cddaa5fe0f188c0ea9e748c35fbfc

A few other things showed up in the logs, in case they're useful for #7:

• 04 20 / 04 00 on interface 1 with every DPI press and release. I bumped another button by accident twice and that came through as 04 08, plus a button bit on the pointer interface.
• 05 07 <charging> <percent> 01 looks like an unprompted battery report. The dongle sent 05 07 00 50 01 (80%, not charging) right after the mouse reconnected, and the cable sent 05 07 01 51 01 (81%, charging). Both matched get_power() at the time.
• For the "away" step I walked out and back within 15 s. Link quality dropped to 76, then nothing for about 7 s, and the dongle sent 05 08 02 01 and then 05 08 01 01 around that gap. Looks like link lost and back, but that's one walk, so it's a guess.

Also, a59543f stops the GUI's listeners from starting on every driver: no DPI updates in the tray and no Connection Quality on Home. Details and a fix in #19.

[packerlschupfer]

Both tables land on 1–6 now. parse_hidraw_event() keeps the arithmetic and takes the first-stage number from the driver: X2A 0, X3 1, 1K dongle 1 (c3667a4).

The dongle is the guess of the three. It relays the mouse's byte untouched, so the numbering is really the mouse's, and the X3 is the only mouse confirmed behind it. If a Fusion2 mouse turns up that counts from zero, that constant has to become a get_connected_mouse() lookup — the comment says so.

The Xlite v4 keeps the X2A's 0, like everything else in that driver; it has never met hardware. Its docstring now points here if its DPI button ever reads one stage high.

The other three report shapes are worth more than a comment on a merged PR — #21.