Fun fact, we can control and use the touch screen without ulcmd if we write our own replacement without it being a giant PITA due to reversing some USB protocol. This is because the touch screen talks to ulcmd via a USB UART bridge (ttyACM0) at 9600, and this is how JSON payloads are sent between it and ulcmd.
We could write our own python service to manage the screen for us, but we would have to reverse the commands/payloads from ulcmd. From what I know most messages have the following format:
Send:
{"id":294702567,"ui":{"usage.cpu":3}}
Response from screen:
{"id":294702567,"status":"ok"}
You can run ulcmd -c -d to watch the messages between both as ulcmd runs, but we would need to capture all cases and messages sent to the screen to build our own full featured replacement but I feel it's worth it to be able to no longer strip ulcmd out of the Ubiquiti firmware.
Fun fact, we can control and use the touch screen without ulcmd if we write our own replacement without it being a giant PITA due to reversing some USB protocol. This is because the touch screen talks to ulcmd via a USB UART bridge (ttyACM0) at 9600, and this is how JSON payloads are sent between it and ulcmd.
We could write our own python service to manage the screen for us, but we would have to reverse the commands/payloads from ulcmd. From what I know most messages have the following format:
Send:
Response from screen:
You can run
ulcmd -c -dto watch the messages between both as ulcmd runs, but we would need to capture all cases and messages sent to the screen to build our own full featured replacement but I feel it's worth it to be able to no longer strip ulcmd out of the Ubiquiti firmware.