Also whoever's decision it was that if you drop the right 10px at the left edge of the screen, it should only show those 10px and not overlap onto the neighbouring screen by default obviously does not use double monitors.
However, the IT support had a list of 'recommended' distros (Ubuntu LTS if memory serves) and kernels and they preferred very much if you stuck to those.
One thing I've found that's drastically cut down on the frequency (possibly eliminated it? not sure) is this: Always wait ten seconds between display state changes. Waking the computer up from sleep? Wait ten seconds before you dock it or connect an external monitor. Undocking it? Wait ten seconds before putting it to sleep.
Also: never make more than one state change at a time. For example, don't put the computer to sleep while docked, then undock it. Undock it first, wait ten seconds, then put it to sleep.
YMMV, but like I said: I think this has eliminated this problem for me. I've been using this process for some months now, and I'm doing much better at the uptime game (28 days since my last restart, right now).
Yes, that's a good thumb rule when dealing with hardware+software. Not just for displays either. Seen many cases of it. I have a USB modem for mobile Net, for which I wait for a few seconds after it shows the login dialog, to make sure it has fully initialized, even though the dialog seems to indicate it is ready. If I click Connect in the dialog a few seconds too early, it connects but often then the speed comes down to zero quickly. Disconnecting, closing the dialog, removing the modem, waiting 5 seconds, plugging it back in, waiting for the dialog to come up again, and then waiting an extra 5 or so seconds, fixes the issue.
Remember issues like this from my system engineer days too (Unix and related support to customers in the field). Once a Unix minicomputer was not booting. (Was working for a large Indian Unix hardware vendor then - India got Unix early and became a Unix country, because of an RBI mandate on bank computerization.) This was at a hospital and they had a lot of critical patient and billing data on it. Backups could have been restored after changing the hard disk, but that would mean machine downtime on a live hospital system. Maybe a lot of time to get a replacement hard disk too, from head office.
Others had tried - hardware engineers. I was called in (I was a system engineer, aka software troubleshooter). Tried rebooting. Did not work - hung before kernel boot messages. Rebooted again. No luck. Did it again. Nope. Others said, drop it, lets try something else. I said - wait. Rebooted it again. It came up fine. End of story :)
Of course, I did a lot of other (and some harder) kinds of troubleshooting stuff in that role too, not just rebooting boxes :) But the point is that this kind of experience and common sense often worked when sometimes other things didn't. So it takes all kinds of skills ...
Yes, good point, and a fundamental tenet of troubleshooting in general. Also to make each change reversible, as far as possible. You can bork a system by one innocent / ignorant change to a config file in /etc, for example. A lot of us learned it on our own (sometimes the hard way, ha ha, got a few stories there), later I also saw it mentioned in an early part of the O'Reilly book Unix System Administration by Aileen Frisch. Very good book, as is another book (thick one) by Nemeth et al - the Unix System Administration Handbook (later there was a Linux edition too).
Randomly the keyboard attached to the dock doesn't initialize and I need to unplug and replug.
Unreliable docking is IMO an excellent reason not to use Linux on laptops. And most people use laptops these days because of work from home optionality.
This is with a mix of Dell and Lenovo laptops with Intel display chipsets, fwiw.