Blocking input while maintaing access to the programming port (Linux)

I just wanted to put this here in case anyone else ever needs to do the same thing:

I managed to mess up my custom firmware in such a way that it would constantly spam out keypress events as soon as I plugged it in; this made it hard to use my computer with my Model 01 plugged in, yet I needed to have it plugged in to upload a new firmware. What I finally ended up with was to put this:

SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="2301", DRIVER=="usbhid", ATTR{authorized}="0"

in a udev rule (eg. /etc/udev/rules.d/80-block-keyboardio.rules)

This prevents the kernel from accepting keyboard, mouse, etc. input from the Model 01, while leaving access to ttyACM0 to upload new firmware.

4 Likes

I made the same mistake a little while ago: Unicode plugin feedback / Macros feedback / How to fix infinite typing

Your solution is much cooler, though :slight_smile:

A simpler solution that has worked pretty well for me in this situation is to unplug the Model01, run make flash, then, when prompted to press enter, I hold down the prog key, plug in the Model01, and quickly tap enter on a different keyboard. This usually starts flashing the keyboard before the bootloader times out, so I don’t get any input from the Model01.

This is exactly how I broke my firmware too - using unicode.type() in a macro :slight_smile: