Bonjour,
Le Wed, 14 Dec 2016 20:23:39 +0100 dumblob dumblob@gmail.com a écrit:
Hi Albert,
Speaking of which, only the drivers should be affected by detaching /
attaching a detachable keyboard, and precisely, the drivers should handle things so that upper layers don't need to care about the keyboard attached/detached state (except very specific parts of the UI, e.g. to show the detached/attached state and/or pop up a software keyboard when the HW one is not here and keyboard input is needed). Most certainly "all daemons up to GUI" should not be involved IMO.
Actually, not only driver needs to know it. Kernel needs to correctly pass the info about what has happened to HAL (udev, etc.), then daemons reacting to attaching/detaching devices (dbus, *bus, systemd, running terminals, PAM, etc.) up to GUI (window manager must not reset the layout; all input methods like SCIM/IBus/uim must preserve all pressed states etc.; mappings of different long-running applications like widgets or icons in tray should keep their state; user shortcuts must not get lost; running applications should not reset any input streams to not interrupt the current functionality, etc.).
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?
All these have to handle the interruptions in a way, that they exactly (!) set the full device state back to the state before interruption. They also need to support these interruptions coming very quickly consecutively (e.g. each milisecond).
Basically such interruption demands a full hot swap functionality, which is basically not present anywhere in the stack I described above (yeah, 99.99% daemons and applications count on the fact, that the initial state will not change during their runtime).
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.
Joke apart, I really don't agree with your description of systems as holistic constructions which would be affected throughout by any event happening in a device (except, precisely, from a holistic viewpoint, which I like in Dirk Gently, but carefully avoid in my day-to-day embedded developing and debugging). Mastering complex SW is precisely about avoiding that all things be interconnected (alright, not *only* about that, but about that too).
It's really extremely frustrating when an old USB connector looses contact for a milisecond and my external keyboard gets redected and all the settings are totally lost (in terminal a different keyboard and without my key bindings - which might be impossible to manually reset because of the need of root permissions; the same in X except for the root permissions; the same with all running applications; the same everywhere).
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.
But not all setups require continuous connection, far from that, and for keyboards particularly, disconnection and reconnection scenarios are known and handled cleanly without all application code needing to be written specially for that.
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?
-- Jan
Amicalement,