I am far from convinced that all of this is sensitive to whether one
keyboard was plugged or unplugged from the system. Why would icons
in the tray be affected by the number of keyboards connected to the
computer, for instance?
I am having a hard time trying to make sense of what you're saying,
which is frustrating, as I've been doing embedded development for more
that 20 years. For instance:
- I am surprised that all of a sudden, all SW in a computer has to
handle interruptions. In my time (which extends to just about a few
days ago), only drivers did. "Driver" is basically the name we give
to thoses pieces of SW which handle interrupts (and talk to HW and do
DMA requests and...)
- Nor did any of the systems I worked, and still work on, require that
the full system state be saved and restored on interrupts; in fact,
if they did completely save and restore their state, they interrupts
would have no effect whatsoever, which would be a pity. Granted,
interrupt handlers must save whatever CPU resources they use, and
schedulers must do the same with task states; but that's hardly a
concern outside of these two cases.
- Finally, the daemons in my time /did/ expect their state to change all
the time. They actually were /intended/ to change state, in carefully
designed ways; a daemon executing in an immutable environment would
have little utility.
I don't know what is the setup on which you encounter these issues; on
mine, I can connect and disconnect keyboards at will, with nothing even
so much as flipping a bit when I do, and my keyboards don't even lose
their French layout :) -- same goes for USB devices which need to get
their firmware uploaded through USB; granted, every time I unplug and
replug them, thy take time to get their firmware /again/, and yes,
trying to use a video capture device won't work if you unplug it right
in the middle of it, but you can hardly expect otherwise, and it's only
logical that plugging it back won't fix the overall problem.
> An extreme case are security modules (e.g. YubiKey)
> or security SW demanding uninterrupted connection of a certain device
> (due to possible MiM attacks etc.).
As you say, this is an extreme example. In fact, it is precisely an
example of a setup where continuous connection is laid out a priori as
a /requirement/; no wonder, then, that discontinuity of connection is
not supported.
> Just my 2 cents from real world.
You should be careful with the way you express yourself: one could be
led to believe that here you are implying I would not know of the real
world whereas you do, and that this implied difference would make my
opinion less worthy than yours. But of course you are not implying
that, since you do no know me at all, right ?
So let's avoid anyone getting false ideas, and to that effect, let's
stay away from hypothetically real vs hypothetically unreal worlds, and
let's just keep to technical discussion with technical and precise
arguments. Shall we?