Add TAP commands mode#12
Conversation
|
The simple functions like pl/sn/vr/sh work fine, but the parameterized ones from the manual don't seem to return anything but a blank report. I wondered if they were nulling the whitespace but that does not seem to be the case. Perhaps it is something like Command + atoi(parameter) + 0x00, will have to experiment or disassemble the DFU image to find out. Edit: Sending 'ba' + 0x4 just reboots the unit due to presumed malformed command, 'ba' + 0x4 + 0x00 still just sends back an empty response. (As opposed to the battery percentage) |
tchebb
left a comment
tchebb
left a comment
There was a problem hiding this comment.
Thanks! I'm happy to add this functionality—I'd seen that manual before, but I'd never noticed the section on TAP commands. Good to know what they're called.
I left a few comments on the code. Can you also update the usage block in the README and maybe provide a brief description of what this subcommand is for? Something like what you already wrote in the PR is just fine.
Sorry about the clippy failures on main. I've pushed a commit to fix those, so if you rebase the builds should succeed.
There's a known issue #5 that the SoundLink Mini II omits the first byte from TAP responses. If the response is only supposed to be one byte, that could explain what you're seeing. I think the most likely cause is that the SoundLink Mini II, unlike the SoundLink Color II, only has one HID report in normal mode, which per the spec means the report ID is omitted. Since we don't parse the HID descriptor, we strip the report ID unconditionally. (Or maybe hidapi does for us? It's been a while since I looked at that.) I'm not at my main computer now and don't have access to my speaker, but I'll try to get that issue fixed in a few days when I get back. That should make this mode much more useful. |
|
OK, I'm making those changes, hold on... |
1: use .is_empty() 2: use rustyline 3: reduce common code 4: move tap loop into main.rs I also did a minor change to only strip the first byte of the response if it matches the report ID
|
I cant figure out why rustyline wont save the history file, or indeed do anything with the history, but line editing seems to work... |
tchebb
left a comment
tchebb
left a comment
There was a problem hiding this comment.
Thanks, this is almost ready to merge now! Just minor feedback left.
On your device, it might not be—it definitely doesn't seem to be included in responses like it was on the device I tested with. But on my device (SoundLink Color II), it definitely is a Report ID, since there are other HID reports that I also observed in the USB capture. If increasing that number makes commands work for you, let me know. That'd be an interesting difference between devices. |
No, it does not work on my device, instead I get a DeviceIoError...
|
1: Remove unneccesary features from rustyline 2: Fix command history 3: Remove history file 4: Fix typo's in README.md 5: Fix comment in run_tap_command 6: Use escape_ascii instead of from_utf8 7: Remove Soundlink mini II hack to get full output string
|
Hm, perhaps we should step version number to 1.2.0? |
I'll handle a version bump and release in a separate commit.
No need to apologize! I really appreciate the contribution. |
|
Merged! Thanks again. |
|
It'll probably be a week or so before I can cut a new release, since I'd like to get back home to my own device and do some testing first. |
|
No worries, take your time |
3 participants
A minor change to allow a sort of terminal command mode (a la Polycomm.zip) used for servicing. In particular useful to put a device in shipmode for a more safe battery replacement, see Soundlink mini II service manual page 30 and on for some example uses...