> windows handles it in its stride

Windows has serious bugs with multiple monitors as well. I switch the second monitor often (usually once or twice a day) and often it would have problems like blank screen on one (or sometimes two) monitors, whole system locking up, HDMI sound device not showing up so I have to play sound over laptop speakers instead of monitor/TV speakers, etc. It doesn't happen often, but it does happen.

I tried using Linux, Windows and Mac and they all have bugs regarding multiple monitor setup. If everything works smooth for you, you're just lucky that your usage doesn't fall into "corner cases".

In my personal anecdotal experience, Mac's multi-monitor support is the worst of the three (and I say that as a currently full-time and otherwise happy Mac user).

ethernet ? It is the most stable part of Linux since 25 years. Do you have a link to the bug report ?

It's funny that you say that, because I'm constantly having problems with e1000e driver on my Intel NUC. Ethernet card stops working and dmesg shows "hardware unit hung" message. Tried to upgrade driver to latest version, compiled from sources - didn't fix it.

I don’t, because I haven’t even investigated the issue myself. I get times where I can’t see the device, and have no connectivity. My solution: use windows.

I am running a 4 monitor setup with Linux Mint 18.2 (Cinnamon) just fine. I set it up two weeks ago and so far I am impressed how easy it was.

However, prior to this setup I had Win 7 on the machine with no issues either.

Reverse anecdote:

I can get my three monitors to work under Linux (trivially, actually), but I can't under Windows, and not for a lack of trying.

Under Windows I can decide which one gets turned off, but running all three is somehow denied. This, of course, with recent drivers straight from the manufacturer (AMD).

Baffling.

I do a lot of support on IRC Freenode #linux and #ubuntu and we get a lot of this kind of report. We see a 90% success rate with a simple-to-apply workaround.

This is so common I wrote an article and fix [0] for it containing 4 shell commands that we refer users to whenever we get these 'works OK in Windows but not in Linux' type of reports.

By far the biggest cause of these hardware issues relating to power (suspend/resume, power-states, platform device enablement, ports - including GPU outputs) not working correctly is not caused by Linux but by the PC firmware itself and is down to the manufacturers.

In short - manufacturers customise the ACPI (Advanced Configuration and Power Interface) DSDT (Differentiated System Description Table) via it's _OSI() method to recognise only Microsoft Windows OSs and enable functionality based on the Windows version.

The version strings are of the form "Windows 2009" "Windows 2015" etc., where the later the year the more functionality is enabled. This is a total misuse of the purpose of _OSI but almost all manufacturers are doing this now.

As a result when Linux is the OS often only a minimal or incomplete set of functionality is enabled which causes all sorts of problems.

For a long time Linux has had code to report itself as various Windows versions to try to solve the worst of these but in many cases unless it claims to be the exact 'best' Windows version for each model/DSDT there will still be problems.

From silly things like some devices not working if the PC starts on battery (but fine starting on AC) - recently saw this was the cause of an external HDMI port not being enabled - through not handling power-state switching correctly and thus draining the battery rapidly, to suspend/resume/shutdown freezes and other symptoms.

The solution has frequently been to set the OSI string to match the most recent Windows version the PC's ACPI DSDT recognises, on the basis that the most recent is likely to enable the most functionality, using the DSDT OSI string via kernel command-line acpi_osi="...".

Checking the supported OSI version strings is quite easy from Linux:

    sudo strings /sys/firmware/acpi/tables/DSDT | grep -i windows | sort

You'll get a sorted list with the most recent version generally at the end. E.g:

    Microsoft Windows
    Microsoft Windows NT
    Microsoft WindowsME: Millennium Edition
    Windows 2001
    Windows 2006
    Windows 2009
    Windows 2012
    Windows 2015

Adding the most recent version to the kernel command-line, either via the boot-menu at start-up to test it, but usually permanently via GRUB, in this form:

    acpi_osi=! "acpi_osi=Windows XXXX"

where XXXX is the latest year reported. The initial =! tells Linux not to offer any of it's hard-coded version strings via OSI - this guarantees the one that gets used is the one specified.

On most GRUB-based systems this is done by editing /etc/default/grub and adding the options into the GRUB_CMDLINE_LINUX variable (there may be other kernel options there too) thus:

    GRUB_CMDLINE_LINUX="acpi_osi=! \"acpi_osi=Windows XXXX\""

(note: the two \" are required to ensure the double-quote gets inserted onto the kernel command line surrounding the space in the version string)

then:

    sudo update-grub

Reboot and test.

[0] http://iam.tj/prototype/enhancements/Windows-acpi_osi.html

I might look into this but it’s not worth spending the time at right now. Unfortunately, and I mean no disrespect, but _its not my problem_. I have existing hardware that works well, it doesn’t matter if it’s the motherboard manufacturer, a kernel bug, a driver issue, it should work (which it does, on windows), and until it does, users won’t use it.

As an aside, that’s awful, and kudos to you for spending so much time looking into the issue and for a clear description of it along with a fix. It reminds me of the useragent nonsense - https://webaim.org/blog/user-agent-string-history/

Sometimes linux works fine, sometimes it doesn't and there will always be room for improvements. Fortunately I have three laptops, one for Win10, one for Arch and another for OSX, all have their quirks (but I must admit, arch linux is my preferred one:)).