Modern mobile SoC's can probably be hard bricked even by accident. Run a kernel image that is not intended for the exact model of your hardware, and you incur the risk of e.g. misconfiguring some voltage regulators and trashing some arbitrary part of the SoC beyond recovery. (And the whole thing a huge mess because the patched kernel code is often the only kind of hardware documentation that's actually available for the SoC - hardware designers work directly on the kernel support, and implement all sorts of horrible, undocumented hacks in the process. Though I can only assume that the recently-mainlined SoC's and the IoT-ish designs that are being repurposed by the likes of Purism are somewhat better from that POV.)

Configuration (including boot or memory setup, crypto keys validating firmware, ...) also is sometimes in write-once fuses you can set from software.

I've been told just failing to set up clock trees right can burn some things up.

Or in the bad old days of CRTs and XF86Config, Modeline [0]:

  You shouldn't use monitor timing values or ModeLine values for
  monitors other than the model that you own. If you attempt to drive
  the monitor at a frequency for which it was not designed, you can
  damage or even destroy it.

[0] http://www.faqs.org/faqs/linux/howto/XFree86/

This warning was probably obsolete even when the FAQ was written (in 1995), though. Multisync monitors were already pretty standard at that point, and they could usually recognize an out-of-range input and display a warning on screen.

It's possible that someone damaged a really old single-scan monitor with a bad XFree86 configuration, but I wouldn't be surprised if this were just a rumor which got propagated through warnings in FAQs.

Any VGA monitor is inherently multisync, which does not imply that it is capable of detecting that horizontal scan is too fast to be safe.

The mechanism by which damage occurs involve the fact that essentially everything inside the monitor is synchronized with horizontal scan, including HV power supply for the CRT (usually even the main SMPS is synchronized with horizontal scan to reduce switching noise). And efficiency of both horizontal scan circuitry and the HV power supply depends on the incoming frequency and it is perfectly possible that some frequency (usually, but not necessarily higher than indended) will cause over voltage somewhere.

I have destroyed one small monochrome VGA monitor (the kind used in late 90's on cash registers) by just blindly switching the output to some SVGA mode, it even involved quite loud bang from inside of it.

It was possible. I did it by hand with a Windows 98 machine, the OS adverted me on trying to set up the resolution to 800x600. A pitched buzz began and the CRT I was using in some sort of academy bugged off with some burnish smell. No smoke, but you noticed it a bit. The screen had a SVGA resolution by default, so it may have been from 1995 or so.

I hope it wasn't intentional because that sounds like it cost that academy a monitor.

It was my fault, I was just trying.

I killed a vga monitor ~2000 trying to install redhat on a machine with an old monitor. Made me really paranoid every time I tried to install X for the next few years.

As a burst of nostalgia, do you remember using Linuxconf on that machine? I kinda miss the early GTK+ and GNOME1 days, whilst I fumbled with fvwm under RedHat (before the Fedora split).

I don’t think I knew enough at the time to remember. Linuxconf sounds familiar though, I’m sure I used it at some point.

I was poor and using a secondhand "due to be thrown out" IBM 12" display (which despite being 12" had a colossal black border around the actual image on the screen, making the usable area even smaller than 12") and had a 486 DX2 whilst everyone else had Pentiums. I remember fumbling around to get my abysmal graphics card working under XFree86 whilst groping around magazines for appropriate commands and setting the configuration to various bad values that caused that monitor to make hellish screaming noises as I attempted to set it to a resolution and frequency higher than it could ever go.

I should have read the warning.

Also, (IIRC) if you had a monochrome display driven by a Hercules card, and accidentally or intentionally set the horizontal refresh rate to zero, your monitor was toast.

The weird thing I remember with Hercules cards was that their memory was square even if the display wasn't. In other words, if your screen was 720x350, you could set up X for 720x720 and scroll down past the bottom edge of the screen to expose a bigger area than fits on the visible part of the screen.

I assume it's still the same on all graphics boards today, but I haven't seen this bidirectional desktop scrolling since back in the Hercules days.

I never had a Hercules, but that virtual desktop automatic panning was a general feature of XFree86. It was especially useful back then when we had CRTs capable of myriad native video modes.

In XFree86 you'd switch through them with ctrl-alt-+ and ctrl-alt--, the monitor's video mode would change but the virtual desktop size stayed the same. Whenever the monitor showed less than the entire virtual desktop, the viewport would pan within the virtual desktop when the pointer moved past the screen edges.

Yup exactly. I think most people didn't realize if they set X for a square screen, they could scroll all over the place. I'd forgotten that it was called a viewport.

And of course, my favourite was all the custom/customizable video modes that Hercules had silently lurking on the board. Some of the early 32-bit desktops (like the 32032) used 4-colour Hercules at 1024x1024. I don't think 16 and 8 bit PeeCees were capable of going that far, though.