Something I learned not long ago on this site: low quality/too long HDMI cables can make some monitors go black when the user stands or sits on a certain kind of office chair. [1] [2]
Apparently it's a known issue at Dell: [3]
>Surprisingly, we have also seen this issue connected to gas lift office chairs. When people stand or sit on gas lift chairs, they can generate an EMI spike which is picked up on the video cables, causing a loss of sync. If you have users complaining about displays randomly flickering it could actually be connected to people sitting on gas lift chairs. Again swapping video cables, especially for ones with magnetic ferrite ring on the cable, can eliminate this problem. There is even a white paper about this issue.
This is an issue at our office. We have some cheaper LG monitors that flicker when someone stands up from his gas spring chair. The Dell monitors we have don’t suffer this issue.
A paper on the issue: https://www.emcesd.com/pdf/uesd99-w.pdf
Apparently a dangling bag of coins can cause similar issues, but haven’t encountered that so far.
> Apparently a dangling bag of coins can cause similar issues
A dangling bag of coins is a famous cheap EMC test for products. All of this sounds like monitor vendors cheaped out on their EMC and need to have their ESD and Immunity certifications reevaluated....
Or maybe it's just the fact that they were dumb enough to ship an I²C interface over a cable as part of the industry spec. Never ship I²C off-board or this kind of crap happens.
My own favorite trick was to put a 1st gen cellphone near the device and call it, or to fire a piezo based gas lighter with the shroud removed against device ground. This was for devices that stood a very good chance of being deployed in a hostile environment so being able to withstand that kind of interference wasn't a luxury.
Why are the monitor vendors at fault when the cables have the poor shielding?
We don't know who produced these cables nor where they came from. I'd wager it's mostly an issue with cheaper products, and you often don't get any cables if you're buying a cheap monitor, so they're likely from a third party.
> Why are the monitor vendors at fault when the cables have the poor shielding?
Because part of hardware engineering is making devices that function even in poor environments, and that tolerate foreseeable misuse. (This is a major part of medical device development, for example.) Cable shielding is always iffy on consumer-grade cables. If other vendors can produce monitors that tolerate its absence, because that seems to be reasonably common!, then if you can't, your products will be seen as inferior. Exactly as is happening here.
Cable shielding often is subpar on industry equipment too. Yes, they have bought shielded cables, no they have not connected the shielding to the expected locations on patch up. Or just wrapped it loosely around, so everytime somebody patches up a new RJ45, you get a new quality situation, cause the vibrations shake the roulett box. Finally, ground.. ground is the yellow green cable and it goes to ground - and ground should be something professional done. Not a network of suffering machinery, pumping hovering potential into one another.
Also dont trust all electricians. Lots of them just try and error, nod in terror. Some do not even speak the language of the e-plan they are cabling up.
A bit of a problem is that HDMI is very sensitive to EMC thanks to DVI (which forms its base) being essentially VGA minus the DAC step - there's even porches and overscan included in the signal. But this meant that you could make very cheap TV displays, which thanks to very limited set of frequencies involved in cables could be made to work "stable enough".
So imagine all the problems you could have, and multiply it by variable frequency cable that thanks to increases in resolution has to run way higher clocks than it used to, combined with being cheapest possible design, and that unlike it's analog origins an error in bitstream can now crash the connection instead of just causing temporarily off-colour area.
Yeah, the simplest possible circuitry for driving a flat panel TV from HDMI (except the HDCP block, which AFAIK can be placed inline before the display logic) would be to declare the 720i/p capability and then just... pump the data straight onto display interface with some buffers here and there meaning to drop the porches, driven all by HSync/VSync signal recovered from the HDMI clock. :V
That solves a lifelong mystery for me. I have twice had monitors that blink off right when I shift position or get up from my desk. I can tell it's caused by me moving, but I can never reproduce it. When it first started happening, I would aggressively shake the monitor cables and nothing happened. But I never considered that it could be my chair.
I put ferrite rings on a ton of stuff to reduce interference, so much I questioned how reasonable it was to do so. Thank you for providing additional confirmation bias for the things I do.
On the subject of interference, this is why a good amount of shop equipment doesn't use USB. Especially for vinyl cutters, serial/RS-232 tend to have less issues than USB. USB tends to be more sensitive to the static buildup caused by moving and cutting vinyl.
Similar but different: I have a 200m Ethernet run (PoE repeater midway), outdoors, FTP, going to a mast atop a hill.
There’s lightning protection etc. on the circuit.
It’s worked fine for several years.
Last week, we had a huge electrical storm - and every time lightning flashed within 8km, the switch at the cabin would reboot. Unplugged, stuck a scope on the Ethernet cable - and lo and behold, 30V+ flashes every time lightning struck anywhere even remotely nearby. The cable is acting like a great big antenna.
Have you looked at shielded twisted pair or optical fiber for that run? I have a similar project planned but at the moment I’m not looking forward to trenching the cable into the ground so it hasn’t moved forward yet.
I didn’t trench mine as I anticipated it might not be the ideal solution… plus it goes up a 45 degree hill, threads past cliffs, etc. - ran it inside a little 10mm slitted duct, at least, to protect it from friction, UV, and curious teeth.
I need it to be able to deliver PoE, which is why I went for Ethernet - but yeah, probably going to replace it with STP, although not sure that’s going to stop lightning induction in the earth/shielding. Other option is splashing out for SWA STP, which should definitely do the job.
For the other run, where I don’t need power, I’m using 802.11n with a pair of Yagis to go about a kilometre. No problems except the usual headaches around layers and discovery a Wi-Fi bridge provides.
I had a motherboard (an ASUS ROG Strix B550-E) that would frequently freeze when I stood up from my chair. I always figured it was something to do with static electricity discharging when I stood up, but no amount of fiddling with grounding helped. An EMI pulse from the gas lift getting picked up somewhere insufficiently shielded would explain it.
Interestingly, I also have a Steelcase Leap chair, as mentioned by someone else in this thread; maybe the gas lift they use is particularly prone to this? Other people also complained about freezes with this motherboard model, so perhaps the combination was particularly bad.
Holy crap, this is amazing. I've wondered about this a lot when it kept happening, and so far my most likely seeming theory had been 'static discharge through the carpet', or something like that... But the chair generating an EMI pulse? Hilarious
I have a lot of respect for this developer’s patience. Back when I was a solo developer, these types of issues were death by a thousand paper cuts. I didn’t have the skills to deal with the amount of support and debugging these kinds of problems entail. And it’s especially frustrating when the answer ends up being “It’s due to how the manufacturer of this monitor just didn’t properly implement the spec and there’s nothing I can do to fix it.” I can’t imagine writing software where this is the norm! So kudos to the developer!
Thank you! It is indeed a very frustrating kind of work.
But still, a lot less frustrating than waking up at 6 AM for a Zoom call with an overseas company I’d be working. I prefer angry users of my own app over demanding (and often not knowing what exactly they demand) bosses.
Even working within a larger organization it’s the sort of reason i avoid certain types of custom work.
I’m embedded in an operational unit and occasionally run up to limitations or bugs of the systems we use. It’s tempting to say “I can build a workaround in a day” but then accounting for edge cases, continued maintenance if/when patches/updates come along… I learned that eventually I’d be bogged down in maintaining bandaids and workarounds. Only truly important things get that treatment these days. I’ve seen the chaos that occurs when someone who’s gone too far down that path leaves the organization and central IT has no resources to support things and there’s no formal knowledge transfer because it was all essentially out of scope.
I purposely add friction via “in-app purchase” so users embrace the free trial. Less support issues when you help someone pre-purchase. Very low refund rate / at the expense of revenue. However, you can purchase a license via mobile at my store that sells a label printer: https://mydpi.com
The first issue, where multiple monitors have the same vendor/model/manufacture date/serial number, couldn't that be solved by also storing which port it's connected to? That way, if you have two HDMI ports, if both monitors have the same UUID, you store settings based on port rather than UUID. I don't know if this is possible with this new USB-C world, but at least with traditional hardware, it seems like the OS knows which port a monitor is connected to.
Anyways, interesting post. It's always fun to discover how much hardware is just broken and doesn't actually correctly implement the protocols or features it's supposed to implement.
If it detects a UUID collision, it should automatically drive to the manufacturer, kick in the door and keep punching faces until they start assigning proper serial numbers.
The manufacturer isn't assigning UUIDs, we're talking about what macOS considers a display UUID. MacOS will generate a UUID based on the manufacturer, the model, the manufacturing date and the serial number, and the intent is truly that these UUIDs uniquely identify the display. It just doesn't work when multiple monitors have the same serial number, which isn't supposed to happen.
I’ve seen similar problems with inexpensive Chinese wifi modules all shipping with an identical MAC address. Mostly you can Google up the method required to reflash them (or worst case, I’ve been out a dollar or two because it usually the ultra cheap things this happens on).
I strongly suspect that this is not the full picture.
I had this exact same issue, two displays, always connected to the same TB3 Dock, and they would randomly get re-assigned after wake-up. Which in my case was doubly irritating, since one of those is in portrait mode, so "fixing it" required tilting my head to be able to navigate the mouse correctly.
There's a small CLI utility called `displayplacer`[1], that basically fixed this for me. I don't... really know what exact EDID fields or whatever metadata it's reading, but after I used it once to "save" the correct orientation/placement, I could reset it to the "correct" one every time after that. Highly recommended if that's something you're struggling with.
Your problem might actually be caused by a timing bug, where the EDID is not fully available in the first few milliseconds of the reconnection, and the system doesn't reconcile after it becomes available.
displayplacer will get the full picture because it's always run a long time after the connection has stabilized.
I can't be certain, but I noticed some slow monitors/hubs do have that timing issue by observing the zero/null values for UUID in The Monitor Database: https://db.lunar.fyi
It’s crazy how many aspects of the electronics in monitors are seemingly phoned in, even on models exceeding $1000 in price. Problems like non-unique IDs and EDID not being available right away are such trivial issues to solve and probably wouldn’t even cost that much in the long run and yet here we are.
I wish a company like Framework or system76 would get into monitors and open source their monitors’ electronics and firmware so at the very least, these issues could be fixed by the community.
I'm surprised that the OS doesn't have a safeguards for this and isn't retrying the read the EDID after it sees a "blank" one after wake-up, but the display controllers in Mx chips are stupid complicated already it seems.
I’m sure there must be a retry with a backoff somewhere. But most of the times I noticed that the EDID is incomplete, not blank.
I don’t think there’s any way for the OS to know that there’s a more complete EDID if it tries again later.
That’s also my theory on why the Intel/AMD/NVidia GPUs feel more stable than the Apple Silicon ones: they had years of dealing with these edge cases and probably adding all the workarounds they could think of, while Apple is still catching up.
I had a TB3 dock with dual displays that was causing my 2019 16" MBP to KP sometimes*. I replaced that with individual separate DP adapters. Then I realized, if I always connect the screens in the same order with a few seconds' delay in between, I get the correct screen arrangement, I think. Not 100% sure because sometimes I forgot the ordering, haha.
* Which btw is the kind of rabbit hole that belongs in this article. That was a high-end CalDigit dock, so seeing KPs was surprising. These monitors even had USB-C inputs, but connecting both at once wouldn't work with this MBP model in particular due to a known incompatibility with its dedicated GPU. Older, newer, or lower-end MBPs were fine. Hence the dock adapting to DP. Another funny quirk is I was able to connect my Mac twice to the same screen (via USB-C and DP), and it thought they were separate screens.
I get kernel panics with my CalDigit dock too! Only since the most recent OS update though. Your post is inspiring me to unplug one monitor when I’m not using it and see if it helps. Thanks for the unintended suggestion!
Certainly, a bus scan has to happen to detect whether devices (including USB hubs) got unplugged or plugged in during standby, so if that scanning isn’t guaranteed to always produce the same result (e.g. because of jitter in the timing when various devices come online), I doubt that’s guaranteed to produce 100% identical information.
It’s a question, though. I don’t know enough of how this work to definitely answer that.
Back when I had two monitors, I got the same cables for both and I indiscriminately plugged them into my computer (I had a laptop, so plugging/unplugging happened ~daily). So the mapping between computer port and monitor definitely wasn't going to stay the same.
Yeah, it would be a workaround for some cases but not all. It would work in the case of a desktop system where the monitors are always plugged in, and it would work for the case where the monitors go through some kind of USB-C dock (assuming it's possible), but not in your case.
This should be at least theoretically possible -- in Windows, for instance, device file paths are based on connection topology, including port address.
I'm guessing this is caused by the monitors waking up in different orders. The computer tries to set em up as soon as possible even if they're in different ports. It would be nice if it detects when the collision happens and then put them in another list for monitors associated with their port. Or just have an option.
That's what I thought. I found some of these devices myself over the years and usually, they had serial numbers of 0 or 1. Could even Special-Case these and proactively include the port, in case the user indeed has another one and just has is unplugged currently.
> Blacking out [...] unplug the power cable, and plug it back again
As someone with a monitor that's prone to blacking out like this (not due to Lunar) and was at one point convinced that the monitor got bricked: the key is waiting ~5 minutes before plugging the power back in. A quick unplug-plug in a hurry might not do it. You need to wait for the internal capacitors to discharge to the point where the controller gets properly reset.
You might speed this up by unplugging the monitor, then holding down the monitor's power button for a few seconds to discharge its capacitors, then immediately plugging back in and powering-on. The only reason I can see to wait 5 minutes is so the capacitors will naturally discharge, but holding down the power button while the monitor is unplugged should immediately discharge them.
This is true only for some designs. It's possible you could have a power island that doesn't get discharged and also has no connection to any buttons when the board is nominally off, and that the things in that power island refuse to reset properly.
There's a whole area of electronics design related to this (unfortunately).
Yes, that's a good hint. Most monitor power bricks have very large capacitors, especially when they also charge the laptop through the Thunderbolt connection.
That's also the point of the LEDs you see on power bricks. After unplugging, the LED uses up the capacitor current to discharge them faster and also serves as a visual indicator to know when it's safe to plug back the cable.
I have some dells (U2414H) that can get into a really bad state. Sometimes unplugging power is not enough. You have to remove all potential power inputs including display input cables (or shut those devices down too) to get a proper reset.
My Samsung G7 monitor has this issue where DDC commands will occasionally lock it up to a black screen. I don't use Lunar as I'm on Windows (I use NirSoft's ControlMyMonitor).
On this monitor I can just unplug and plug the monitor back in and it immediately works again, but its an annoying enough issue and it happens frequently enough that I just stopped using DDC control for it altogether.
So if I have my cell phone (Galaxy S21) near my headphones USB cable, and there is activity on the mobile phone radio (I can hear the mobile phone 'radio' in my headphones), sometimes my monitors will black out. This has happened to a few other users at my office as well. Move the mobile phone a meter away from any cables and problem goes away.
I’ve run into this on the older ASUS model PB278Q. It’s otherwise a decent monitor, if a bit slow to turn on and switch sources by modern standards, but once in a while it’ll refuse to display anything and I’ll have to unplug it from power for a few seconds to “hard reset” it.
This is a kind of look behind the curtain that we rarely get from large software developers. Users are often told by someone down the chain in support it works or doesn't and no explanation why. I find this very fascinating and as a saas developer that makes an app that has to work with external hardware that I often don't have to test on very encouraging. Sometimes, there's no fix and it's not my fault.
I (have learned to) love working with hardware. There’s a specific tension between hardware developers (firmware) and software that runs closer to the user. I used to do a lot more consulting - building mobile apps that talked to BLE sensors, like refrigeration controllers, etc, and almost always the end user was a technician.
Now, I’m making apps specifically for non-technical users. I really love the challenge.
To come up with my app idea (and business) I tried to think about the worst possible hardware on the planet and thought label printers.
Turns out that the hardware is almost universally pretty good, but there was no software that worked for both Mac and windows, worked independent of device drivers, was easy to use, had modern conveniences, and didn’t cost hundreds of dollars.
At the same time my competitors are extracting as much value from the label printer landscape as possible, with a wake of irked users behind them. RFID in the label roll? Yep. Jacked up pricing and mandatory support subscriptions. Yep. More proprietary everything… yep.
I’m always looking for new markets and ideas. A year ago, when a competitor released a new printer with RFID, I got call after call asking me to bundle a printer with my app. At the time I didn’t find a compelling printer on the market … nothing that would set my business apart.
But then I found a Chinese manufacturer and read Hardware Hacker, and now I’ve got these awesome printers for sale, bundled with my design app! I’m competing in the 4” wide 300 DPI direct-thermal market. I’m not marketing this as a shipping label printer (that’s a solved problem), instead, it’s for making custom designed labels, usually with barcodes, usually with data from an external source.
That "if" does a lot in that sentence :) Just had a typical fun experience:
Customer: Your platform doesn't work, when we do this, A happens
Me: Hm, we don't have that feature, but I understand your use-case. We could deliver this new feature by tomorrow, but using it that way also inherently means B would happen in such and such cases, so just want to make sure that's what you want?
Customer: Let us know when the bug has been fixed, it's urgent and we're losing money because of you (they had 1 month free trial)
Me:: It's not a bu...okay, we will
Me: * works all night, builds a new feature, fully polished, notifies customer
Customer after 2 days: Yet ANOTHER bug with your unstable software!! * describes B
Unless this was a customer you absolutely needed you should not have given them control over your immediate development schedule. Offer refunds if relevant (sounds like not the case). Keep your sanity instead.
I've tried that in the past only to be told ' We've tried them and they are even worse than you lot are! They are rude, their stuff is full of bugs and their support staff are unhelpful.. '
>This is a kind of look behind the curtain that we rarely get from large software developers.
Very true, it makes me wonder just how unreliable hardware is and how many crashes are caused by random EMI like cosmic rays, or close proximity of other devices.
Maybe someone here can explain the following weird effect:
My previous laptop (an HP EliteBook, the exact model escapes me at the moment) had an issue with Linux drivers where it would sometimes crash. When it crashed, the laptop's screen would quickly flash bright-dark-bright-dark... To my eye it looked like one garbage frame with mostly bright pixels and one frame with mostly dark pixels.
Nothing weird so far - just a driver bug right? The weird thing was that when I rebooted the laptop after such a crash, the screen brightness would still slightly, but visibly blink in the same pattern, while the monitor was showing normal boot screen and later the login and desktop. The flashing would get less and less noticeable and kind of ring out by itself after a few minutes. After that the monitor was just working as normal.
I can't think of a good reason why the monitor would keep blinking like that after a reboot. The best explanation I had was that perhaps some kind of adaptive algorithm for image postprocessing in the LCD driver had rolled off into an extreme and needed a while to get back to normal parameters. But it seems unlikely anything like that would have time constants in the range of minutes. The other possibility I thought about was that the blinking after a reboot was just a illusion created by my eyes, but I found that unlikely. I never saw anything similar.
Author here. My intuition says that's probably a faulty backlight panel.
Not sure if you know that, but the liquid crystal that creates the image and colors is very dark by itself, so behind the crystal panel there's another panel filled with bright white LEDs to project the image into your eyes.
Those LEDs can draw a lot of power and get hot, so they need proper passive cooling. In laptops that's usually achieved by gluing the LEDs to the lid and making the whole lid a massive heatsink (if it's a metal lid).
It's possible that your backlight panel was overheating for some reason, or maybe it was just drawing more power than the source (old battery?) could provide. That would explain the continous blinking/ringing until the power/temperature stabilized, but it's really just a guess.
It doesn't really sound like a software error anyway.
I hoped to see a more solid answer because I caused a (I think) similar thing to happen on a friend's MacBook a couple years ago.
I think I was using some utility to force the resolution down from retina levels for some emulated game we wanted to play. Something went wrong and the top ~1/5 of the screen started flickering insanely quickly.
We restarted the laptop and the flickering continued. Then I think we turned it off, left it off for a while, then turned it back on. Still flickering.
In the end we left the laptop on for a couple hours and it slowly became less flickery until it was eventually entirely back to normal.
Super weird. I was so confused and my friend was so nice about it all that I didn't even think to take a video or document any exact stuff we tried aha.
I managed to create the same effect by playing a video which displayed white and black frames in sequence, without a pre-existing monitor defect: https://www.youtube.com/watch?v=-CIzZv5al2E
I’ve done this with WinUAE, the Amiga emulator, by running it in the mode where it simulates interlace flicker, and leaving it up too long. It faded, but boy did the flickering stay around for at least 30 minutes.
Kind of annoying that monitors are identified by UUID and not by the physical port they're connected to. Some layer of the system probably has that information, but some other layer probably deletes it.
(Even more annoying is when the information isn't deleted, but it's ignored. The Nvidia control panel knows which port each monitor is connected to, and could store the monitor arrangement by port number. Also appreciated would be some way of saying "this monitor is going away for just a second, just keep sending a signal even though you know I can't see it". I have a monitor that likes to hard crash every so often and has to be unplugged, this results in seconds of software freaking out when I'd rather not tell the OS or the apps about the loss of a screen and a switch of "primary display" to some other monitor. Usually a reboot is necessary to get everything's state correct again.
Silly.)
But then it would get annoying if you have a laptop with multiple identical ports. You'd have to remember which port you need to plug each monitor into.
Exactly. USB devices do this (seem to identify the device by (port, uuid?)) and it's highly annoying having to rearrange everything so the USB-to-serial adapter can reach the correct USB port so I can keep calling it COM5 and not have to switch everything over to COM1 or COM13 or whatever.
It also causes weirdness like "my scrollwheel scrolls in one direction when plugged into my laptop and the other direction if I plug it into the USB hub in my keyboard."
*on Windows. On macOS USB serial devices use their serial (lol) numbers or models or whatever for /dev/usbserialXXX, definitely regardless of which port you plug it in.
Keys don't need to be defined by a single component - use the monitor reported value, and failover to something like (reported_value ^ connected_port) if there's a collision.
The first issue should be possible to deal with at OS level. Even if all the monitors send same serial number, OS should know in which port they are plugged in. Preferably things shouldn't swap if you swapped ports for your two monitors with properly unique serial numbers. But if the serial numbers are identical, ports seem like reasonable fallback since most people with multimonitor setups don't randomly unplug and plug them too often (except laptops).
No he isn't. He's assuming the wires are plugged into the same physical ports and the USB/Thunderbolt system makes that information available (it does).
No, I’m saying that the same physical ports, on broken hardware, won’t always enumerate to the same physical port. Say port 0 is the one on the left and port 1 is on the right. You’d expect that the computer is able to reliably get that right and be consistent. I’m saying that in the case of broken hardware / bad firmware that it’s not, and port 0 will come up as the right port, with port 1 on the left, with no working, proper way to identify between the two.
I had a very strange monitor bug a few years ago. Dwarf fortress and a weird linux display mode drove my monitor to display a freeze frame of what was going on during the bug at about half opacity with a bit more of a glitchy feel.
It stayed after reboot, mode changes, OS changes, retriggers of the bug etc. etc. etc. to the point where it did not make sense at all how the pseudoimage stayed past power cycles and everything else I could imagine. I briefly, and quite seriously, questioned my sanity trying to figure out what was going on.
Eventually it just went away. Some firmware bug got an image stuck in memory or something, but man it was weird.
Author here, it happens right now with my 5 year old LG 27UD88.
When the bottom part of the monitor renders something darker (say a Sublime Text window), it also displays a ghost image of a lighter previous image (like the browser window with a white page).
It started about a year ago, and every time it happens, the bottom part of the panel is very hot to the touch.
After letting a fan blow over that part to cool down the LEDs behind, the problem went away.
Which leads me to think this is a hardware problem, and the panel is giving up on me.
Fun fact: in some monitors, the EDID flash is writable via the HDMI cable (because the manufacturer forgot to wire the write disable pin to disable this). I know this, because my employer at the time shipped one like that (facepalm).
That means that your laptop can corrupt the EDID.
Windows and MacOS actually ship with a database of 'corrected EDIDs', in which they look up the EDID of your monitor and use instead the one in the DB, because they know the original is broken. TBF, I think this information is provided by the manufacturer.
If you don't need DDC for anything else, the monitor-swapping issue could be fixed by wiring a 4kb I2C flash chip to the DDC pins of the hdmi cable (in place of the monitor, and writing it with a copy of the EDID, with the serial number incremented. A lot of work though. Maybe there is a place for someone to make an HDMI cable with a small embedded microcontroller, for fixing this and other DDC issues.
Like most people here on HN, I have experienced all 3 major OSes (Win, Mac and various Linux distros/DEs).
One of the points where MacOS struggles when compared to other OSes is, in my opinion, multi monitor support.
I'm not sure why, but it seems to me that Apple decided that multi-monitor was not a very important use case and it got de-prioritised (maybe they wanted to push users towards one single, large monitor?), as a result the multi-monitor experience on Mac is not on par with other desktop environments.
I'm not saying that the bugs in the post could not happen on other desktop environments, or that other desktop environments don't have bugs of their own, but in general it seems to me that on several Linux DEs and on Windows, I can get a smoother multi-monitor experience than on MacOS.
I’m a full time macOS user with multiple screens and haven’t used multiple screens on Linux and Windows in ~15 years. But what is missing from macOS? There was a time when I had displays that got switched around but that was fixed. I can set individual display resolutions, scaling, rotation, colour profile, and relative positions.
it would require some time to properly describe the various issues but they are mostly related to 2 thematic areas: window management/snapping in place when in multiple screens and using specific features (e.g. dock, full screen apps) in a multi screen environment. And more in general it's just the presence of little bugs here and there that makes the experience not particularly smooth, for example there are some gestures that you can do when your screens are positioned side by side, but not when your screens are positioned on top of another
I've got a cablematters thunderbolt hub with two DP outputs connected to two LG monitors. They aren't exactly the same but it doesn't matter, as I'm using Xorg, which doesn't use EDID for layouts. It just uses the output names, which are DP-1, and DP-2, and sometimes the hub flips them. The only way I've found to "fix" this is to use Autorandr, which will update the layout based on the EDID, but the output names remain flipped. This is still an unsolved problem, because i3 uses the output name rather than physical position for where to put workspaces.
My other laptop doesn't have an nVidia GPU and runs Sway/Wayland, which doesn't seem to have this issue.
If anyone knows how to solve this I'd be eternally grateful. It's been driving me nuts for a year.
If you switch from i3 to sway you can use the serial number instead of the port to assign outputs. I think these days it's usable with even the proprietary nVidia driver.
Oh interesting, I understand that sway with Nvidia is developing quickly. I did read maybe less than a month ago though that it's still quite glitchy. Will look into it again.
IMO the various standards bodies should require validation against all commands and against a number of certified cables. Shoot, an automated test suite could absolutely identify all these issues. You should not be able to display HDMI, DisplayPort, or HDR validation unless your monitor passes these tests. I give them a pass when it is an OS specific bug, but most of the time it is not. My G9, for instance, doesn't sleep AT ALL even though Windows puts the monitor to sleep. Same story with Linux. Samsung just flat out borked sleep mode. FWIW I have an EVGA 3090 on the other end.
I have a Samsung G9 and it has many of these bugs...and I haven't even tried macOS on it.
I found Lunar very helpful in a South facing apartment with floor to ceiling windows. Without Lunar I had to spend a minute adjusting each monitor, multiple times a day. It solved a problem I never experienced in a home with normal windows.
I got my first Mac + monitor setup in an apartment with the desk on a closed balcony. It was driving me crazy to press the fiddly LG joystick to get to the brightness menu all day long, so I can follow the ever changing ambient brightness.
It's also why Lunar v1.0 only had sunrise/sunset based automatic brightness, not even hotkeys for adjusting the brightness manually.
I used to have a ton of issues with my MacBook Pro and thunderbolt monitor. These issues persisted through different MacBooks and monitors (we used the monitors at work and it was a work machine so I had a few).
All of these issues finally went away after getting an M1 machine. Maybe a coincidence but fewer monitor connection bugs was one of the noticeable changes for me.
Based on the article it might also be because I switched to the apple pro display? Though I can’t remember what happened first.
Also off-topic, but this blog has beautiful style and typography.
And yes, it's very likely that most of your problems went away because you're using the Pro Display, as it has a much faster CPU than most monitor controllers on the market.
Apple displays also support a proprietary USB protocol through which they can communicate with the Mac faster than through the DDC protocol which is still based on two-wire slowpoke I²C.
That Apple Native protocol is also supported by Lunar for silky smooth brightness transitions, which is just not possible on DDC, unless the monitor has some kind of built-in fader.
I found that after I updated the firmware of the monitors, they worked almost perfectly. And to make them actually work perfectly, I connect them on different sides on the MacBook Pro (intel version still). Took way too long to figure that out.
A few years ago I had a 10+ year old LCD start to show pink horizontal lines and it partially blended and distorted 30% of the monitor on the left side.
The interesting part was you could see a decent amount of the original screen's contents even if you had a different screen being shown such as being behind a lock screen. So imagine a scenario where you had your monitor on with something sensitive open, you turn on your lock screen and go AFK. You could come back 15 minutes later and still see a third of whatever apps you had open at like 50% opacity and it blended through with the pink lines and login screen. It was like an acute burn-in effect.
Oh nice. Yeah it sounds very similar. I never did a touch test to see if it was hotter but heat makes sense. The pink lines and distortions were always present once the problem started but eventually the previous image would fade away. I remember trying everything with no change (different computer, drivers, cables, adapter types, etc.) and also chalked it up to a hardware problem.
There are a bunch of Fujitsu screens out there from maybe 6+ years ago that have another peculiar bug: the osd breaks after a few years. It manifests in such a way that the language select (that you usually only see the very first time you turn on the screen) flashes for a split-second and then... Nothing. You cannot change any setting of the screen. Not even brightness.
The workaround is to issue a factory reset via DDC. Then you can properly select the language again and everything works..... Until the first time the screen goes to standby or gets turned off. Rinse and repeat. It's better than nothing I guess. You can easily find these models on ebay et al, usually people state that "the menu button is broken" or similar.
A bit off topic: I'm facing an issue where a monitor works only when getting power (220v 60hz) from an outlet but not from an external power generator: ecoflow river pro (220v 60hz) as well.
It's the only appliance that doesn't work. It turns on normally but stays black (I use it in mirror mode).
Every hour or so it may show the correct content for a glance then it'll turn black.
I suspect the power supply source is not the real reason, maybe there's something causing interference with the cable?
I'm waiting to have a free weekend to check it out.
My guess would be the power supply is putting out something closer to a square wave than a sine wave and the monitor power supply is unable to turn that into DC.
Is there another appliance that I can test to see if that's the issue? I don't have an oscilloscope.
Edit: I just tested powering it from a UPS: It's flickering more now and when it show the correct content it stays for a second more then when powering from the ecoflow.
It sounds very likely that this might be electromagnetic interference. The good part is that it’s easy to troubleshoot, just move the generator (or the monitor, whichever is lighter) far away, like in another room or outside.
You can also try a different, thicker cable, if you have one handy. The thicker cables are usually better shielded by having a sheath of tiny wires to catch that interference and conduct it to ground.
I just tested moving the ecoflow to another room (both door closed ~5m between the ecloflow and the monitor) and used an extension cable to power the monitor.
The issue is still happening.
Unfortunately I don't have a different HDMI cable at hand now. I'll test another cable as soon as I get my hands on one.
As someone who is using display-switch[0] to imitate a hardware KVM switch in software I can say I’ve seen many of these issues in trying to debug the random issues that using ddc creates.
Ddc is to http what your county clerk’s website is to (current) healthcare.gov essentially. There’s no standardization at all, it’s maintained by 1000 different people who don’t communicate and don’t care how anyone else is doing it because only like 1/10000 people have heard of it and 1/100000 uses it.
To be fair...under the same conditions windows and even Linux a la Nvidia gracefully handles monitor assignment for matching serials so I think it's a bit disingenuous to say this is all on the monitor manufacturer...though I agree ultimately they are the primary party at fault.
Source: have this exact scenario and on windows/Linux Nvidia drivers it works and on Mac it flips everytime I come back from sleep. Same brand batch and serial, cables, ports, etc.
And I have an m1 pro with a simple HDMI to usbc and an HDMI direct so no hub/bus assignment funny stuff either it's directly plugged into dedicated ports.
Was skimming through comments sure that someone would confirm this exact thing.
In addition to this I have a USB-C hub that includes 2 HDMI inputs, my M1 Max Mac Pro doesn't recognize two monitors connected to it but my Windows laptop does.
One thing I learnt recently is that Windows 10 or below is incapable of remembering window positions. You need to buy third-party software. Microsoft finally fixed this with Windows 11.
I'm not making this up, its well documented on many internet forums, including Microsoft's own.
Incidentally, made me happy to be a Mac user. Since Apple never had that problem. Infact OS X is magical in how it deals seamlessly with unplugging/plugging external monitors (and no, I don't use an Apple external monitor).
It's not so simple. I've had two (different type) Dell 27" monitors on Win10 for years and never had a problem with losing window positions, until I accepted an 'upgraded' Nvidia driver (27.x to 30.x) a few weeks ago. I rolled back the driver version and it's all good again.
Another +1 from a happy user! Thank you for developing it. I use several times a day, whenever I'm entering/leaving video calls, or depending if the site/app has dark mode. It's incredibly helpful and reliable!
Oh man. I used to have an Asus monitor that would crash if you connected a sleeping MacBook, then woke up the MacBook. You had to unplug the monitors power for a few seconds to reboot it.
My current LG 34BK95U had an issue where MacOS would sometimes refuse to send the correct resolution or even aspect ratio. The workaround was to force it to DP1.2 instead of 1.4 (over thunderbolt), but then my Windows machine couldn't send the full resolution/refresh rate over DisplayPort. LG eventually put out a firmware update to fix that.
On the other hand, they still haven't fixed the false claim on their website that it supports a 75hz refresh rate. It's identical hardware to their 34WK95U, including the 60hz maximum refresh rate.
A previous LG monitor I had falsely claimed 60 USB PD laptop charging on their website. The hardware only supported 7.5w. It was the same scenario, where the consumer model has correct specs, and the business model has identical hardware and falsely inflated specs.
I think every single 4k/5k monitor I've ever owned, from LG, Dell, etc. have had useless HDMI ports that were unable to drive the monitor at the correct resolution and refresh rate. You had to settle for either 30hz or a blurry low-rez picture.
So many monitors run on similar controllers internally - it would be absolutely wonderful if one or more of those had open source firmware so these bugs could be fixed
Would also be wonderful if they could use a halfway modern CPU so the monitor didn't take 30 seconds to wake up. My CRG9 takes long enough that my macbook will fall asleep again from the password prompt as I'm waiting for the monitor to light up, if I don't keep hitting keys.
Yeah I tried disabling the eco saving mode and that definitely helps a bit. I wonder if perhaps turning off the automatic input detection would help further. I can switch inputs manually the occasional time I need to do so.
That thing looks fancy! Perhaps make sure there isn't a "light sleep" or similar option in its OSD that allows it to blank the screen without fully sleeping.
On my monitor (~5ish year old Dell) I have the "Deep Sleep" option disabled and it suits me very well like this.
That's a good catch. There is an 'eco saving' setting that I found after you mentioned it, and it does seem to help the monitor wake up faster. Still not going to win any speed contests, but waking up before the computer goes back to sleep is a win!
It's a bug with most modern LCDs. Ever since HDMI days they started taking ages to turn on or change modes. I have LCDs from 1997 that turn on and change modes in about 100ms, as opposed to the new 3s-10s. I suspect something extremely stupid, like maybe HDCP crap takes a long time to do its thing (regardless of whether its used) and the process gets blocked on that.
Wow... I started at my current job about a year ago and we use Mac Minis as the main workstation for the users. Well as the users started doing more work we got them dual monitors and that is when I started noticing the first problem described. Everyday the same few people would come to me saying that their display settings would swap the main monitor, and sometimes it happened when they went to lunch.
I searched online and couldn't really find a sure-fire resolution. I did however, find that if I logged into the administrator account and swapped the monitors, then went into the Energy Saver settings and prevented the Mac from automatically sleeping when the display is off then it keeps the problem away long enough. I will usually have to repeat that process upon an update but I am just glad I found out why this was actually happening.
I wonder if anyone has worked on open source firmware for monitors, so that we can fix some of these bugs. I also wonder how many security vulnerabilities are in DDC parsing firmware. MonitorDarkly proved that there are definitely some:
It matters what your security settings for URL display are. There are attacks related to the URL bar (of course), so you can set Firefox to only display the raw urlencoded URL, or display emojis/non-ASCII characters visually. I guess there is theoretically ideograph attack mitigations in the second mode, but I don't trust it enough for the small benefit as an English language user.
A bit of warning if you try to get a firmware update from Dell to your monitor. Dell's official stance is "we don't sell monitors outside our official channel". If you bought a Dell monitor from Amazon, Dell may NOT accept it for a firmware upgrade.
I should probably just google this but how do I see the UUID numbers for the monitors? I have that swapping problem at work. If it's as simple as swapping one of my monitors with a co-worker that would be great. But rather than just swapping and praying it would be great to be able to verify the UUIDs, before I swap. One to make sure I get a monitor with a different UUID and another to make sure I'm not giving a matching UUID to whoever I swap with
Interestingly ioreg reports the same UUID for both monitors but Apple Menu->About Mac->System Report->Graphics/Displays on Intel Mac shows different serial numbers (not UUID) for both monitors. So,.... this sounmds like a bug in MacOS, not the monitors. Whatever they are using for UUID they should be taking into account the serial numbers reported by System Report.
Strange though, the M1 Mac shows no serial numbers. Both Macs have the swap problem.
Maybe you should add an update to your article. This is clearly an Apple bug, not a monitor manufacture bug. At least in my case.
The Alphanumeric Serial Number is not a standard EDID field, but a custom extension of it.
MacOS definitely has a way to distinguish between monitors here, and in other cases too, but they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID.
Only a small percentage of the monitors implement those EDID extensions so it's hard to rely on them. At best you can use them as a fallback, but that needs field data which they might not have had when the M1 firmware was written.
The standard serial number field is 0 as you can see, so it's still a monitor bug. Incrementing an integer and compiling it into the firmware is not that hard.
> the Alphanumeric Serial Number is not a standard EDID field,
Maybe I mis-understood your article. I thought it was up to the computer to decide what to add/sum/checksum into an UUID and therefore the fact that Mac is not using all the data is arguably a poor choice by Apple.
> But they would still have to go through every edge case and try to make sure they don't break previous working setups when including more data for the UUID.
They break those things all the time and people have to re-setup how their monitors are arranged. Doing yet another time doesn't seem like a big deal. If they really wanted to solve that problem they'd just compute a UUID the old and new ways and then remap the old to the new way. The only people this wouldn't work for is the people who they're fixing the bug for and those people already experience the bug.
It is up to the OS, you understood correctly. But the EDID spec tells that you can only rely on the standard EDID fields to be present. Someone implementing the spec would be right to do what Apple engineers did in their UUID logic.
All the rest are workarounds that they need to add on a case by case basis when new data appears like 10% of the monitors since 2017 only have an alphanumeric serial number or like some very popular Dell models need a 1.5 second warmup time before reading the EDID to get a complete structure.
You might say, why don’t they just stick every available data in the UUID and call it a day?. The issue is that outside the standard EDID fields, you have no guarantee that the extension data will be persistent. If even a byte of that data changes when adjusting monitor settings, or when reconnecting the monitor, then you’ll break the persistent storage even more for setups where it worked before.
I’m trying to say that it’s not Apple’s fault here. If monitor vendors would follow the incredibly simple standard for those fields, we wouldn’t have any “bug” to talk about right now.
But of course, people will only care if their setup works or not, assigning blame to the right party doesn’t change a thing. So Apple must now try to fix those edge cases, because monitors won’t go back and reflash correct EDIDs in their EEPROMs.
Simply incrementing the serial number or the week of manufacture bit will be enough.
But you also have to be lucky to have a monitor that hasn’t already locked the write pin of the EEPROM.
On macOS it’s a lot harder to write the EDID, especially on Apple Silicon. I’m not sure why, but the WriteI2C method doesn’t always work so you might end up breaking the monitor with an incomplete write.
I'm going to suggest again that Apple still has stuff to do here. For example, on another setup I have 2 very different monitors, 38 inch wide 3840x1600 LG and a BenQ 32" 3840x2160. They don't have the swap problem but MacOS just screwed up and even though I have the BenQ set to Scaled at 2560x1440, MacOS just put it at 3840x2160, and, when I went to go fix it, System Prefs showed it set to 2560x1440. To fix it I had to pick another resolution and then set it back.
There's clearly work to be done on Apple's part here.
Another common problem I have is switching from no external monitor to external monitors. Usually the process is I'm on my laptop on battery. Close the lid. Come home. With lid closed plug in monitors one via USB-C, the other via a Thunderbolt dock, tap an external keyboard to wake it up.
Quite often (once a week?), MacOS never switches on. Often I open the laptop and MacOS flickers all 3 monitors and never recovers (have given it several minutes). Unplug the monitors and there's an 80% change the laptop monitor will come on. Re-plugin the external monitors, wait for them to come on, then close the laptop. The other 20% of the time the Mac never comes on and I have to hold the power button to hard rebooth. This happens on both a 2019 Intel/AMD MBP and an M1 Max MBP. This situation also happens with the 2 identical monitors but the swap probably happens multiple times a day where as the "it can't get itself started" problem happens once a week.
macOS definitely has its own bugs, I’m not siding with Apple because I like them or anything like that.
I waste countless hours each week just responding to emails and explaining to people how what’s happening with their colors and brightness is caused by buggy Gamma implementation in a macOS framework, or how BlackOut (https://lunar.fyi/#blackout) is so unstable sometimes because of unreliable mirroring APIs, and of course I bump into the resolution and wake/reconnection problems you mentioned as well.
Especially on Apple Silicon where the Display Coprocessor is still in its infancy, they still have a lot of work to do.
It would be good if the article mentioned the models of buggy monitors, in particular those that don't present unique UUIDs, so that we know which ones to avoid buying.
I'm about to choose a new monitor, they all seem much the same, but being reliable against this sort of problem would be a deal-winner for me.
> After standby or restart, the monitors get swapped by the OS, so moving the cursor to the left monitor will actually appear on the right monitor, and vice-versa.
This happens to me all the time, and it's a small; annoyance that's slowly crept up to a frustration now. It also happens that one screen entirely won't 'receive signal' after sleep until I turn unplug/replug the lightning cable
Yes, man-in-the-middle for EDID was one of the solutions I thought about. But that can be a security issue [0] and I didn't want to endorse something I don't trust fully.
Maybe users wouldn’t send this in for a brightness control app but:
Do you ever get bugs where sometimes after waking from sleep the macOS only offers a few limited resolutions? I have one cheap display and with one of my MacBooks there’s a 25% chance it switches to 1080p after sleep.
I did get this bug reported thinking it was caused by Lunar.
In the end it turned out to be either a too long cable, or simply a cable that didn’t support the full bandwidth needed when the heat over the wires was increasing resistance.
On my Acer XB271HU, using SoftMCCS either doesn't work, or causes the monitor to go into factory test mode (flashes full screen R, G, B instead of sleeping). In factory test mode, different commands work or don't work.
Your second monitor has a microphone jack (without anything connected) which it autoselects for audio input? I think the usual logic is to use the most recently added microphone
That's moreso because Apple has a Strongly Held Belief that UIs should never render at fractional scale factors. If it needs to be 150%, it will render a larger virtual desktop at 200% and then downscale.
Contrary to Apple, monitor manufacturers have a Strongly Held Belief that monitors should all be one marketable resolution (e.g. 4K) and shape (16:9 widescreen or wider) and users just pick a size. Bigger monitors shouldn't have more pixels in them.
The Apple philosophy says that 4K 27" monitors are fundamentally broken hardware that the OS needs to fix at the cost of some display clarity. The manufacturer philosophy says that DisplayPort can't run 5K off a single cable[0] and that nobody wants letterboxing when watching a movie on their new laptop. Apple designs the monitor around what the OS and user need while display manufacturers design around whatever they can buy and repackage.
Of course macOS has fuzzy fonts even at 1x, but that's not a display problem. That's a different Strongly Held Belief. Microsoft deliberately bends fonts to fit the pixel grid (they call this ClearType) while Apple uses antialiasing to remain faithful to the glyph shapes as they were originally designed.
[0] Or at least this was true as of the release of the iMac 5K almost a decade ago. This is not true anymore but no manufacturer is touching 5K anyway.
This is typical but poor gymnastics which grants benefit of the doubt to brand loyalty. Manufacturers hold no such belief, they are beholden to standards to cater to a wide variety of configurations and setups. Implying it's not made for users is poor form, and simply false.
If this were true then companies other than Apple would offer monitors that actually do cater to non-broken configurations but they don’t. The parent post does a great job explaining the technical trade-offs and economy of scale optimisations that manufacturers have decided to make, whereas you have only an ad-hominem attack to offer.
I'd attribute this to the fact that the way technology is organised follows how the groups of people who develop it are organised. The Ghost Of The New Machine thing; "if you put database folks and kernel folks into the same office, you'll end up with parts of database in the kernel".
Problem is that fractional scale factors are broken, unless your GUI is completely vector-based. While OS can render texts and vector graphics on fractional scales, bitmaps has to be scaled, which makes them blurry.
Bitmap scaling doesn't become blurry if you have enough resolution (e.g. going from 2x to 1.5x is fine). Vector scaling breaks because layout calculations don't take the pixel grid into account.
The most egregious example of this is CSS floats, where browsers have to do all sorts of hacks to ensure that percentages still add up to 100% after rounding. Otherwise fractional zoom factors cause layouts to have pixel gaps or overflow onto other pages. Fonts get around this with hinting but there's no way to hint a CSS layout.
that install script is not correct. $BIN is never set to anything so it would thankfully crash at the mkdir -p instead of installing to the root directory but either way it wouldn't work
I feel obligated to point out that the comment you replied to never said anything about brightness control being built into any OS. They only found it humorous that someone would pay extra for it (presumably because it's free). Then... you went ahead and supported their argument by pointing out that it is indeed free; while also chastising them.
I guess my point is that your reply didn't really contribute anything to the conversation other than hurling an insult at the commenter for their past comments. Maybe they really just wanted to make a joke? On some level it would be silly to pay for something that's free, right?
Given that you're the original author, could it be that you may have replied as a defense mechanism? At least to some degree? If so, is that proper?
Honestly, I don't have a "dog in this fight". I just thought it was an interesting situation.
Lol, yeah... back in the day a snide remark like that would have ruffled my feathers too.
Lots of people told me "you get more flies with honey" but it can take a while for that to become a reflex. I'll probably never really get to the point where I can wear the hat of a highly polished, glib salesperson. But we perservere :-)
Retail sales is a tough game! What more is there to say?
Are you sure it's not some old USENET/e-mail/early web troll/joke thing? It has that sort of quality. Bending your TV's aperture grill by focusing too hard on a small part of your screen, using some sort of supposed psycokinetic effect sounds more like the product of the 1990s Internet than the product of a 2020s AI/text prompt system.
Apparently it's a known issue at Dell: [3]
>Surprisingly, we have also seen this issue connected to gas lift office chairs. When people stand or sit on gas lift chairs, they can generate an EMI spike which is picked up on the video cables, causing a loss of sync. If you have users complaining about displays randomly flickering it could actually be connected to people sitting on gas lift chairs. Again swapping video cables, especially for ones with magnetic ferrite ring on the cable, can eliminate this problem. There is even a white paper about this issue.
[1] https://www.youtube.com/watch?v=voW5kEI7JKE
[2] https://www.youtube.com/watch?v=D6pY4t0k1hk
[3] https://support.displaylink.com/knowledgebase/articles/73861...