macOS 12 Monterey

[dominiklohmann]

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).

devvz 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?

This was happening to me as well with @donaldguy's fixes when I tried during developer beta 8. Would randomly switch window places (I'm guessing yabai was maybe restarting?). Couldn't really figure it out, so haven't tried since then.

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?

This was happening to me as well with @donaldguy's fixes when I tried during developer beta 8. Would randomly switch window places (I'm guessing yabai was maybe restarting?). Couldn't really figure it out, so haven't tried since then.

Yeah I'm hoping someone can help me out, I only use Yabai for two apps every time, and others I toggle when I need to tile, but it's frustrating to have everything shuffling around for no reason while I'm working.

shaunsingh commented 2 years ago

For me, every time I open a new app, yabai crashes, restarts, and rearranges windows. The crashing was actually the first issue in this thread (see https://github.com/koekeishiya/yabai/issues/920 which this issue continues).

koekeishiya commented 2 years ago

If you cannot wait til ~end of november, try the the-future branch instead of master. Read the changelog if you do so.

leftbones commented 2 years ago

If you cannot wait til ~end of november, try the the-future branch instead of master. Read the changelog if you do so.

I'll try this out, is there any special installation instructions for this, or is it just like normal?

HosAkh 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?

oh I thought I was doing something and didn't know it was a known issue. I spent all day yesterday trying to figure out what I was doing wrong and trying to get the borders working. Will be trying out the feature branches and reporting back

HosAkh commented 2 years ago

@HosAkh for me borders work on 12.0.1 RC (21A558) with the same config you have.

Do you have a screenshot of what the borders looks like for you so I can see what a preview of it looks like?

I even tried turning the borders green so I could see if it was maybe the coloring the made it look like there was no border but nothing changed for me.

for example, does this give you a blue border around the active window? yabai -m config active_window_border_color 0x1977f3

Thanks ahead

koekeishiya commented 2 years ago

I'll try this out, is there any special installation instructions for this, or is it just like normal?

Same instructions as usual, the scripting-addition is not updated, but it should be stable. Read the changelog to see breaking changes.

donaldguy commented 2 years ago

@mak1A4 I got around to doing it also – here's what I got:

https://github.com/donaldguy/yabai/commit/00bf5e46685df0cd3e961c155615ddecc75562ab

SA seems to load fine for me (with the payload version rather than error notification; haven't put through all the paces). Do those addresses match your findings?

(Though, for example, I messed it up briefly by forgetting to actually mv my new binary into place before using sudo yabai --install-sa and falling back to my path; its a finicky process, easy to make silly mistakes/oversights; no worries)

---

re other recent thread traffic: when I last checked borders drew fine most of the time, but having them enabled caused more windowserver crashes (per my memory because of attempts by yabai to draw or remove borders on short lived windows; a similar thing happens to me still occasionally with removing shadows)

I am not having a crash and redraw problem (obviously; or I would fix it or give up on using this). I'd just say to that, try running with debug output enabled / look at the log (I have this in my config so that debug output comes on automatically when run direct from shell rather than via launchd; so I can just do brew services stop yabai; yabai to do debugging)

If I had to guess, I would bet its about granting accessibility permissions?

EDIT: with this build, yabai -m space --destroy 2 seems to cause the windows to get relaid out in space 1 (that I am focused on); it doesn't seem to be cause yabai or Dock is crashing, so odd. I'd believe though could be a result of something else about my setup (the event handler or another program that's running)

I'll try to look into it, but its not a priority

leftbones commented 2 years ago

I'll try this out, is there any special installation instructions for this, or is it just like normal?

Same instructions as usual, the scripting-addition is not updated, but it should be stable. Read the changelog to see breaking changes.

I'm attempting to build from source on the branch the-future with the most recent commit a97a574 and getting a TON of errors running make -f makefile, here's a pastebin if that's helpful: https://pastebin.com/yaEJhgDn

donaldguy commented 2 years ago

@evprkr glancing at your pastebin quickly, you are back toward the beginning of this thread in terms of problems addressed in @xorpse 's fork (and/or mine)

Like https://github.com/koekeishiya/yabai/issues/923#issuecomment-856885054 adding that import (there or somewhere else) should definitely pare down the errors

EDIT: Also, all things being equal, I would prefer people use gist.github.com over pastebin cause of ads, etc. not a strong preference - but a preference

EDIT 2: Or like you may have seen me do above, Github supports use of the <details> tag - you just may have to add extra newlines to get the markdown parser to go back to normal markdown parsing (vs html tag parsing); or in the worst case, use <pre> inside it

leftbones commented 2 years ago

EDIT 2: Or like you may have seen me do above, Github supports use of the <details> tag - you just may have to add extra newlines to get the markdown parser to go back to normal markdown parsing (vs html tag parsing); or in the worst case, use \<pre\> inside it

I didn't know about those, thanks!

I added the import from #923, and have indeed narrowed down the errors:

> make -f makefile
rm -rf ./bin
clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation
clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon
clang ./src/osax/mach_bootstrap.c -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/mach_bootstrap -framework Carbon -lpthread
./src/osax/mach_bootstrap.c:32:76: error: unknown register name '%rax' in asm
    for (;;) __asm__ __volatile__ ("movq %0, %%rax;" ::"r"(0x7961626169) : "%rax");
                                                                           ^
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

mak1A4 commented 2 years ago

@donaldguy yup findings match, unfortunatly I'm still getting the error notification

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

I did move the binary after building, so I'm kinda stuck right now :-/

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

@evprkr I'm getting the same error when trying to build "the-future" branch

leftbones commented 2 years ago

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

I'm still getting the same error after running softwareupdate --install --all --force and downloaded the latest version of CLT

HosAkh commented 2 years ago

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

I'm still getting the same error after running softwareupdate --install --all --force and downloaded the latest version of CLT

I've been getting the same errors. I posted a question about it under Q&A (wasn't sure if it was something I was doing incorrectly).

I did all version of the software update for CLT and still get the same error message.

mak1A4 commented 2 years ago

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

leftbones commented 2 years ago

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

This wasn't working for me yesterday, but today it is. Thanks I guess!

EDIT: Except I'm still getting the "reshuffling" issue I was having earlier.

mak1A4 commented 2 years ago

@evprkr yesterday payload.m wasn't updated for 12.0.1RC that's why it wasn't working. Unfortunatly I can't really help you with the reshuffling issue :-/

HosAkh commented 2 years ago

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

shaunsingh commented 2 years ago

Is the the-future branch good for m1 Macs as well, or should I stick to donaldguy's fork? I don't need the SA, I just want to get rid of the window shuffling issue

leftbones commented 2 years ago

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

Just noticed I completely missed that step. I'm not really sure what it means though.

EDIT: Found the answer, the command is literally as typed. If you get an error saying the realpath command isn't found, run brew install coreutils

EDIT 2: After following the above instructions, it appears my issue is resolved!

HosAkh commented 2 years ago

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

Just noticed I completely missed that step. I'm not really sure what it means though.

EDIT: Found the answer, the command is literally as typed. If you get an error saying the realpath command isn't found, run brew install coreutils

EDIT 2: After following the above instructions, it appears my issue is resolved!

I tried that command and this is the message that I'm getting:

mv ./bin/yabai $(realpath $(which yabai))
mv: /Users/my-user-name/.config/yabai/found is not a directory

So then I tried replacing realpath with copy pasting the directory's path to it and says permission denied even when I tried it withsudo`

zsh: permission denied: /Users/my-user-name/.config/yabai/yabai
usage: mv [-f | -i | -n] [-v] source target
       mv [-f | -i | -n] [-v] source ... directory

I tried it with mv -f as well but it still gave me the same error.

• did you try this with the the-future branch or the m1 branch
• did you try a specific folder or directory to install yabai in? I have tried this in my download and my .config/yabai folder. Both gave me the same results

Also thank you for all of your patience and assistance

SamHep0803 commented 2 years ago

i've just installed @donaldguy's fork and its working brilliantly apart for the fact that for some reason, "official" Apple applications (i've seen it happen on Preview and the App Store so far) seem to stop responding to mouse and keyboard input immediately after a mouse scroll. As well as this you can only quit the application via Pkill.

I'm not too familiar with the yabai codebase/how it all works but I'd be completely happy to respond with any logs or anything.

junwei-wang commented 2 years ago

Anyone encounter the following error:

$ yabai                                                                                                             
could not locate the space to act on!
yabai configuration loaded..
fish: Job 1, 'yabai' terminated by signal SIGSEGV (Address boundary error)

Thanks in advance for your help.

weizheheng commented 2 years ago

I went through this thread and can't seem to find any working solutions for Intel mac. Tried to clone @donaldguy branch but couldn't get it to compile. Anyone has luck getting a workaround for yabai to run on Intel Mac with Monterey?

I have the yabai latest master version now, and some of the problems I am facing is similar to others:

1. Yabai restarts randomly causing the reshuffling (this happens a lot especially when I have the Books app opened, have to turned yabai off now)
2. Space/Desktop focusing does not work (falling back to Macbook built-in keyboard shortcut for desktop switching now).
3. Border not working (I can definitely live without this though)

🙏 Appreciate if anyone can point me to a workaround until we have a new release for Monterey support. So hard to live without a tiling manager.

peppy commented 2 years ago

@marcushwz can confirm all the issues you mention. have been living with these for months now. they aren't too bad, but definitely not optimal. note that borders do seem to be working, but are rendered beneath the window rather than above making them mostly hidden.

donaldguy commented 2 years ago

There are fixes for some things on my fork (and xorpse’s); it’s not just the SA offset updates

Check ‘em out if you want or don’t. There are also open PRs against upstream(s) for most of them

HosAkh commented 2 years ago

What's the eta for yabai intels based Monterey release? late November (assuming that's like November 20th)

choco commented 2 years ago

@koekeishiya FYI, the MISSION_CONTROL_ENTER event is not fired on macOS Monterey :( Hopefully they haven't restricted SLSRegisterConnectionNotifyProc completely...

koekeishiya commented 2 years ago

What's the eta for yabai intels based Monterey release? late November (assuming that's like November 20th)

Same as for the Apple Silicon version. My current mbp does not support Monterey. See https://github.com/koekeishiya/yabai/issues/725#issuecomment-949484389

rpoovey commented 2 years ago

@donaldguy, has this been tested on the M1 Pro/Max? I get the following when trying to compile. 12.0.1

 make -j1
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 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk" -framework Foundation
In file included from ./src/osax/loader.m:2:
In file included from ./src/osax/x86_64/loader.m:1:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
- (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
                                                         ~~~~~~~~~~~~~~                                                                       ^                  ~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
        #define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A)))
                                                      ^          ~
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

donaldguy commented 2 years ago

Nope, just got an M1 Air.

That doesn't look super in the weeds of arch specific stuff though, so I am a little surprised

it jumps out at me that the invocation is (hardcoded to) /Library/Developer/CommandLineTools/usr/bin/clang vs the invocation on the include path looking into SDK within /Applications/Xcode.app/Contents/Developer/

so I would maybe try upgrading one or both (e.g. softwareupdate --all --install --force) or normalizing to just CommandLineTools or just Xcode by changing SDK_PATH CLANG_PATH in the makefile and/or do sudo xcode-select --switch /Library/Developer/CommandLineTools

donaldguy commented 2 years ago

Oh well except there's a much bigger problem @rpoovey which is that its building ./src/osax/x86_64/loader.m at all

donaldguy commented 2 years ago

Can you try arch -arch arm64e make ?

rpoovey commented 2 years ago

@donaldguy

SDK_PATH: running the command xcrun --sdk macosx --show-sdk-path) returns /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Running sudo xcode-select --switch /Library/Developer/CommandLineTools and then make -j1 gives me

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
In file included from ./src/osax/loader.m:2:
./src/osax/x86_64/loader.m:1:9: fatal error: 'Foundation/Foundation.h' file not found
#import <Foundation/Foundation.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

Which is a bit different

arch -arch arm64e make yields the same output.

donaldguy commented 2 years ago

It still seems like you are ending up invoking Intel toolchain somewhere in the line, whether its clang or something further underneath

If you got here via a migration or a ~time machine restore, you might try nuking and reinstalling CLTs (sudo rm -rf /Library/Developer/CommandLineTools && sudo xcode-select --install) ; also make sure at least that your PATH has /opt/homebrew/bin before /usr/local/bin (not that any homebrew stuff should really be involved here), but maybe consider deleting (or moving out of place) any intel dev tools in /usr/local.

rpoovey commented 2 years ago

This was indeed from a migration. I removed intel based homebrew earlier today but didnt think about CLT. I'll run the removal and re-install and report back. Smart thinking.

rpoovey commented 2 years ago

@donaldguy. Good catch, that fixed it.

Thanks!

vespakoen commented 2 years ago

Just wanted to report that I am running @donaldguy's fork successfully on a M1 Pro & Monterey (12.0.1). The only problem I ran into is when window_border was set to on, it causes applications to hang, so this should be set to off for the time being.

Steps used where:

• Create the yabai-cert as outlined in this guide: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD)
• Do the dance: https://github.com/donaldguy/yabai/blob/canon/README-arm64.md

choco commented 2 years ago

While spending some time investigating changes in Monterey I stumbled upon a bunch of notifications that the Dock.app sends. I didn't see these documented anywhere, maybe they can be useful. Just need to register specifically for these:

• AXExposeExit: when exiting mission control
• AXExposeShowFrontWindows: when mission control has finished activating in show front windows mode
• AXExposeShowAllWindows: when mission control has finished activating in show all windows mode
• AXExposeShowDesktop: not sure when this is triggered
• AXLaunchpadShown: when launchpad has finished activating
• AXLaunchpadHidden: when launchpad is left

Unfortunately those are triggered at the end of the respective animation, so for example when activating mission control through the 4 finger gesture on the trackpad you won't get an immediate notification.

donaldguy commented 2 years ago

I added offsets for 12.1 beta 1 to my fork, but conditionalized so 12.0.1 should keep working; if there's a 12.0.2 I'm gonna need somebody else to do the update

https://github.com/donaldguy/yabai/commit/3fe15373d97475ce9b5d22ed65814beaf13f204d

mak1A4 commented 2 years ago

@donaldguy I think I should be able to do it now :)

sallar commented 2 years ago

@donaldguy does your fork only work with M1? I tried cloning it on my Intel mac and it failed to compile.

donaldguy commented 2 years ago

@donaldguy does your fork only work with M1?

@sallar The consensus in the thread seems like no. I have been traveling these last two months and don't have a non-M1 mac with me to test or debug on (nor would I definitely do it if I did, but I might)

Sorry.

It seems like maybe people are having luck with the the-future branch here. To quickly slap something together ...

EDIT: ... I'd start from here if one is intent on getting my fork going on intel: https://github.com/donaldguy/yabai/tree/intel-maybe-probably-not

marshall-mcmullen commented 2 years ago

Thanks for the updated intel branch @donaldguy . I tried it out and hit a different compiler error due to an unterminated ifdef:

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
./src/osax/payload.m:208:2: error: unterminated conditional directive
#ifdef __arm64__
 ^
1 error generated.
make: *** [src/osax/sa_payload.c] Error 1

LachlanGrant commented 2 years ago

@marshall-mcmullen I've got a compiling version here: https://github.com/donaldguy/yabai/pull/1

marshall-mcmullen commented 2 years ago

@LachlanGrant -- thanks! I did indeed get past that compile error with your fork. Now I'm getting a different error though (on my intel based mac). Did you get this one?

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
as -o ./src/osax/arm64/sa_arm64e.o ./src/osax/arm64/sa_arm64e.s
./src/osax/arm64/sa_arm64e.s:5:13: error: unknown token in expression
sub sp, sp, #0x20
            ^

LachlanGrant commented 2 years ago

@marshall-mcmullen try running make clean and then make bin/yabai-x86_64 ... this will build only for intel

marshall-mcmullen commented 2 years ago

Thanks very much @LachlanGrant, that totally worked! Finally have it working again!

weizheheng commented 2 years ago

Thanks @LachlanGrant , got it working on my Intel machine as well.

@peppy , got it working without the restarting and random shuffling anymore. You might want to give the branch a shot.

@marshall-mcmullen , did you get the space switching work? I no longer get error when running

yabai -m space --focus 2

But it is not actually switching to the intended space.

Update after using for a few hours

• Mac WindowServer has been crashing randomly after switching to the branch above. Had to fall back to the master version now.

Previous Next

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

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.

[devvz]

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?

This was happening to me as well with @donaldguy's fixes when I tried during developer beta 8. Would randomly switch window places (I'm guessing yabai was maybe restarting?). Couldn't really figure it out, so haven't tried since then.

[leftbones]

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?

This was happening to me as well with @donaldguy's fixes when I tried during developer beta 8. Would randomly switch window places (I'm guessing yabai was maybe restarting?). Couldn't really figure it out, so haven't tried since then.

Yeah I'm hoping someone can help me out, I only use Yabai for two apps every time, and others I toggle when I need to tile, but it's frustrating to have everything shuffling around for no reason while I'm working.

[shaunsingh]

For me, every time I open a new app, yabai crashes, restarts, and rearranges windows. The crashing was actually the first issue in this thread (see https://github.com/koekeishiya/yabai/issues/920 which this issue continues).

[koekeishiya]

If you cannot wait til ~end of november, try the the-future branch instead of master. Read the changelog if you do so.

[leftbones]

If you cannot wait til ~end of november, try the the-future branch instead of master. Read the changelog if you do so.

I'll try this out, is there any special installation instructions for this, or is it just like normal?

[HosAkh]

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?

oh I thought I was doing something and didn't know it was a known issue. I spent all day yesterday trying to figure out what I was doing wrong and trying to get the borders working. Will be trying out the feature branches and reporting back

[HosAkh]

@HosAkh for me borders work on 12.0.1 RC (21A558) with the same config you have.

Do you have a screenshot of what the borders looks like for you so I can see what a preview of it looks like?

I even tried turning the borders green so I could see if it was maybe the coloring the made it look like there was no border but nothing changed for me.

for example, does this give you a blue border around the active window? yabai -m config active_window_border_color 0x1977f3

Thanks ahead

[koekeishiya]

I'll try this out, is there any special installation instructions for this, or is it just like normal?

Same instructions as usual, the scripting-addition is not updated, but it should be stable. Read the changelog to see breaking changes.

[donaldguy]

@mak1A4 I got around to doing it also – here's what I got:

https://github.com/donaldguy/yabai/commit/00bf5e46685df0cd3e961c155615ddecc75562ab

SA seems to load fine for me (with the payload version rather than error notification; haven't put through all the paces). Do those addresses match your findings?

(Though, for example, I messed it up briefly by forgetting to actually mv my new binary into place before using sudo yabai --install-sa and falling back to my path; its a finicky process, easy to make silly mistakes/oversights; no worries)

---

re other recent thread traffic: when I last checked borders drew fine most of the time, but having them enabled caused more windowserver crashes (per my memory because of attempts by yabai to draw or remove borders on short lived windows; a similar thing happens to me still occasionally with removing shadows)

I am not having a crash and redraw problem (obviously; or I would fix it or give up on using this). I'd just say to that, try running with debug output enabled / look at the log (I have this in my config so that debug output comes on automatically when run direct from shell rather than via launchd; so I can just do brew services stop yabai; yabai to do debugging)

If I had to guess, I would bet its about granting accessibility permissions?

EDIT: with this build, yabai -m space --destroy 2 seems to cause the windows to get relaid out in space 1 (that I am focused on); it doesn't seem to be cause yabai or Dock is crashing, so odd. I'd believe though could be a result of something else about my setup (the event handler or another program that's running)

I'll try to look into it, but its not a priority

[leftbones]

I'll try this out, is there any special installation instructions for this, or is it just like normal?

Same instructions as usual, the scripting-addition is not updated, but it should be stable. Read the changelog to see breaking changes.

I'm attempting to build from source on the branch the-future with the most recent commit a97a574 and getting a TON of errors running make -f makefile, here's a pastebin if that's helpful: https://pastebin.com/yaEJhgDn

[donaldguy]

@evprkr glancing at your pastebin quickly, you are back toward the beginning of this thread in terms of problems addressed in @xorpse 's fork (and/or mine)

Like https://github.com/koekeishiya/yabai/issues/923#issuecomment-856885054 adding that import (there or somewhere else) should definitely pare down the errors

EDIT: Also, all things being equal, I would prefer people use gist.github.com over pastebin cause of ads, etc. not a strong preference - but a preference

EDIT 2: Or like you may have seen me do above, Github supports use of the <details> tag - you just may have to add extra newlines to get the markdown parser to go back to normal markdown parsing (vs html tag parsing); or in the worst case, use <pre> inside it

[leftbones]

EDIT 2: Or like you may have seen me do above, Github supports use of the <details> tag - you just may have to add extra newlines to get the markdown parser to go back to normal markdown parsing (vs html tag parsing); or in the worst case, use \<pre\> inside it

I didn't know about those, thanks!

I added the import from #923, and have indeed narrowed down the errors:

> make -f makefile
rm -rf ./bin
clang ./src/osax/loader.m -shared -O2 -mmacosx-version-min=10.13 -o ./src/osax/loader -framework Foundation
clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -framework Foundation -framework Carbon
clang ./src/osax/mach_bootstrap.c -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/mach_bootstrap -framework Carbon -lpthread
./src/osax/mach_bootstrap.c:32:76: error: unknown register name '%rax' in asm
    for (;;) __asm__ __volatile__ ("movq %0, %%rax;" ::"r"(0x7961626169) : "%rax");
                                                                           ^
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

[mak1A4]

@donaldguy yup findings match, unfortunatly I'm still getting the error notification

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

I did move the binary after building, so I'm kinda stuck right now :-/

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

@evprkr I'm getting the same error when trying to build "the-future" branch

[leftbones]

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

I'm still getting the same error after running softwareupdate --install --all --force and downloaded the latest version of CLT

[HosAkh]

EDIT: Got it working :) the problem was that somehow I got the wrong version of Xcode Command Line Tools, had to update and now space switching works like a charm. Thanks for the support @donaldguy.

I'm still getting the same error after running softwareupdate --install --all --force and downloaded the latest version of CLT

I've been getting the same errors. I posted a question about it under Q&A (wasn't sure if it was something I was doing incorrectly).

I did all version of the software update for CLT and still get the same error message.

[mak1A4]

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

[leftbones]

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

This wasn't working for me yesterday, but today it is. Thanks I guess!

EDIT: Except I'm still getting the "reshuffling" issue I was having earlier.

[mak1A4]

@evprkr yesterday payload.m wasn't updated for 12.0.1RC that's why it wasn't working. Unfortunatly I can't really help you with the reshuffling issue :-/

[HosAkh]

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

[shaunsingh]

Is the the-future branch good for m1 Macs as well, or should I stick to donaldguy's fork? I don't need the SA, I just want to get rid of the window shuffling issue

[leftbones]

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

Just noticed I completely missed that step. I'm not really sure what it means though.

EDIT: Found the answer, the command is literally as typed. If you get an error saying the realpath command isn't found, run brew install coreutils

EDIT 2: After following the above instructions, it appears my issue is resolved!

[HosAkh]

@evprkr I didn't talk about the "the-future" branch, I got it working by compiling the repo of @donaldguy (Macbook Air M1, 12.0.1 RC (21A558))

git clone https://github.com/donaldguy/yabai/ make -j1 make sign mv ./bin/yabai $(realpath $(which yabai)) sudo yabai --install-sa sudo yabai --load-sa brew services start yabai brew services start skhd

dumb question...when you say $(realpath $(which yabai)) are you referring to the folder where I have the pulled branch in?

Just noticed I completely missed that step. I'm not really sure what it means though.

EDIT: Found the answer, the command is literally as typed. If you get an error saying the realpath command isn't found, run brew install coreutils

EDIT 2: After following the above instructions, it appears my issue is resolved!

I tried that command and this is the message that I'm getting:

mv ./bin/yabai $(realpath $(which yabai))
mv: /Users/my-user-name/.config/yabai/found is not a directory

So then I tried replacing realpath with copy pasting the directory's path to it and says permission denied even when I tried it withsudo`

zsh: permission denied: /Users/my-user-name/.config/yabai/yabai
usage: mv [-f | -i | -n] [-v] source target
       mv [-f | -i | -n] [-v] source ... directory

I tried it with mv -f as well but it still gave me the same error.

• did you try this with the the-future branch or the m1 branch
• did you try a specific folder or directory to install yabai in? I have tried this in my download and my .config/yabai folder. Both gave me the same results

Also thank you for all of your patience and assistance

[SamHep0803]

i've just installed @donaldguy's fork and its working brilliantly apart for the fact that for some reason, "official" Apple applications (i've seen it happen on Preview and the App Store so far) seem to stop responding to mouse and keyboard input immediately after a mouse scroll. As well as this you can only quit the application via Pkill.

I'm not too familiar with the yabai codebase/how it all works but I'd be completely happy to respond with any logs or anything.

[junwei-wang]

Anyone encounter the following error:

$ yabai                                                                                                             
could not locate the space to act on!
yabai configuration loaded..
fish: Job 1, 'yabai' terminated by signal SIGSEGV (Address boundary error)

Thanks in advance for your help.

[weizheheng]

I went through this thread and can't seem to find any working solutions for Intel mac. Tried to clone @donaldguy branch but couldn't get it to compile. Anyone has luck getting a workaround for yabai to run on Intel Mac with Monterey?

I have the yabai latest master version now, and some of the problems I am facing is similar to others:

1. Yabai restarts randomly causing the reshuffling (this happens a lot especially when I have the Books app opened, have to turned yabai off now)
2. Space/Desktop focusing does not work (falling back to Macbook built-in keyboard shortcut for desktop switching now).
3. Border not working (I can definitely live without this though)

🙏 Appreciate if anyone can point me to a workaround until we have a new release for Monterey support. So hard to live without a tiling manager.

[peppy]

@marcushwz can confirm all the issues you mention. have been living with these for months now. they aren't too bad, but definitely not optimal. note that borders do seem to be working, but are rendered beneath the window rather than above making them mostly hidden.

[donaldguy]

There are fixes for some things on my fork (and xorpse’s); it’s not just the SA offset updates

Check ‘em out if you want or don’t. There are also open PRs against upstream(s) for most of them

[HosAkh]

What's the eta for yabai intels based Monterey release? late November (assuming that's like November 20th)

[choco]

@koekeishiya FYI, the MISSION_CONTROL_ENTER event is not fired on macOS Monterey :( Hopefully they haven't restricted SLSRegisterConnectionNotifyProc completely...

[koekeishiya]

What's the eta for yabai intels based Monterey release? late November (assuming that's like November 20th)

Same as for the Apple Silicon version. My current mbp does not support Monterey. See https://github.com/koekeishiya/yabai/issues/725#issuecomment-949484389

[rpoovey]

@donaldguy, has this been tested on the M1 Pro/Max? I get the following when trying to compile. 12.0.1

 make -j1
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 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk" -framework Foundation
In file included from ./src/osax/loader.m:2:
In file included from ./src/osax/x86_64/loader.m:1:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
- (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
                                                         ~~~~~~~~~~~~~~                                                                       ^                  ~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
        #define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A)))
                                                      ^          ~
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

[donaldguy]

Nope, just got an M1 Air.

That doesn't look super in the weeds of arch specific stuff though, so I am a little surprised

it jumps out at me that the invocation is (hardcoded to) /Library/Developer/CommandLineTools/usr/bin/clang vs the invocation on the include path looking into SDK within /Applications/Xcode.app/Contents/Developer/

so I would maybe try upgrading one or both (e.g. softwareupdate --all --install --force) or normalizing to just CommandLineTools or just Xcode by changing SDK_PATH CLANG_PATH in the makefile and/or do sudo xcode-select --switch /Library/Developer/CommandLineTools

[donaldguy]

Oh well except there's a much bigger problem @rpoovey which is that its building ./src/osax/x86_64/loader.m at all

[donaldguy]

Can you try arch -arch arm64e make ?

[rpoovey]

@donaldguy

SDK_PATH: running the command xcrun --sdk macosx --show-sdk-path) returns /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Running sudo xcode-select --switch /Library/Developer/CommandLineTools and then make -j1 gives me

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
In file included from ./src/osax/loader.m:2:
./src/osax/x86_64/loader.m:1:9: fatal error: 'Foundation/Foundation.h' file not found
#import <Foundation/Foundation.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [src/osax/sa_loader.c] Error 1

Which is a bit different

arch -arch arm64e make yields the same output.

[donaldguy]

It still seems like you are ending up invoking Intel toolchain somewhere in the line, whether its clang or something further underneath

If you got here via a migration or a ~time machine restore, you might try nuking and reinstalling CLTs (sudo rm -rf /Library/Developer/CommandLineTools && sudo xcode-select --install) ; also make sure at least that your PATH has /opt/homebrew/bin before /usr/local/bin (not that any homebrew stuff should really be involved here), but maybe consider deleting (or moving out of place) any intel dev tools in /usr/local.

[rpoovey]

This was indeed from a migration. I removed intel based homebrew earlier today but didnt think about CLT. I'll run the removal and re-install and report back. Smart thinking.

[rpoovey]

@donaldguy. Good catch, that fixed it.

Thanks!

[vespakoen]

Just wanted to report that I am running @donaldguy's fork successfully on a M1 Pro & Monterey (12.0.1). The only problem I ran into is when window_border was set to on, it causes applications to hang, so this should be set to off for the time being.

Steps used where:

• Create the yabai-cert as outlined in this guide: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD)
• Do the dance: https://github.com/donaldguy/yabai/blob/canon/README-arm64.md

[choco]

While spending some time investigating changes in Monterey I stumbled upon a bunch of notifications that the Dock.app sends. I didn't see these documented anywhere, maybe they can be useful. Just need to register specifically for these:

• AXExposeExit: when exiting mission control
• AXExposeShowFrontWindows: when mission control has finished activating in show front windows mode
• AXExposeShowAllWindows: when mission control has finished activating in show all windows mode
• AXExposeShowDesktop: not sure when this is triggered
• AXLaunchpadShown: when launchpad has finished activating
• AXLaunchpadHidden: when launchpad is left

Unfortunately those are triggered at the end of the respective animation, so for example when activating mission control through the 4 finger gesture on the trackpad you won't get an immediate notification.

[donaldguy]

I added offsets for 12.1 beta 1 to my fork, but conditionalized so 12.0.1 should keep working; if there's a 12.0.2 I'm gonna need somebody else to do the update

https://github.com/donaldguy/yabai/commit/3fe15373d97475ce9b5d22ed65814beaf13f204d

[mak1A4]

@donaldguy I think I should be able to do it now :)

[sallar]

@donaldguy does your fork only work with M1? I tried cloning it on my Intel mac and it failed to compile.

[donaldguy]

@donaldguy does your fork only work with M1?

@sallar The consensus in the thread seems like no. I have been traveling these last two months and don't have a non-M1 mac with me to test or debug on (nor would I definitely do it if I did, but I might)

Sorry.

It seems like maybe people are having luck with the the-future branch here. To quickly slap something together ...

EDIT: ... I'd start from here if one is intent on getting my fork going on intel: https://github.com/donaldguy/yabai/tree/intel-maybe-probably-not

[marshall-mcmullen]

Thanks for the updated intel branch @donaldguy . I tried it out and hit a different compiler error due to an unterminated ifdef:

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
./src/osax/payload.m:208:2: error: unterminated conditional directive
#ifdef __arm64__
 ^
1 error generated.
make: *** [src/osax/sa_payload.c] Error 1

[LachlanGrant]

@marshall-mcmullen I've got a compiling version here: https://github.com/donaldguy/yabai/pull/1

[marshall-mcmullen]

@LachlanGrant -- thanks! I did indeed get past that compile error with your fork. Now I'm getting a different error though (on my intel based mac). Did you get this one?

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
as -o ./src/osax/arm64/sa_arm64e.o ./src/osax/arm64/sa_arm64e.s
./src/osax/arm64/sa_arm64e.s:5:13: error: unknown token in expression
sub sp, sp, #0x20
            ^

[LachlanGrant]

@marshall-mcmullen try running make clean and then make bin/yabai-x86_64 ... this will build only for intel

[marshall-mcmullen]

Thanks very much @LachlanGrant, that totally worked! Finally have it working again!

[weizheheng]

Thanks @LachlanGrant , got it working on my Intel machine as well.

@peppy , got it working without the restarting and random shuffling anymore. You might want to give the branch a shot.

@marshall-mcmullen , did you get the space switching work? I no longer get error when running

yabai -m space --focus 2

But it is not actually switching to the intended space.

Update after using for a few hours

• Mac WindowServer has been crashing randomly after switching to the branch above. Had to fall back to the master version now.