Just started noticing this a couple days ago. Not sure if this should be posted to GitHub, since maybe I’m holding it wrong. My original context is rather different from what’s shown here, but here’s the minimal reproducible example I’ve arrived at:
- Call a command over USB, such as
setLedTxt or set backlight.keyRgb.base.*
- Call
printStatus over USB
- “ERR” is now displayed on UHK
- Call
printStatus, get shown error message saying Unrecognized command: <some fragment of the original command from step 1>
Here are two examples, one with setLedTxt, one with set backlight. (Note: I’m using the “tee” version of the UHK command script that Max posted here to show what’s being sent to the UHK.)
$ uhkcmd setLedTxt 500 "ABC"
setLedTxt 500 ABC
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at 1/2/1: Unrecognized command: 0> 2 | 0 ABCError at 1/2/1: Unrecognized command: 0> 2 | 0 ABC
$ uhkcmd set backlight.keyRgb.base.1 51 192 0
set backlight.keyRgb.base.1 51 192 0
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at 1/2/1: Unrecognized command: t.keyRgb.base.1> 2 | t.keyRgb.base.1 51 192 0Error at 1/2/1: Unrecognized command: t.keyRgb.base.1> 2 | t.keyRgb.base.1 51 192 0
From my testing, executing these macro commands from a macro did not cause the same problem, even with an intervening delayUntil to replicate the pause between my manual executions of uhkcmd.
The closest GitHub issue I found is 993, but that’s now closed and looks like it was for the UHK80 anyway.
For my testing purposes, I’ve reset my UHK’s configuration to default. I first noticed this problem on firmware 13.0.0, and have done most of my troubleshooting on 13.0.2.
I forgot to note: the issued commands (e.g. setLedTxt) all seem to actually work without issue. Even after the error status is triggered, further issued commands continue to work.
Added some file locking to uhkcmd to queue concurrent calls/prevent simultaneous writes to the /dev/hidraw device. Just in case I there’s something on my system calling uhkcmd that I hadn’t already disabled for troubleshooting.
#!/bin/bash
# if flock is installed, use it to queue calls to this script
if command -v flock > /dev/null; then
exec 42<"$0" || exit 1
flock -x 42
fi
hidraw=`grep 'UHK 60' /sys/class/hidraw/hidraw*/device/uevent | LC_ALL=C sort -rh | head -n 1 | grep -o 'hidraw[0-9][0-9]*'`
echo -e "\x14$*" | tee "/dev/$hidraw"
Is your Agent running? If so, please close it and powercycle the UHK, then retry.
(If no, then powercycle the UHK and retry anyways please.)
Thanks, Karel. I hadn’t actually thought to close Agent before, I don’t think.
But unfortunately, those steps didn’t change anything.
I’ve booted into an older kernel (Fedora’s 6.14.2-300.fc42.x86_64) whose release predates my problem (and I’m moderately sure I was running it before the problem as well).
I’m going to try to get my hands on a USB drive and boot another OS to try and isolate that aspect. But I don’t know when I’ll be able to do that.
Do you make anything of the fact that commands that are “unrecognized” (e.g. 0 or t.keyRgb.base.1) are both 13 characters into the command string?
Also, I just randomly got newlines (and enter-key presses?) when replicating again. I can only intermittently replicate the newlines.
$ uhkcmd setLedTxt 512 "ABC"
setLedTxt 512 ABC
$ uhkcmd printStatus
printStatus
$ uhkcmd printStatus
printStatus
$ Error at 1/2/1: Unrecognized command: 2
> 2 |bash: Error: command not found...
2 ABC
Error at 1/2/1: Unrecognized command: 2
> 2 | 2 ABC
$ > 2 | 2 ABC
bash: 2: command not found...
$ Error at 1/2/1: Unrecognized command: 2
bash: Error: command not found...
$ > 2 | 2 ABC
bash: 2: command not found...
The 13 character part is strange, but it doesnt ring any bell. I have tried your commands and they worked fine for me with 13.0.2 development firmware.
If you post your UserConfig, I am happy to retest with it.
(Please generally use printStatus in a text editor ;-).)
Super. Here is the config in pastebin kinda thing (not sure if there is a better way to share configs since json/txt/et al. aren’t allowed as attachments). I’ve commented out the clearStatuses that I added as workarounds to shut the UHK up.
Grepping throught my ~/.config, these are the only two places where I call uhkcmd:
uhkcmd "setLedTxt 0 '$statusstring'" > /dev/null &
uhkcmd "exec bellPause" > /dev/null &
Sorry, I have forgotten about this!
I have tested with your UserConfig, and everything still works fine with both mine and max’s script.
Let’s dive deeper. Please flash this firmware:
Then:
- Remove any macro events from your UserConfig (either backup your config, or just prefix them with ‘_’…)
- Save the config.
- Kill Agent.
- Run your uhkcmd command. (Exactly one command. Not a sequence of uhkcmd calls.)
- Open Agent again.
- Copy and paste the log.
I am seeing this:
1 Like
