I want to handle custom data inside the keyboard. With qmk I did this with RAWHID.
Is this be possible with the UHK60 V2 too?
If yes, is it also possible to extend the macro language of the keyboard that I can handle the data there?
Thanks
1 Like
I now reply to this because I think it is not possible to do that.
I bought the UHK60 the last days and the keyboard is till now not on my desk but I sent it back bebause I cant do what I already do with other QMK keyboards like ZSA Voyager/Keychron.
The name of this keyboard is in my opinion totally missleading. One User has quoted in the forum:
The term Ultimate Hacking Keyboard, besides the name and the marketing perspective, does create several expectations, especially from the ones that come from qmk/zmk and tendency is to have a continuous experience rather than a limited one. Definitely, the power points of the keyboard are the modules primarily and the build quality of the board itself, but these should not replace a previous user experience and call it a compromise. It should extent and improve. … I hope you understand what I am saying :).
1 Like
Sorry, forgotten about this topic 
.
You can use the hid command interface for custom commands and data communication, as long as you don’t mind doing C coding. There is (not much) support for that in place though.
Specifically see:
- firmware/right/src/usb_commands; They are managed from right/src/usb_protocol_handler.c
- agent/packages/usb, especially packages/usb/send-command.ts that allows you to send custom payload - we use that for prototyping; --log=usb is useful for many of the scripts
- As for triggering usb commands directly via raw hid, see end of firmware/doc-dev/user-guide.md at master · UltimateHackingKeyboard/firmware · GitHub
At the moment you can already use the agent/packages/usb/exec-macro-command.ts to execute a macro, which you can use to set macro variable values (they are global; their number is limited to 32, although increasing that should be easy), and to execute other macros via fork.This way has quite lited payload though (62 or so bytes per packet).
As for creating new macro commands, feel free to see firmware/right/src/macros/commands.c and ask questions, but be warned: it may be tricky.
As to the name, I completely agree. My command macro engine effort stemmed out of exactly the same frustration.
Thanks, is it also possible that the macro can sent something back?
This is what I also do with RAWHID. With my voyager I can get the actual layer and can set one. Sometimes this is helpful if I want automatically switch to an layer if a specific program opens or if I press a specific button on my Streamdeck.
No. Macros are not processes synchronously, so it is not possible to reply immediately. You would have to implement buffering and poll the buffer…
…which is something we have, although it is a text buffer, not raw data - you can print (text) into the status buffer via macros and then retrieve it via a usb command. Firmware outputs error there, and I occasionally use it to print stuff for debug purposes.
But there already are usb commands for retrieving layer and keymap.
Polling would be ok. I test it if I’ll have the keyboard in my hand.
Is the communication from the host to the keyboard over USB via a serial port or over HID?
Not sure. If I recall correctly, then it is outside of hid, so maybe serial?
Ok, what I understand so far is that I can get the layer and other information in the same way as the agent do this under the hood.
This means that I can do it on the host site also in C/C++ or in any other language, right?
Ok, what I understand so far is that I can get the layer and other information in the same way as the agent do this under the hood.
Yes!
This means that I can do it on the host site also in C/C++ or in any other language, right?
Sure!
We need a high-level description of what you’re after to help you the most effectively. This is the closest I found above:
With my voyager I can get the actual layer and can set one. Sometimes this is helpful if I want automatically switch to an layer if a specific program opens or if I press a specific button on my Streamdeck.
However, coming from QMK, I’m unsure if you know that the UHK supports multiple keymaps, each containing up to 12 layers. Hence, you may want to switch keymaps.
The name of this keyboard is in my opinion totally missleading. One User has quoted in the forum:
The term Ultimate Hacking Keyboard, besides the name and the marketing perspective, does create several expectations, especially from the ones that come from qmk/zmk and tendency is to have a continuous experience rather than a limited one. Definitely, the power points of the keyboard are the modules primarily and the build quality of the board itself, but these should not replace a previous user experience and call it a compromise. It should extent and improve. … I hope you understand what I am saying :).
I strongly disagree with the above. The UHK firmware is not QMK/ZMK, it’s not meant to be, and we never stated it is. It has its strengths that I can elaborate on, but it’s pointless if all one cares about is QMK/ZMK compatibility.
@ mlac, Yes, you can disagre but I uphold my view. The mentioning of QMK and ZMK or KMK is an example. The main point is the name of the product and the name implies something. For me this was the reason that I bought it in the first place.
Now with the help from Kareltucek I could do what I want to do.
The time I bought the keyboard I didnt realize that there is an successor/newer model of the keyboard therefore I want to give back the UHK60V2 and want to switch to the UHK80. I hope that this is possible.
According to our return policy, the products can be returned in 14 days. Please contact us to arrange it.
I written a mail yesterday in the early morning and since now no answer.
Why last this so long?
We don’t guarantee answers in 24 hours, although we do our best. We’ve been busy with the UHK 80, hence we’re a bit behind. My colleague will get back to you soon.