Closed npiegdon closed 2 months ago
thanks for reporting this.
to be honest, i have not done much testing on windows :) but that byte sequence should be correct at byte 10 should be 0x01 and byte 11 should be 0x92 which are sufficient to hold in u8 data type. regardless, it seems it is not working and something is crashing so i will try this out as i have a 0x8890 device when i get a chance and report back
after looking at this a bit more, it appears what you stated is correct. media keys > 0xff cannot be programmed, but that is because i believe the device does not support it. using the manufacturers software the only multimedia keys they support are play/pause, prev song, next song, mute, volume up and volume down.
i will make a change to validate to check for this on this device. other devices (namely pid 0x884x) support this. sorry, this was an oversight on my part when i added support for the 0x8890 device
Thanks for looking into this! I saw that one of the manufacturer's apps (the "new version" that looks like it has a Qt-based UI) had a calculator key but after checking again I wasn't able to get it to connect to my 0x8890 device.
Checking their older, .NET-based Windows Forms app which does work with my device, there isn't a calculator key so I suspect you are right that it doesn't support wider-than-8-bit key codes.
I found a workaround: I just treat the buttons as F13, F14, etc. and use AutoHotkey on Windows to intercept the generic presses and turn them into whatever I like. So I got my calculator button in the end! 🤣
Thanks again.
yay! glad you found a creative way to get it to work.
If you try to use one of the media keys in the upper part of the allowed range (say, "calculator" with a value of 0x192), the config file will validate just fine, but upon trying to program the device I am getting:
I'm not familiar with Rust but I'm guessing it's the
to_u8
part that is failing because 0x192 is larger than a u8 can hold.(Thank you for this tool! Everything else is working great.)