Stable monitor assignment when there's multiple copies of the same monitor

[ELLIOTTCABLE]

I'm trying to use workspace-to-monitor-force-assignment to keep certain windows on my vertical display; but it keeps getting shuffled onto another display during reboot. )=

[workspace-to-monitor-force-assignment]
0 = 'main'
7 = 'Pro Display XDR (1)'
U = 'U13NA'
...

At the moment, whatever 'name' Aerospace gets for attached monitors seems to be something assigned by the system at boot; and that assignment seems to be mutable. (Sometimes, my left monitor is named “Pro Display XDR (1)” and my right is “Pro Display XDR (2)”; other times they're shuffled in another way.)

Would it be possible to match on another property of the monitor that is more immutable? I see an OS UID (although for all I know that'd also be unstable) as well as the display's serial number as potential options.

---

(To be clear, this is an issue without workspace-to-monitor-force-assignment configured at all; I'm trying to use workspace-to-monitor-force-assignment to work around it. The best improvement would be Aerospace transparently handling monitor-location-and-identity more in a more stable fashion; but I don't see how that's possible without user-input.)

Additional situations where this presents (some more annoying than others), as search-result keywords:

• Disconnecting/reconnecting a display. This is the worst one for me; one of my monitors fully turns itself off every time the input appears/disappears, which plays poorly with macOS display-sleep and Aerospace - it means all of my windows get shuffled every time my computer locks!

• Rearranging in the macOS “Displays” settings. Every single one-pixel adjustment of the displays seems to result in the name-assignment by macOS getting reshuffled; it's bad enough that I have to quit Aerospace before messing with the display-arrangement; otherwise all of my windows are randomly shuffling between the displays (including the display-settings window I'm trying to interact with!) every three-to-five-seconds. Oof! (This one isn't so bad during everyday use, though; hopefully one shouldn't have to rearrange their display-settings too often.)

• Rotating a display that supports automatic OS rotation, like Apple's XDR. This might suck for users who rotate their displays often; but that's not me right now. (=

[nikitabobko]

Would it be possible to match on another property of the monitor that is more immutable? I see an OS UID (although for all I know that'd also be unstable) as well as the display's serial number as potential options.

If you find how to retrieve it in Swift, I'm ok to add matching by uid like this:

[workspace-to-monitor-force-assignment]
  1 = { monitor-uid = 178131 }

AeroSpace uses https://developer.apple.com/documentation/appkit/nsscreen/. I don't see a way to get UID from NSScreen.

But please make sure that they are stable; otherwise, it's all for nothing.

---

Alternatively, I can suggest the following:

[workspace-to-monitor-force-assignment]
  1 = { monitor-pattern = 'pro display xdr', first-in-sorted-by = 'monitor-min-x' }
  2 = { monitor-pattern = 'pro display xdr', last-in-sorted-by = 'monitor-min-x' }

• Workspace 1 will be assigned to leftmost monitor that matches 'pro display xdr'
• Workspace 2 will be assigned to rightmost monitor that matches 'pro display xdr'

Along with first-in-sorted-by, others could be added: second-in-sorted-by, third-in-sorted-by, fourth-in-sorted-by, ... (up to some reasonable number)

Along with monitor-min-x, others could be added: monitor-max-x, monitor-min-y, monitor-max-y

[ELLIOTTCABLE]

Hmmmmm. I'm torn. That feels like a relatively complex feature, maintenance-weight wise. I could see some flexibility with it, which is cool; bit it immediately has me asking 'what's the user stories this satisfies.'

I think flexibility in display management can really be broken down to two situations that will actually happen “during flow” - any other arbitrary changes or rearrangements don't really need to be optimized in software, because they'll happen extremely rarely:

• Removal/addition of a fixed display from the set (“KVM switching” of a display to another machine and then back; or sitting down at work with your laptop and plugging it into your dock)
• Rotation of a display in its existing position in the ordering

I could be biased by my own experiences, idk; but it feels like a less-powerful, simpler, and more-specific UX could account for both of those?

---

As for the UID, looks like CGDirectDisplayID is available from NSScreen; that's not guaranteed to be stable, but it's supposedly “[persistent] across processes and typically remains constant until the machine is restarted.” Maybe I can add a patch allowing that to be listed as an integer in workspace-to-monitor-force-assignment; lemme take a quick stab, I haven't done any Cocoa since waaaay back in the ObjC days, though.

[ELLIOTTCABLE]

While I hack on this (#1166), it's worth noting that I came across this aside in the displayplacer README:

ScreenIds Switching:

Unfortunately, macOS sometimes changes the persistent screenIds when there are race conditions from external screens waking up in non-determinisic order. If none of the screenId options below work for your setup, please search around in the GitHub Issues for conversation regarding this. Many people have written shell scripts to work around this issue. Recommended discussions are one, two, three, four, five, six.

You can mix and match screenId types across your setup.

• Persistent screenIds usually stay the same. They are recommended for most use cases.
• Contextual screenIds change when switching GPUs or when cables switch ports. If you notice persistent screenIds switching around, try using the contextual screenIds.
• Serial screenIds are tied to your display hardware. If the serial screenIds are unique for all of your monitors, use these.

I'm still reading code and building tests and whatnot; but I'm potentially leaning slightly towards “replicate displayplacer's three forms precisely” as an approach. Allowing exactly the same formats that displayplacer takes as command-line-arguments inside workspace-to-monitor-force-assignment; what do you think?

(displayplacer uses private APIs, to be sure; but the command-line argument format is just information we can replicate. That, and it's a popular tool that very nicely complements AeroSpace, even if it's got a different philosophy of development.)

Something like:

[workspace-to-monitor-force-assignment]
1 = { persistent-id = 'EA2FFBBA-4D91-C91A-E605-8BF03F9084E0' }
2 = { contextual-id = '69960577' } # CGDirectDisplayID
3 = { serial-id = 's202705666' } # Display serial-number prepended by `s`

One minor qualm: I'd be tempted to match the naming precisely to what displayplacer calls each of those forms of ID (for lack of anybody else thoroughly documenting this leaky-abstraction, and to help users write consistent scripts); but I dislike their name for the UUID - I suspect the named it before discovering from users how, well, not persistent each and every one of these options turns out to be, in some weird user-situation or other. So, I'm torn between calling that simply display-uuid vs. calling it persistent-id. Thoughts?

[nikitabobko]

That feels like a relatively complex feature, maintenance-weight wise

Not sure, first-in-sorted-by = 'monitor-id' is already implicitly always applied, but the docs fail to mention that. Exposing first-in-sorted-by to users will help to document the behavior and make it more clear

---

I didn't know about the existence of displayplacer, and I didn't yet have time to take a look at the links your mention, but given that you only mention problems, I don't have a good feeling about it.

Previously, I didn't have a good experience with monitors identity #336 (the thread explains why AeroSpace has to introduce its custom numbering via monitor-id) so I'm skeptical if it's possible at all. I have a feeling that the matching against relative positions (like order along the x or y axis) will work better.

But again, I've not yet taken a look at the links you mention, maybe I miss something and monitors identity/persistence is a very simple task

[ELLIOTTCABLE]

It is definitely not a simple task (in the UX design sense, anyway - the code is fairly simple, although I am bad at systems programming and spent two days banging my head against a segfault before I ran out of time.) And yeah, your summary is pretty much correct: any available apporach appears to be a fairly user-unfriendly leaky abstraction.

I still want to finish my implementation; I think it's the “best possible option” for a very, very important feature. I don't know when I'll have time, though; it's definitely defeated me thus far.

[mcarlin]

@nikitabobko does what you described above work with latest aerospace? or would that be an enhancement?

[workspace-to-monitor-force-assignment]
  1 = { monitor-pattern = 'pro display xdr', first-in-sorted-by = 'monitor-min-x' }
  2 = { monitor-pattern = 'pro display xdr', last-in-sorted-by = 'monitor-min-x' }

• Workspace 1 will be assigned to leftmost monitor that matches 'pro display xdr'
• Workspace 2 will be assigned to rightmost monitor that matches 'pro display xdr'

[dasvh]

I did try this since I have the same issue at work where I have multi-monitor setup with identical monitors that show up with same name:

aerospace list-monitors
1 | Built-in Retina Display
2 | S27H85x (1)
3 | S27H85x (2)

Here is what I tried:

[workspace-to-monitor-force-assignment]
1 = "Built-in Retina Display"
2 = "Built-in Retina Display"
# 3 = "S27H85x (1)"
# 4 = "S27H85x (1)"
# 5 = "S27H85x (2)"
# 6 = "S27H85x (2)"
3 = { monitor-pattern = 'S27H85x', first-in-sorted-by = 'monitor-min-x' }
4 = { monitor-pattern = 'S27H85x', first-in-sorted-by = 'monitor-min-x' }
5 = { monitor-pattern = 'S27H85x', last-in-sorted-by = 'monitor-min-x' }
6 = { monitor-pattern = 'S27H85x', last-in-sorted-by = 'monitor-min-x' }

But I got this error:

aerospace reload-config
Failed to parse /Users/username/.aerospace.toml

workspace-to-monitor-force-assignment.3: Expected types are 'string' or 'integer'. But actual type is 'table'
workspace-to-monitor-force-assignment.4: Expected types are 'string' or 'integer'. But actual type is 'table'
workspace-to-monitor-force-assignment.5: Expected types are 'string' or 'integer'. But actual type is 'table'
workspace-to-monitor-force-assignment.6: Expected types are 'string' or 'integer'. But actual type is 'table'

I suspect it is not possible with the most recent version of aerospace (0.18.5-Beta).

[dasvh]

@nikitabobko Are there any plans to implement this - handling multiple monitors of the same make?

[dasvh]

@nikitabobko any update this?

[abitops]

Hello there, I've been trying to set up two, the same dell monitors next to native display without using any other apps. Here's what worked for me.
List of monitors:

1 | Built-in Retina Display
2 | DELL P2421DC (2)
3 | DELL P2421DC (1)

I've tried using monitor-pattern but run into the same issue as above, after that, I've tried to set up number of the monitor according to the list-monitors order and that worked (here's part of my config):

[workspace-to-monitor-force-assignment]    
    W = '1'
    T = '2'
    B = '3'
    R = '2'
    Q = '2'
    F = '3' 

The only thing that botters me is a small menu bar on an inactive window, but I think I can get used to it.