v0.1.26

Four changes, all from contributors reading their own hardware: two mice stop being driven as if they were an X2A, and one stops being offered two buttons it hasn't got. Found and measured by @variasjon on a Pulsar Xlite v4 and @bluesceada on a Pulsar Xlite V3.

The Xlite v4's lift-off distance

Its 07/02/03 register is not the X2A's single index: byte 7 is a mode and byte 8 the distance in tenths of a millimetre, the same shape the X3 uses. @variasjon read all six profiles of his, through the 1K dongle and over the cable alike, and the five he had never touched hold 02 0a — 1.0 mm, which this app reported as "2 mm" because it read the mode byte.

Writing was worse than reading: --lod 1 wrote 00 00 and --lod 2 wrote 01 01, pairs Fusion2 never writes, over whatever the mouse had. Both connections now write 02 0a and 02 14, and a pair this app wrote earlier still reads back as 1 mm, so the next write makes it exact.

Two of the five mice the Dongle Kit covers have now been read and both keep this shape. A third would make it worth assuming for the whole generation; until then the driver goes by what has actually been read.

The Xlite v4's six profiles and its DPI range

Its profile list answers with a count of six on both connections, where the cabled driver offered five — the sixth was unreachable. And its DPI ceiling was 26000 in steps of 100, the X2A Wired's PAW3395, where this mouse carries the XS-1 at 32,000 in tens like the rest of the Dongle Kit. The 1K dongle has said so since v0.1.25, so the same mouse had two different ceilings depending on which end it was plugged into — and a stage set to 32000 through the dongle, read back on the cable, was a value the page could not show, which stops Apply entirely.

Two buttons three of those four mice do not have

The X2A Wireless, Xlite V3, X2 V2 and X2 V2 Mini all ship as 3554:f507 and 3554:f508, so one driver serves them and its button table was built from the ambidextrous X2A Wireless — four thumb buttons, two per flank. The other three have one flank.

@bluesceada found both halves of the fix: Fusion identifies these mice by a CID and MID pair it reads from the device (command 0x01, the handshake — decoded from two of his USB captures), and Fusion's own Cfg.ini names each pair, with the key matrix each model gets. So the driver asks, and a mouse whose MID says six buttons now refuses Thumb 3 and Thumb 4 instead of reading a binding that isn't one and writing over whatever those slots hold. On his Xlite V3 they hold DPI-type actions.

A mouse that won't say, or one whose MID isn't in that table, keeps all eight: hiding two real buttons from an X2A Wireless whose read happened to fail would be the worse mistake. Those two rows are still present in the window on a six-button mouse, just refused — hiding them needs the GUI to rebuild its pages when a driver learns what it is talking to, which is still to come.

The model, named

pulsar-mouse prints the pair and what it means — Model IDs: cid=6 mid=7 (Pulsar Xlite V3) — on the mice that answer it. Only one of the four rows in that table has been read off hardware so far, so if yours disagrees with its label, that is worth an issue.

---

Full attribution is in the README.