| 1 |
# Re-evaluate the USB keyboard gate whenever the input subsystem changes. |
| 2 |
# |
| 3 |
# The gate itself is usr/bin/alloy-usb-gate and alloy-usb-gate.service; this is |
| 4 |
# only what makes it continuous. The ruling behind it (GoingsOn alloy 63de3d4c) |
| 5 |
# asks for evaluation on every attach and detach rather than once at boot, |
| 6 |
# because a keyboard that dies mid-session is the same lockout as one that was |
| 7 |
# never there, and a boot-only check has already passed by then. |
| 8 |
# |
| 9 |
# `add` and `remove` both, and the remove is the important one: that is the |
| 10 |
# edge where the machine loses its last keyboard. |
| 11 |
# |
| 12 |
# Starting a unit rather than doing the work in `RUN+=`, for two reasons that |
| 13 |
# are both hard rules rather than preferences. udev kills a `RUN` program that |
| 14 |
# outlives the event it was spawned for, and this one stops a service and |
| 15 |
# authorizes every device on the bus. And the script calls `udevadm info`, which |
| 16 |
# from inside udev's own event context is how a rule deadlocks against the |
| 17 |
# daemon running it. |
| 18 |
# |
| 19 |
# `--no-block` for the same reason: the rule must return immediately, and |
| 20 |
# whether the gate has finished deciding is not something udev needs to wait for. |
| 21 |
# |
| 22 |
# 70- puts this after udev's own input_id builtin has run, which is what sets |
| 23 |
# the ID_INPUT_KEYBOARD property the script reads. A rule numbered ahead of it |
| 24 |
# would read the property before anything had written it and would count zero |
| 25 |
# keyboards on a machine full of them. |
| 26 |
|
| 27 |
SUBSYSTEM=="input", ACTION=="add|remove", RUN+="/usr/bin/systemctl start --no-block alloy-usb-gate.service" |
| 28 |
|