Correction

[Mihail Konev]

> Make sure device removes are processed before doing a VT switch,
> so that no removes are "overwritten" with attachments afterwards
> (before the main thread releases the input lock, letting them be
> processed), which would leave affected devices disabled.

The dev->state is not "overwritten with device_state_added",
but instead not "written with" (as on returning from VT switch,
InputThreadRegisterDev sees a dev with .state == device_state_removed,
and assumes that it is a device_state_running one).

Always overwriting with a device_state_added gave no change
(or perhaps mouse disabled also).
Neither did overwriting with a device_state_running.

The misbehaving keyboard, however, did always got disabled for while on
another VT -- X wasn't receiving any keystrokes.

So it was getting either disabled or not-re-enabled due to a combined
state of a "real" and one or more "virtual" device(s).