Audeze Maxwell 2 (3329:4b29): device returns zero-length responses to all status queries; battery and chatmix unavailable #573

Summary

On my Maxwell 2 PS/PC dongle (3329:4b29), every info capability reports as
unavailable: battery is BATTERY_UNAVAILABLE / -1, chatmix is always 0.
Setters work — sidetone changes are plainly audible — so the device is
reachable and the write path is fine.

Probing the HID interface directly shows the device replies to every status
request with a zero-length payload. It is not that the response is
misparsed; there is no data in it to parse.

This looks like the same underlying problem as #460 (Maxwell 1), and the two
drivers send byte-identical packets, so a fix likely covers both.

Environment

What headsetcontrol reports

$ headsetcontrol -b -m -o json
      "device": "Audeze Maxwell 2",
      "id_vendor": "0x3329",
      "id_product": "0x4b29",
      "battery": { "status": "BATTERY_UNAVAILABLE", "level": -1 },
      "chatmix": 0

What the device actually returns

I replayed the driver's exact sequence — all 15 UNIQUE_REQUESTS then all 6
STATUS_REQUESTS, 62-byte writes, 60ms delays, HIDIOCGINPUT with
buf[0] = 0x07 — straight against /dev/hidraw4. Every single response, for
all 21 packets:

07 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...

All payload bytes zero. No D6 0C 00 00 battery marker anywhere in any
response, so getDeviceStatus() takes the BATTERY_UNAVAILABLE path
correctly — there is genuinely nothing there.

Two details that suggest the device understands the framing and is declining
the command rather than failing to parse it:

1. Byte 1 looks like a length field, and the device answers with zero.
   Requests carry 0x08 / 0x07 / 0x09 there; every reply carries 0x00.
2. Byte 2 mirrors the request. All requests with byte 2 = 0x80 get
   07 00 80 ... back. UNIQUE_REQUESTS[6], the only one with byte 2 = 0x00,
   gets 07 00 00 ... back. So the dongle is echoing header state, not
   returning payload.

Transports tried

Ruled out

• Permissions — the shipped rule matches (3329:4b29, TAG+="uaccess"),
  the ACL grants my user rw, and the node opens O_RDWR from an unprivileged
  process.
• Wrong interface — interface 5 is the only HID interface on the device,
  matching getCapabilityDetail's interface_id = 5.
• Wrong usage page — the report descriptor declares 0xff13, as expected.
• Wrong message size — the descriptor gives report 6 output = 61 payload
  bytes and report 7 input = 61, i.e. 62 with the report ID. MSG_SIZE = 62
  is correct.
• Headset asleep or unlinked — audio streams through the dongle at
  48kHz/24-bit throughout, and the same zero responses come back while it does.
• Version — the 4.0.0→master diff for audeze_maxwell2.hpp is only the
  status-reuse caching from perf(audeze): answer every info capability from one status read #550; packet sequences and parsing are identical, so
  4.1.0 behaves the same.

Also tried, also no response

Following the RACE protocol notes in
kats1123/maxwell-firmware-research
(which documents this exact framing: 06 [LEN] 80 05 5A [PLEN] 00 [CMD...],
polled GetInputReport on report ID 0x07, and a battery query of
06 07 80 05 5A 03 00 D6 0C — byte-for-byte what the driver sends):

• Delay between write and read. That write-up notes a read issued
  immediately after a write returns stale data, and sendGetInputReport()
  sleeps 60ms before the write then reads immediately after it. I tried
  delays of 0, 5, 10, 20, 40, 60, 100, 200 and 400ms between the write and the
  read, and polling the input report continuously for 1s. Always
  07 00 80 00 00....
• Routing byte. Byte 2 appears to select dongle-local (0x00) versus relay
  to headset (0x80). I swept all 256 values for the battery query; none
  produced a non-zero-length reply.

A documented response looks like 05 5B 06 00 01 09 2F 00 00 <state> — RACE
response magic 0x5B and a real length. Nothing I send produces a frame
containing 0x5B at all.

Likely a firmware revision difference

audeze_maxwell.hpp and audeze_maxwell2.hpp contain identical
UNIQUE_REQUESTS and STATUS_REQUESTS arrays. Given #460 reports the same
BATTERY_UNAVAILABLE on Maxwell 1, I suspect a firmware generation that
changed or gated these opcodes, affecting both models rather than one.

If a maintainer can say which firmware version the original implementation was
developed against, I'm happy to compare against mine and help narrow it.

Secondary: setters report success unconditionally

sendGetInputReport() only checks that the read returned MSG_SIZE bytes:

auto read_result = getInputReport(device_handle, tempBuff);
if (!read_result || *read_result != MSG_SIZE) {
    return DeviceError::hidError("Failed to get input report");
}

62 zero bytes satisfy that, so on this hardware every setter returns
success regardless of what the device did:

$ headsetcontrol -s 128 -o json
  "actions": [ { "capability": "CAP_SIDETONE", "status": "success", "value": 128 } ]

Here the write genuinely did apply, so that particular line is honest. But the
check cannot distinguish an applied write from an ignored one, which made this
considerably harder to diagnose — I only established that writes work by
setting sidetone to maximum and listening for it. Treating a zero-length reply
as a failure, or validating the echoed header, would surface real write errors.

Reproduction script

The probe used above is a single standalone Python file with no dependencies
(opens /dev/hidraw*, replays the two sequences, dumps every response and
flags the D6 0C 00 00 marker). Happy to attach it or open a PR adding it
under a debug/ directory if that would be useful for triaging Audeze reports.