macOS 12 Monterey - Githubissues

This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.

I will try to keep this updated just like every year.

2021-06-07 Developer Beta 1 (21A5248p)

Dock.app is available at [Dock.app.zip](https://github.com/koekeishiya/yabai/files/6617787/Dock.app.zip).

donaldguy commented 3 years ago

The invisible window problem above [1] [2] has seemingly resolved for me on beta 5 :-)

Idk why, maybe the beta 3 set frontmost entry point I had was off? or maybe something changed in SkyLight.framework?

Anyway, I'll take it.

EDIT: hmmmm. I have apparently managed to re-trigger the problem. As far as I can tell, this was by:

Re-enabling borders (to check whether that made a difference; initially it did not)
Re-triggering the hang-on-quit issue with ordering groups (or movement groups, but one seems more relevant than the other) as above.

EDIT 2: restarting (sudo kill -1ing) the WindowServer seems to have returned me to a state where I can e.g. open new windows in Firefox without them being "invisible"

peppy commented 3 years ago

@donaldguy thanks for your work on this. i've gotten mostly everything working with your branch, but can't seem to focus spaces:

works:

~/Projects
❯ yabai -m window --focus (yabai -m query --windows | jq '.[] | select (.app  == "Safari") | .id');

doesn't work:

~/Projects
❯ yabai -m space --focus 4
cannot focus space due to an error with the scripting-addition.

donaldguy commented 3 years ago

@peppy -m space --focus works fine for me, so I don't know

Some ideas:

You are on M1, yes? I have neither updated nor validated the x86_64 offsets
Just to check, you ran both sudo yabai --install-sa (once) and sudo yabai --load-sa (since you last restarted Dock.app/logged in/crashed the WindowServer/restarted the system) ?

(you can also put load-sa in your .yabairc if you do this setup)

If so, maybe try install-sa again but rm -rf /Library/ScriptingAdditions/yabai.osax first to make sure its actually up to date?
Are you signing your yabai binary? (./scripts/codesign ./bin/yabai after make). I'm not sure if this is required, but I do know that there is a signing step in --install-sas code. So I wouldn't be surprised if you do

Also it might just be a typo on your part, since you said it worked, but I can't help but notice as a pendant nerd :neckbeard: that the -m window --focus as written is missing a $ before the (, so I'd expect running that to just be telling yabai to focus your shell window 😅

More helpfully, if are doing this sort of thing from the cli, I would recommend https://github.com/Amar1729/yabai-zsh-completions which does a nice tab completion for window ids in a table with their titles

peppy commented 3 years ago

Ah, that would be it then. I am on intel!

Also the commands I wrote are written in fish format, which differs slightly from standard bash. Trust that it works :). I have it bound to keys so I'm not manually running these commands - just provided for comparison.

donaldguy commented 3 years ago

(Boo, my WindowServer died while I was typing this (lest you think all crashes in SA land are gone; they are rare but they do happen to me occasionally, seemingly at random), and Safari rudely tossed the in-progress textarea input)

So once more with feeling, but possibly less detail than before:

@peppy If you, or any other adventurous intel users in this thread (or M1 users who want to beat me to it on the next beta) want to follow my DIY / blind-ish process for updating the payload.m offsets yourself, here is my guide.

Disclaimer/Warning ⚠️: this reverse engineering may or may not be strictly legal. I didn't really look into the case law on the matter. Based on my vague understanding by osmosis, I'm not that worried— as evidenced by how I am talking about doing it and how to do it; but maybe I'm a fool and Apple is about to sue me 🤷.

<-- click to receive (possibly) 👻 𝔣𝔬𝔯𝔟𝔦𝔡𝔡𝔢𝔫 𝔨𝔫𝔬𝔴𝔩𝔢𝔡𝔤𝔢 🕯️

1. Probably disable `yabai` or get a `--layout float` space; Ghidra was for me an app that was ill-suited to tiling 2. Figure out what version the offsets in the existing code correspond to; for me this was beta 3, but I think (haven't checked) those for x86_64 are still beta 1. Somehow get the version of Dock.app from that release. if it is beta 1, its conveniently up there in the [OP](https://github.com/koekeishiya/yabai/issues/923#issue-915174423) of this issue 3. Setup [NationalSecurityAgency/ghidra](http://github.com/NationalSecurityAgency/ghidra) per its readme (and/or `brew install --cask`, but eh) - or if you'd rather spend $2k than run code written by the NSA on purpose, you could use IDA Pro and diaphora like xorpse; I also hear https://www.hopperapp.com is nice (and only $100; but I'm not sure it has a version differ)? Anyway, I used the FOSS ghidra - and prebuilt JARs at that 😱; whatever, bad opsec I know. I'mma keep talking about Ghidra, cause thats the one I did, ergo know 4. Import the old Dock binary (Dock.app/Contents/MacOS/Dock) to your project. Batch import when prompted (cause its a universal binary), pick your architecture. Open in the CodeBrowser, run the analysis as prompted (or probably you could get away with less, but eh), save. you can close 5. Import your local `/System/Library/CoreServices/Dock.app/Contents/MacOS/Dock`, open, analyze, save. Make sure names/paths are clear which version is which 6. Pull up the version tracker (the footprints icon) and configure with old and new version. Start the analysis - I clicked the star-wand looking icon. Note that it didn't actually ever finish for me, but I managed to do the rest before cancelling. - At/right before this point I actually (maybe or maybe not) had to (but certainly did) reopen the two binaries go to the bookmarks for the errors (you can filter on type in the bookmarks panel) from my analysis and just delete the bookmarks, so the preflight checks would pass. - The errors had to do with it falling over on the dyld_shared_cache addresses. that might just-work on intel, or it might work if you also import your `/System/Library/dyld/dyld_shared_cache_x86_64.*`s to the project - I never got it to work - Also I'm not sure you'll even have those errors either way if you don't like me try to get the experimental ObjC class and message analyzers to work 7. Possibly raise your resolution (to something non-HiDPI?) cause the CodeBrowser with the version tracker sidebar is thicc. You might also be able to get it to be a horizontal rather than vertical split 8. In the two CodeBrowsers that Version Tracker should open, Cmd-\` to the window with the old version 9. Go to the locations per the old addresses in the code (G opens the go to dialog, its also under I think Navigation? in the menu bar) 10. In the pane for the versiontracker (marked by the footprint icon), it should point you at the correlated address and its confidence. copy those out. 11. build, test, enjoy Fin.

^{(a good tweet)}

donaldguy commented 3 years ago

"fun" wrench in the works for beta 6: java segfaults when I try to run ghidra; My initial responses of trying reinstalling/upgrading jdk & disabling the arm64e_preview_abi have been ineffective

EDIT: also didn't work: making extra sure there are no other JDKs installed, installing the homebrew bottle java11

next attempt: installing that openjdk from source, ~~possibly with an upgraded Xcode beta~~ (nope; no new Xcode 13 beta since August 10 nor CommandLineTools. I was fucking around with a beta build of LLVM (for clang-format with debug symbols) in the interim, so I should probably make sure thats not a factor. )

initial result: the tmp javac to bootstrap the self-hosted (I guess) jdk build also segfaults

EDIT 2/3:That said I was/am not rocking the latest Xcode beta anyway apparently - so might as well try it I guess, incase anything in the sdk is different? (the os 12 beta 6 release notes suggest maybe); and hey lets throw a sudo rm -rf /Library/Developer/CommandLineTools; sudo xcode-select --install in for good measure

This did not help but that is remarkably unsurprising as on closer inspection the homebrew formula for this jdk is relying on the same zulu jdk I was initially trying to bootstrap

koekeishiya commented 3 years ago

The trial version of Hopper Disassembler is sufficient if you are unable to get Gihdra or IDA Pro working.

donaldguy commented 3 years ago

Because we live in possibly the weirdest timeline (if you asked me from like certainly any time before 2009, but probably several years since, maybe even literally still), I have gotten ghidra to open and run (quite well) using the aarch64 jdk for mac from ... Microsoft: https://github.com/microsoft/openjdk-aarch64/releases/tag/jdk-16.0.2-ga WTF?

Anyway, I got the beta 6 M1 offsets and they some to be working https://github.com/donaldguy/yabai/commit/8a65d56830ecb5a28958325eee75a4b1ea907a1d

leftbones commented 3 years ago

Does anyone have status on if Yabai is working or not on Monterey?

abzcoding commented 3 years ago

Does anyone have status on if Yabai is working or not on Monterey?

thanks to @donaldguy it works just fine Screen Shot 2021-09-19 at 7 45 19 PM

TheNoim commented 3 years ago

Does anyone have status on if Yabai is working or not on Monterey?

thanks to @donaldguy it works just fine

Only on M1 or also on intel?

abzcoding commented 3 years ago

Only on M1 or also on intel?

works on both, but there are some crashes here and there

alok commented 2 years ago

@donaldguy do you have instructions on building your fork? when i do make, i get invalid instruction mnemonic 'data' and similar errors. running monterery beta 6, m1 mac.

raunakdoesdev commented 2 years ago

I'm getting "cannot focus space due to an error with the scripting-addition" on M1 Mac Mini 6 21A5506j after trying install-sa, load-sa. SIP is disabled and I'm not getting any other output or descriptive error messages even with verbose mode on. Other things work though, like moving windows to a specific space. Any pointers @donaldguy or others? Thanks for your great work on this by the way!

erikc96 commented 2 years ago

I'm having similar issues on the latest update. I get a segmentation fault.

~ % yabai -v
yabai-v3.3.10

 ~ % sw_vers
ProductName:    macOS
ProductVersion: 12.0
BuildVersion:   21A5522h

devvz commented 2 years ago

Does anyone have status on if Yabai is working or not on Monterey?

thanks to @donaldguy it works just fine

This setup looks amazing 🤯. What are you using for the top bar?

abzcoding commented 2 years ago

This setup looks amazing 🤯. What are you using for the top bar?

simple-bar with my own config here is an updated pic

donaldguy commented 2 years ago

Hi, I've been off on a road trip away from fast internet and I missed beta 7 entirely :scream:

but anyway - here are the offsets for beta 8 on M1: https://github.com/donaldguy/yabai/commit/efc8785ec3483ffb6125a68c82ddc8fbbb42f6f7

at least is passing the health check and producing the happy notification banner. (EDIT: seems to actually work; I got one super whacky loop of front windows and then WindowServer crash right after I posted this - but that was with ghidra itself which was ~slow to exit before I re-enabled yabai 🤷 )

This was, again, just following my process from above

@alok @sauhaardac :

@donaldguy do you have instructions on building your fork? when i do make, i get invalid instruction mnemonic 'data' and similar errors. running monterery beta 6, m1 mac.

Hmmm ... That (since it cares about instruction level at all) sounds like an assembler error to me.

The one direct invocation into using arm asm (which was all @xorpse 's doing, not mine; indeed ... I don't think I knew you could get away with multiple files as a target like that... ) is around here:

https://github.com/donaldguy/yabai/blob/efc8785ec3483ffb6125a68c82ddc8fbbb42f6f7/makefile#L52-L53

So I'd focus in on that bit. as env goes, I have:

$ which as
/usr/bin/as

$ xcode-select -p
/Library/Developer/CommandLineTools

$  as --version
Apple clang version 13.0.0 (clang-1300.0.27.3)
Target: arm64-apple-darwin21.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

(as seems to also probably secretly just be clang also, but maybe behaving differently on the argv0 switch?)

My overall session rebuilding/installing after doing the above update looked like

this (input and output)

``` yabai on  canon [$?⇡] via  v16.10.0 ❯ make clean makefile:42: warning: overriding commands for target `src/osax/sa_payload.c' makefile:34: warning: ignoring old commands for target `src/osax/sa_payload.c' rm -rf ./bin rm -f ./src/osax/arm64/injector.o ./src/osax/sa_payload.c ./src/osax/sa_loader.c ./src/osax/sa_mach_bootstrap.c ./src/osax/sa_payload.c yabai on  canon [$?⇡] via  v16.10.0 ❯ make makefile:42: warning: overriding commands for target `src/osax/sa_payload.c' makefile:34: warning: ignoring old commands for target `src/osax/sa_payload.c' rm -rf ./bin /Library/Developer/CommandLineTools/usr/bin/clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -arch x86_64 -o ./src/osax/loader -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" -framework Foundation /Library/Developer/CommandLineTools/usr/bin/clang ./src/osax/mach_bootstrap.c -shared -fPIC -O2 -mmacosx-version-min=10.13 -arch x86_64 -o ./src/osax/mach_bootstrap -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" -framework Carbon -lpthread xxd -i -a ./src/osax/loader ./src/osax/sa_loader.c xxd -i -a ./src/osax/mach_bootstrap ./src/osax/sa_mach_bootstrap.c rm -f ./src/osax/loader rm -f ./src/osax/mach_bootstrap /Library/Developer/CommandLineTools/usr/bin/clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -arch x86_64 -arch arm64e -o ./src/osax/payload -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" -framework Foundation -framework Carbon xxd -i -a ./src/osax/payload ./src/osax/sa_payload.c rm -f ./src/osax/payload mkdir -p ./bin /Library/Developer/CommandLineTools/usr/bin/clang src/manifest.m src/osax/sa_loader.c src/osax/sa_mach_bootstrap.c src/osax/sa_payload.c -arch x86_64 -std=c99 -Wall -g -O0 -fvisibility=hidden -mmacosx-version-min=10.13 -F/System/Library/PrivateFrameworks -framework Carbon -framework Cocoa -framework CoreServices -framework SkyLight -framework ScriptingBridge -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" -o bin/yabai-x86_64 dd if=./src/osax/arm64/sa_arm64e.o of=./src/osax/arm64/sa_arm64e bs=1 count=300 skip=312 300+0 records in 300+0 records out 300 bytes transferred in 0.001230 secs (243902 bytes/sec) xxd -i -a ./src/osax/arm64/sa_arm64e ./src/osax/arm64/sa_arm64e.h /Library/Developer/CommandLineTools/usr/bin/clang -c ./src/osax/arm64/injector.c -o ./src/osax/arm64/injector.o -arch arm64e -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" rm -f ./src/osax/arm64/sa_arm64e sysctl kern.bootargs | grep -q -- -arm64e_preview_abi || (echo >&2 "\n\nBooted w/o arm64e ABI support!"; glow README-arm64.md >&2; exit 1) #technically we can build the binary w/o the abi enabled, but output will be immediately SIGSEVEd mkdir -p ./bin /Library/Developer/CommandLineTools/usr/bin/clang src/manifest.m src/osax/arm64/injector.o src/osax/sa_payload.c -arch arm64e -std=c99 -Wall -g -O0 -fvisibility=hidden -mmacosx-version-min=10.13 -F/System/Library/PrivateFrameworks -framework Carbon -framework Cocoa -framework CoreServices -framework SkyLight -framework ScriptingBridge -isysroot "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" -o bin/yabai-arm64 ld: warning: object file (src/osax/arm64/injector.o) was built for newer macOS version (12.0) than being linked (11.0) lipo -create ./bin/yabai-x86_64 ./bin/yabai-arm64 -output ./bin/yabai yabai on  canon [$?⇡] via  v16.10.0 took 3s ❯ ./scripts/codesign ./bin/yabai ./bin/yabai: replacing existing signature ./bin/yabai: signed Mach-O universal (x86_64 arm64e) [yabai] yabai on  canon [$?⇡] via  v16.10.0 ❯ mv ./bin/yabai $(realpath =yabai) yabai on  canon [$?⇡] via  v16.10.0 ❯ sudo yabai --uninstall-sa Password: yabai on  canon [$?⇡] via  v16.10.0 took 2s ❯ sudo yabai --install-sa yabai on  canon [$?⇡] via  v16.10.0 ❯ sudo yabai --load-sa ```

If you did into the makefile a little you'll see that CLANG is hardcoded as /Library/Developer/CommandLineTools/usr/bin/clang - so maybe make sure thats up to date (if for example you normally use the Xcode.app install; or try replacing it?) ; or maybe add a similar absolute pathed in as

magebeans commented 2 years ago

Running into the same invalid instruction issues as the previous posters, and I noticed that they're compiler errors on the as -o ./src/osax/arm64/sa_arm64e.o ./src/osax/arm64/sa_arm64e.s command, which I don't actually see in your session. Could it be that make clean isn't deleting these files and so you don't run into it because your make is just re-using the compiled versions from a previous successful run?

magebeans commented 2 years ago

Changing the as invocation to as -arch arm64e -o $(OSAX_PATH)/arm64/sa_arm64e.o $(OSAX_PATH)/arm64/sa_arm64e.s adding the -arch flag to force compiling the inline assembly as Apple Silicon ARM fixes it for me.

magebeans commented 2 years ago

@donaldguy do the scripting additions work fine for you? I'm seeing issues with commands affecting spaces fail silently.

donaldguy commented 2 years ago

@magebeans yeah space manipulation works for me:

https://user-images.githubusercontent.com/43136/135575757-64d57dea-b2ff-44a8-828b-22d274ecc795.mp4

Do note that you need to run --load-sa anytime you reboot / login / restart Dock.app. Ideally directly in your .yabairc after allowlisting the command for passwordless invocation in sudoers as described in https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(latest-release)#macos-big-sur---automatically-load-scripting-addition-on-startup

I do it in my .yabairc here: https://github.com/donaldguy/dotfiles/blob/749c564f6b5f8f1d22ecc7f593cad5c8d80f8bd0/executable_dot_yabairc#L65

donaldguy commented 2 years ago

Just M1 - I don’t have an Intel w/ me to test against - tho I could maybe ferret them out

And/but I believe the Intel code is mostly still set up to do a search for the functions (specified as hex of some of the raw instructions) at runtime (I’m not looking at the code right now, so I could be wrong)

raunakdoesdev commented 2 years ago

I'm still facing the space manipulation issues on M1.

Bit of a dumb question, but how are you installing yabai in this case? There's the brew installer and then you can also compile it from scratch. Maybe I'm messing something up there.

donaldguy commented 2 years ago

I installed using @xorpse's homebrew formula (though the like upstream one is probs just as good?) and then overwrote the binary with the one I built from source, hence the use of mv ./bin/yabai $(realpath $(which yabai)) for my install

(this may have been obscured slightly by the zsh-specific =yabai syntax, sorry)

(realpath from coreutils ; you could also use readlink or maybe brew ls)

raunakdoesdev commented 2 years ago

Got it, thanks so much for your help. I followed the instructions as you said but am still running into issues with spaces. Here is a video: https://www.loom.com/share/b57ce7df6b044240b4ef7b5ceafb3c28

donaldguy commented 2 years ago

When you run --load-sa I'd expect to see either a notification like:

I'm guessing its just that you had a DND / Focus set that suppressed - but yeah: its not a huge signal - but I guess the question is like, does yabai think its gonna work and then doesn't? or does it know it doesn't have the SA loaded and is just ignoring your space commands

raunakdoesdev commented 2 years ago

I disabled the focus mode and I'm getting the first notitifaction that the payload doesn't support this macOS version. Is that an actual error or expected?

When I run yabai in the terminal (top left window) rather than through brew services I get the following behavior: https://www.loom.com/share/5ca4e7dcbc51406ab07d39a3a0838008

magebeans commented 2 years ago

Which version are you on? The payload offsets are version-specific, so you might have to either change versions or update the payload offsets in the manner described here to get them working. I will say that even with updated offsets, I've been running into WindowServer crashes often enough that I haven't been using yabai on Monterey much.

magebeans commented 2 years ago

Anybody seeing iTerm crashes with yabai on Monterey? I also seem to have issues with the Calendar app freezing up.

shepherdjerred commented 2 years ago

I was finally able to get yabai working on my M1 MacBook running Monterey Beta 8! Here's what I did:

# Install official packages
brew install yabai skhd

git clone https://github.com/donaldguy/yabai/
# Follow instructions in https://github.com/donaldguy/yabai/blob/master/README-arm64.md

make -j1
# Follow instructions to setup code signing cert: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD)
make sign

# Replace the homebrew binary with the one just built
mv ./bin/yabai $(realpath $(which yabai))
sudo yabai --install-sa
sudo yabai --load-sa

brew services start yabai
brew services start skhd

Everything works; even space switching! I haven't gotten a crash either.

shaunsingh commented 2 years ago

Thanks for the summary note that you can also run make -j8 since you have 8 cores

donaldguy commented 2 years ago

found beta 9 M1 offsets: https://github.com/donaldguy/yabai/commit/723f2ee0346b78360c497b7a7eb7be409c02302c

(the two non-functions don't seem to have moved)

EDIT: here's a binary if anybody wants it / wants to trust me :D yabai.zip

shaunsingh commented 2 years ago

Whats the plan once macOS 12 releases? Is the donaldguy fork going to get merged into yabai master?
@donaldguy Can you kindly make a release on GitHub. I have a nix configuration which is set to download from GitHub releases (for a given version).

donaldguy commented 2 years ago

@shaunsingh This work?

https://github.com/donaldguy/yabai/releases/tag/v3.4.0%2Bdonaldguy

shaunsingh commented 2 years ago

Yup, works perfectly. Thanks!

shaunsingh commented 2 years ago

I followed all the instructions, and get this every time I try to load the sa: yabai: scripting-addition could not locate pid of Dock.app!

donaldguy commented 2 years ago

There's not a lot complexity in which for it to go wrong

https://github.com/donaldguy/yabai/blob/723f2ee0346b78360c497b7a7eb7be409c02302c/src/osax/sa.m#L258-L268

@shaunsingh To ask the obvious, ... is Dock.app, in fact, running? (I know that when I was a uBar user for a while it had a hack to suppress it starting entirely; I wouldn't be shocked if you, as a Nix user, were doing something similar)

Does nix introduce some kind of extra sandboxing that could be keeping it from seeing the process? (EDIT: another pretty speculative idea: does it ... set up aggressive static linking? I wouldn't be shocked if dynamic loading/paging of a ~shared objective C runtime was normal and if nix (even can) subvert/s this, I'd see how that would be a problem for NSRunningApplication)

@xorpse 's fork (and by extension mine) can build a binary that:

just does the injection (so that you can set it up setuid)
more relevant to our interests, it takes the pid as an input rather than trying to discover it

You don't need/want to call this until your .yabairc ; if you need to sidestep the nix parent chain to duck sandboxing(?), maybe like ... do it as a launchd user agent? idk.

Or, of course, you could literally just run it manually

shaunsingh commented 2 years ago

Probably some nix sandboxing or linking thats messing it up. I ran it manually and its fine.

I checked activity monitor, Dock.app is running fine. Nix introduces sandboxing, but on macOS its disabled by default so that shouldn't be an issue. The aggressive linking is likely what's causing it. Sorry for the trouble!

deividaspetraitis commented 2 years ago

Anyone was lucky enough to make it work on Monterey running Intel?

peppy commented 2 years ago

Anyone was lucky enough to make it work on Monterey running Intel?

I do have it kind-of-working. Actions to move around spaces doesn't work (you can still target specific windows on a space to make that space active, to workaround this) but everything else seems to be in order (although it will randomly crash/re-layout once every 30 minutes or so). I'm not using any special patches, just the latest release build.

mak1A4 commented 2 years ago

@donaldguy any chance you already had time to look at Monterey 12.0.1 RC (21A558)? I have upgraded today and unfortunatly scripting additions have stopped working :-/

donaldguy commented 2 years ago

I have not - I have been traveling and not on consistently good enough WiFi to take the update

I will post here & update the description of my fork when I do - or someone else can give it a shot :D using the process I posted: https://github.com/koekeishiya/yabai/issues/923#issuecomment-899116832

mak1A4 commented 2 years ago

I would like to give it a shot. Could you (or someone else) maybe upload the beta 9 version of Dock.app, I'm kinda struggling to find it after upgrading. Thanks.

donaldguy commented 2 years ago

Dock-beta9.app.zip

mak1A4 commented 2 years ago

That was quick, thanks :)

donaldguy commented 2 years ago

yeah, I am recently back on good enough Wifi, but I am currently in a (pretty passively watching/listening) zoom meeting, so can't take the update per se yet - but yeah, it's pretty easy.

A missing step is maybe "wait a bit" after you start the correlation; when I wrote up the instructions, I wasn't quick enough for it to matter - but YMMV

HosAkh commented 2 years ago

Hi, does the active border window work on the Monterey? I'm can't seem to get it to work and I don't know if it's my config file or something else (even the copy and pasted codes don't work)

yabai -m config window_border on
yabai -m config window_border_width 3
yabai -m config active_window_border_color 0xFF40FF00
yabai -m config normal_window_border_color 0x00FFFFFF
yabai -m config insert_feedback_color        0xffd75f5f

mak1A4 commented 2 years ago

@HosAkh for me borders work on 12.0.1 RC (21A558) with the same config you have. @donaldguy I managed to find new offsets with ghidra but unfortunately space switching still doesn't work, also some programs have to be force quitted otherwise they will hang. Could it be that vor 12.0.1 RC we have to change more then just payload.m?

EDIT: I had notifications disabled for yabai, now I'm getting

payload (0x3C) doesn't support this macOS version!

this notifications also pops up without my modified version of payload.m

leftbones commented 2 years ago

The base version of Yabai appears to be working fine on Monterey (12.0.1) however the windows keep shuffling around even when I'm not doing anything. Is there a fix for that?

Previous Next

Issue	Note
build from source fails	Click to expand build log ``` ❯ make rm -rf ./bin xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon ./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber psn); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:37:8: error: interface type 'NSError' cannot be returned by value; did you forget in 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber psn); ^ ./src/osax/payload.m:38:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:38:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha); ^ * ./src/osax/payload.m:39:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowListAlpha(int cid, const uint32_t window_list, int window_count, float alpha, float duration); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:39:8: error: interface type 'NSError' cannot be returned by value; did you forget in 'NSError'? extern CGError CGSSetWindowListAlpha(int cid, const uint32_t window_list, int window_count, float alpha, float duration); ^ ./src/osax/payload.m:40:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:40:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level); ^ * ./src/osax/payload.m:42:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:42:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list); ^ * ./src/osax/payload.m:43:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int window_cid); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:43:8: error: interface type 'NSError' cannot be returned by value; did you forget in 'NSError'? extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int window_cid); ^ ./src/osax/payload.m:44:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:44:51: error: unknown type name 'CGWindowID' extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^ ./src/osax/payload.m:44:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^ * ./src/osax/payload.m:45:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:45:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^ * ./src/osax/payload.m:46:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:46:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^ * fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make: *** [src/osax/sa_loader.c] Error 1 ```
constant crashes	See #920 for details.

Issue

Note

build from source fails

Click to expand build log

``` ❯ make rm -rf ./bin xcrun clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation xcrun clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon ./src/osax/payload.m:37:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:37:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSGetConnectionPSN(int cid, ProcessSerialNumber *psn); ^ * ./src/osax/payload.m:38:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:38:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowAlpha(int cid, uint32_t wid, float alpha); ^ * ./src/osax/payload.m:39:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:39:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowListAlpha(int cid, const uint32_t *window_list, int window_count, float alpha, float duration); ^ * ./src/osax/payload.m:40:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:40:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowLevel(int cid, uint32_t wid, int level); ^ * ./src/osax/payload.m:42:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:42:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSReassociateWindowsSpacesByGeometry(int cid, CFArrayRef window_list); ^ * ./src/osax/payload.m:43:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:43:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSGetWindowOwner(int cid, uint32_t wid, int *window_cid); ^ * ./src/osax/payload.m:44:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:44:51: error: unknown type name 'CGWindowID' extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^ ./src/osax/payload.m:44:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSInvalidateWindowShadow(int cid, CGWindowID wid); ^ * ./src/osax/payload.m:45:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:45:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSSetWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^ * ./src/osax/payload.m:46:8: error: unknown type name 'CGError'; did you mean 'NSError'? extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^~~~~~~ NSError /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserScriptTask.h:8:88: note: 'NSError' declared here @class NSAppleEventDescriptor, NSArray, NSDictionary, NSError, NSFileHandle, NSString, NSURL, NSXPCConnection; ^ ./src/osax/payload.m:46:8: error: interface type 'NSError' cannot be returned by value; did you forget * in 'NSError'? extern CGError CGSClearWindowTags(int cid, uint32_t wid, const int tags[2], size_t maxTagSize); ^ * fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. make: *** [src/osax/sa_loader.c] Error 1 ```

constant crashes

See #920 for details.

koekeishiya / yabai

macOS 12 Monterey #923