> the touchbar software also had to run on the same CPU
It actually ran on the separate T1 CPU.
It actually ran on the separate T1 CPU.
Thanks for the clarification, I guess that didn't really change the result. Perhaps the Intel CPU was busy burning CPU cycles and couldn't process interrupts properly, or because the communication was USB-based, it couldn't reliably deliver the required messages. The end result for me was that whenever I needed to use the ESC key, it wasn't available/visible or was unresponsive.
Out of curiosity.
The Tx SoCs themselves should have never locked up because there was a watchdog that would power cycle it when it became unresponsive.
The Wikipedia page linked in your other comment reports: "The T2 communicates with the host via a USB-attached Ethernet port.". So in the end it's really both, Ethernet AND USB.
> The Tx SoCs themselves should have never locked up because there was a watchdog that would power cycle it when it became unresponsive.
Perhaps I was reaching in the corner too far due to physical ESC muscle memory and it wasn't being registered by the touchbar, but regardless, being eth-over-usb means there was a server or kernel process listening on the Intel side to process those keys and raise them as interrupts or keyboard events. I guess sometimes, when some misbehaving application was already stealing all the Intel CPU capabilities or the kernel or some kernel extension had an issue, the touchbar could become unresponsive due to the load on the Intel side, with the T2 part being perfectly fine. And I did get at least a couple dozen times a completely frozen touchbar that left me with no choice but to reboot the system.