BetterDisplay and MacOS indexing different

[chikko80]

Hey,
in my current setup, I try to run an LG 5k Display directly connected to a MacBook M1 Pro, together with 2x 4k LG Displays with DisplayLink Dock D6000.
As long as I set up everything from the beginning it runs great, but after the mac wakes up from sleep there is a big issue. It seems like the Dummy Displays connect to the wrong physical Display. One of my Displays is vertical like in the picture below, and after wake the horizontal dummy display is connected to the vertical display, resulting in a complete mess.

I noticed that the index of the monitors is different.
The "Lg Ultrafine (1)" in the macOS settings is actually the "LG Ultrafine (2)" and vice versa in the BetterDisplay Settings.
So that could be the issue.
I am a programmer myself but don't know anything about monitor software, but if you need further information for debugging or anything, I think I can provide that easily.

EDIT:
I connected one Ultrafine with HDMI and the other one with Displayport (before both with Displayport).
Indexing seems right now! But the problem is still there. I'll add a few photos of what's happening.

The same is happening if I remove the rotation, the image on the two screens is mirrored (after wakeup from sleep), and they are not extended anymore - in the setting dummy1s mirror target is still ultrafine 1 and dummy2s ultrafine 2 - but in reality its like dummy1 mirrored to ultrafine1 to ultrafine2

If I disconnect and reconnect the dummies the problem still remains. Only if i remove the dummies and create new ones the problem goes away (until mac goes to sleep)

I've already tried the alternative identify method, but it's also not working..
If disable BetterDisplay, the Monitors are correctly tracked by the OS after reboot.

I discovered that the following menu function is also not working properly: Create new dummy -> Create and configure for

The dummy is getting created, but the program does not mirror it to the target monitor

[waydabber]

Well, handling identical displays is always super problematic, even for macOS as there is no reliable way to tell them apart. Things are up to dumb luck and depends on the order how they are enumerated after wake. Things are even more problematic when DisplayLink is involved as with this even unique identifiers that otherwise might be stable at least until reboot or reconnect do change around from time to time.

You can click on the display name under Settings/Displays and see if there is any natural identifier that differs and might help telling the displays apart reliably - if there is, I can alter the app to put more emphasis on it.

[chikko80]

What kind of identifier are you using at the moment?

[waydabber]

Normally the UUID as this is the system generated identifier that macOS itself uses to tell displays apart. With the alternative identification method enabled the serial number, vendor id and model id.

[chikko80]

Okay, I'll see if I find anything we could use.
From your experience:
Do you think it would help to use a thunderbolt hub (connected to the MacBook) and connect 2x DisplayLink adapters to the hub?
So every monitor would have its own DisplayLink adapter, and could theoretically use more bandwidth.
As far as I know, DisplayLink always uses compression (to get 4k60hz through USB 3.0).
I also noticed, that if you use 2x monitors on the same DisplayLink hub, the quality decreases significantly, because the monitors have to share the bandwidth which is already compressed.
Just curious what you think about that, just in terms of betterdisplay - would the split on two adapters maybe help for identifying?

[waydabber]

No, it would not help in identification I am afraid as the display identifiers would remain the same and the both the UUIDs and the alternative identifications are based on these. Furthermore in case of virtual displays the virtual display itself and the physical connection it uses is entirely disconnected, it is rather difficult to establish a clear link between the two. I think the solution would be some kind of option in the DisplayLink driver to somehow "tag" a display by overriding its serial number based on connection which then could be read by both the OS and various apps.

[chikko80]

I've used the monitors for a few days now.
macOS tracks the monitors without any problem and the UUID is constant.
Even with DisplayLink, there is no issue in tracking. Every time I wake up, my layout is correct.

When I use BetterDisplay on top, everything works fine, as long as I use just one dummy display.
With one dummy I can go to sleep and wake up and everything works -> the dummy always connects to the associated display.

But as soon as I use two dummies, the exact same thing described above is happening.
And it's always the exact same behavior.
I don't know why the bug is happening if it's triggered by the OS or BetterDisplay, but would it be just a real random bug, then I would expect more different outcomes.
A few weeks ago, tested a pair of HP Monitors.
It was horrible because the Monitors didn't provide the necessary information to macOS to distinguish between them.
As a result, every time I woke the mac up from sleep, I had a random layout, the left side was on the right and vice versa + sometimes I had completely different resolutions.
But over here the outcome is the same every time, the left vertical monitor is attached to the right horizontal monitor (or its dummy).

So there is some issue with the reattachment if there is more than one dummy.

Do you have any idea?
Maybe it gets triggered by the OS, idk to be honest, but in fact i don't have any issues without BetterDisplay (besides the bad resolutions of course:) - that's why i would like to use this masterpiece of software)

It's so frustrating because better dummy if working perfectly with one dummy and even with two dummies, but it doesn't matter what i do, as soon as i use the two dummies and go to sleep, i get the wrong attachment bug and its everytime the same behaviour

[waydabber]

Hi there,

dummy-display association affects only whether a dummy is connected or not (depending on the presence of the display). If I understand correctly, then association works, as both dummies are connected for both displays. The issue is that the layout just gets messed up. This is controlled by macOS, not BetterDisplay.

I think you should try resetting the windowserver display configuration:

1. Disable display association and close the app
2. Navigate to your computer's /Library/Preferences folder in Finder and remove the file com.apple.windowserver.displays.plist
3. Navigate to your user's ~/Library/Preferences/ByHost folder in Finder and remove every file that starts with com.apple.windowserver
4. Restart your Mac

After this, without launching the apps, you should

1. Configure the displays in the right arrangement
2. Connect dummy 1 and mirror it and configure the displays in the right arrangement
3. Disconnect dummy 1
4. Connect dummy 2 and mirror it and configure the displays in the right arrangement
5. Connect dummy 1 as well, configure mirrors and configure the displays in the right arrangement

This should let macOS store the display configuration for all possible scenarios that might arise. After this, you can enable association.

If things do not work after this, then macOS simply cannot handle a 4 display 2 mirror layout consistently. You might want to try to disable various sleep workaround settings in the app so dummies are not disconnected on sleep or wake, that should preserve the mirrors.

[chikko80]

@waydabber
thanks for your detailed answer!
I tried every step, but it still just doesn't work after sleep. Even with the reset.

But I discovered something very interesting:
If I set up everything correctly (arrangement, displays on the right sides etc.) and then select (in BetterDisplay)
Tools -> Manage Dummies -> Reconnect Connected Dummies
the mirrors get messed up the same way after sleep.

But if I select Tools -> Manage Dummies -> Disconnect All Dummies
and after that Tools -> Manage Dummies -> Connect All Dummies

then everything is in the right arrangement and works as expected!

Can we work with that, maybe create a workaround out of this?
I don't know how your reconnect - connect / disconnect is implemented, but if there is a major difference, we could maybe create some kind of workaround to use connect / disconnect instead of reconnect.
It seems like there is any kind of problem with the reconnect function in combination with macOS.
Maybe you have an idea about that.

Looking forward to your answer!

EDIT: I used it for a few hours now and it works reliably, every time I woke up from sleep and it was messed up, I disconnect the dummies via the menu and connect them again. After that everything is restored correctly.
I can also just do it on the fly whenever I like and it works every time with disconnect -> connect.

Every time I use the "Reconnect" button, things are getting messed up.
So it would be nice to use the disconnect -> connect automatically if that's possible.

[chikko80]

Okay i think i solved it for my usecase..
I did a reset on the windowserver settings and set up everything correctly.

I definitely had to disable the "Reconnect dummies after wake".
Now it works - even after sleep - as far as I can tell.

I am curious, what exactly does the reconnect function?
Because it seems like there is a major difference between "reconnect" and normal "disconnect / connect".

For me reconnecting is messing everything up.

[waydabber]

The reconnect dummies after wake will iterate through the dummies and disconnect and reconnect them one-by-one. If you disconnect all dummies and then reconnect all dummies, the order is different. This is significant because every combination of connected displays recall a different display layout. The Reconnect dummies after wake is not enabled by default and for most configurations it is not needed/helpful, so it is best to leave it disabled. An other thing that might mess up display layouts is Use mirrored dummy sleep workaround - so if you don't need that for system stability, it is best to turn that off as well.