Apple Silicon M1

Placeholder to track support for Apple Silicon M1 at some point in the distant future.
Couple of things to be mentioned..

The scripting-addition obviously needs a full rewrite for the ARM architecture and I do not actually have hands on experience with any ARM processor. This should not be a blocker, but will take time as the Dock.app ARM binary needs to be reverse engineered in the same way we did the x86-64 version.
The master branch should now compile and run fine on Apple Silicon with Monterey 12.0.0 and 12.0.1.

As this project does not have any external dependencies with the exception of the C standard library and Apple frameworks, I would expect basic support  (read: compile and run) for Apple Silicon to work with close to no changes. Considering the performance differences between the models I am also interested in knowing if this will provide a noticeably better user experience when interacting with applications through the accessibility API, as yabai is doing, when managing windows.
The master branch should now compile and run fine on Apple Silicon with Monterey 12.0.0 and 12.0.1.

Feel free to discuss potential issues or post notable mentions in this issue.
If you are one of the people that have decided to get a first gen. M1 machine and are a developer, it would be great to see how yabai (or similar software) ends up running.
I'm undecided whether to get one of the new machines, or wait for further adjustments to their high-end machines.
Probably won't be getting one any time soon, so don't expect official support for some time.

Wow, so quick and nice!
Does this https://github.com/koekeishiya/yabai/commit/4410fef0fd272fc00a527f317351bb007bafe073 mean we can run script additions on M1 now?

I am getting one of ASi machines next week and enjoy reverse-engineering things(no experience with ARM though). Unfortunately, I have no idea about how yabai works under the covers. I will try to play with things for a bit though 👍

I don't even know if the method for code injection is still going to work on the M1, and I can't really verify anything as I don't have one. The above commits are mostly just future notes for myself for when I do end up buying one, or if other members in the community want to do the work required to support the M1.
I have made adjustments to the injection process that I believe should work on the M1. If it works; the current master should support things such a window borders, opacity, layers (sticky windows) and such, but none of the spaces functionality will work yet.

Can't build on M1, error in the attachment.
1.txt

Should be resolved now.

I have both yabai and skhd up and running on my m1.

So far so good! Here are a few small things I have noticed so far. Some of this might be my ignorance/configuration, but figured I would report it either way.
Screenshot of the first thing:

This one is likely me being dumb, but for some reason I felt like the borders worked fine even on windows with a border radius of sorts.
The second thing:
I am seeing borders on workspaces for windows that aren't there/are on other workspaces maybe?/are hidden? ... I'm not entirely sure what is causing that.
Note: I don't have the scripting additions up and running at all, but I am down to try and get it going as well.
Thanks for all your work on this!

Window borders require the scripting addition to work correctly. The current master should support this, but spaces functionality is not yet implemented for arm.

I've installed master, I can confirmed that borders are not working (still shows "failed to inject payload into Dock.app!"), but yabai -m window --space N works.

Can you post the output of the following commands:

Right, so it seems to me like it should be working fine. I'm probably just doing something wrong when setting up the thread state for arm64 here: https://github.com/koekeishiya/yabai/blob/master/src/osax/mach_loader.c#L100

Added a commit to master that will print the error; could you fetch that, compile and run sudo yabai --load-sa again and post the output?

sudo yabai --load-sa
could not spawn remote thread: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!

Hmm how about now? I don't think it should matter, but it is my last idea as of now.

Still the same.

@cxa Can you try the latest commit? clean, make and reinstall the scripting addition before finally trying to load it.

I installed latest commit with brew install koekeishiya/formulae/yabai --HEAD, this should be a clean rebuild? After that I run
sudo yabai --uninstall-sa
sudo yabai --install-sa
sudo yabai --load-sa

Unfortunately it was still the same result.

Hmm aight, I give up for now; I don't see what I'm doing wrong.

Thanks for your hard working! Wish you a good day.

This seems like it could be relevant for the M1: https://bazad.github.io/2018/10/bypassing-platform-binary-task-threads/

Good luck. I will a bit before buying a M1, and a working yabai is one of my requirement :)

Yabai appears to be working well for me on a new M1 MacBookPro with SIP disabled.  I haven't tried re-enabling SIP or partial SIP.

Just throwing this out there because I didn't see it mentioned but limelight works great on M1 macs as an interim solution.
Thanks for the incredible work on this, skhd, and limelight by the way.

Basic tiling is working well for me on an m1 MacBook Pro. I’m pretty happy
with it.
On Sun, Dec 13, 2020 at 20:03 Brandon Shockley<EMAIL_ADDRESS>wrote:

Just throwing this out there because I didn't see it mentioned but
limelight works great on M1 macs as an interim solution.
Thanks for the incredible work on this, skhd, and limelight by the way.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/725#issuecomment-744151093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABEOIB6VJGUKVJSUCTG7WOTSUWFBFANCNFSM4T2SNMWA
.

Basic tiling is working well for me on an m1 MacBook Pro. I’m pretty happy with it.
…
On Sun, Dec 13, 2020 at 20:03 Brandon Shockley @.***> wrote: Just throwing this out there because I didn't see it mentioned but limelight works great on M1 macs as an interim solution. Thanks for the incredible work on this, skhd, and limelight by the way. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#725 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEOIB6VJGUKVJSUCTG7WOTSUWFBFANCNFSM4T2SNMWA .

Limelight is just for window borders. https://github.com/koekeishiya/limelight it would work in conjunction with yabai. Sorry I should have been more clear.

Basic tiling, shadows, etc. are working well here (M1 MBP). I'm still receiving the error message that sa injection isn't working.
could not spawn remote thread: (os/kern) invalid argument
yabai: scripting-addition failed to inject payload into Dock.app!

Therefore jumping between desktops isn't working. I am able to move windows to different desktops, however.

Basic tiling, shadows, etc. are working well here (M1 MBP). I'm still receiving the error message that sa injection isn't working.
could not spawn remote thread: (os/kern) invalid argument
yabai: scripting-addition failed to inject payload into Dock.app!

Therefore jumping between desktops isn't working. I am able to move windows to different desktops, however. Just can't follow the window there haha

@ndom91 I received this message too, and I found the running yabai process is in Intel architecture shown in the Activity monitor. I guessed you install yabai without the --HEAD option, so you installed the prebuilt binary with x86 arch. I ran brew install yabai --HEAD and got an arm64 binary. This time, the error message becomes:
could not spawn remote thread: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!

hmm protection failure. Do you have the mac system integrity protection (SIP) disabled?
If not, you have to boot into recovery mode briefly and run some commands you'll find with a quick google

hmm protection failure. Do you have the mac system integrity protection (SIP) disabled?
If not, you have to boot into recovery mode briefly and run some commands you'll find with a quick google

@ndom91 I disabled the SIP following the instructions of the yabai wiki page. my csrutil status returns:
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: enabled
	Kernel Integrity Protections: disabled
	Authenticated Root Requirement: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Hi -
At least based on my experience & looking at the other ticket/thread, this is the current state of what happens with Yabai on the M1, even with SIP disabled.
Tony<EMAIL_ADDRESS>writes:

hmm protection failure. Do you have the mac system integrity protection
(SIP) disabled?

If not, you have to boot into recovery mode briefly and run some commands
you'll find with a quick google

@ndom91 I disabled the SIP following the instructions of the yabai wiki page. my
csrutil status returns:
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: enabled
BaseSystem Verification: enabled
Boot-arg Restrictions: enabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

I have some ideas of things to try, but I’m waiting to see if Apple is going to release a 14" mbp before I order one.
Sent from my iPhone
On 29 Dec 2020, at 17:02, jonathanwilner<EMAIL_ADDRESS>wrote:

Hi -
At least based on my experience & looking at the other ticket/thread, this is the current state of what happens with Yabai on the M1, even with SIP disabled.
Tony<EMAIL_ADDRESS>writes:

hmm protection failure. Do you have the mac system integrity protection
(SIP) disabled?
If not, you have to boot into recovery mode briefly and run some commands
you'll find with a quick google
@ndom91 I disabled the SIP following the instructions of the yabai wiki page. my
csrutil status returns:
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: enabled
BaseSystem Verification: enabled
Boot-arg Restrictions: enabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/koekeishiya/yabai/issues/725#issuecomment-752136049, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPDZVYXNBFVQKFAOHDHNTTSXH4QVANCNFSM4T2SNMWA.

yabai wiki page

hmm protection failure. Do you have the mac system integrity protection (SIP) disabled?
If not, you have to boot into recovery mode briefly and run some commands you'll find with a quick google

@ndom91 I disabled the SIP following the instructions of the yabai wiki page. my csrutil status returns:
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled
	BaseSystem Verification: enabled
	Boot-arg Restrictions: enabled
	Kernel Integrity Protections: disabled
	Authenticated Root Requirement: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

It looks like there are still many SIP options still enabled. I have my SIP completely disabled and I do not see this error (although Yabai definitely still isn't working 100% on M1 even with SIP completely disabled).
They mentioned a few different variations of the command based upon which version of Mac OS you're running:
# If you're on macOS 11.0.1
# Requires Filesystem Protections and Debugging Restrictions to be disabled (workaround because --without debug does not work)
# (printed warning can be safely ignored)
csrutil disable --with kext --with dtrace --with nvram --with basesystem

# If you're on macOS 10.14 and 10.15
# Requires Filesystem Protections and Debugging Restrictions to be disabled
# (printed warning can be safely ignored)
csrutil enable --without debug --without fs

# If you're on macOS 10.13
# (disables SIP completely)
csrutil disable

with csrutil disable you'll get everything turned off

I have both yabai and skhd up and running on my m1.

So far so good! Here are a few small things I have noticed so far. Some of this might be my ignorance/configuration, but figured I would report it either way.
Screenshot of the first thing:

This one is likely me being dumb, but for some reason I felt like the borders worked fine even on windows with a border radius of sorts.
The second thing:
I am seeing borders on workspaces for windows that aren't there/are on other workspaces maybe?/are hidden? ... I'm not entirely sure what is causing that.
Note: I don't have the scripting additions up and running at all, but I am down to try and get it going as well.
Thanks for all your work on this!

quick question: how are you grabbing an am64 version of yabai? Currently when i run brew install yabai I am receiving an x86_64 version

I have both yabai and skhd up and running on my m1.

So far so good! Here are a few small things I have noticed so far. Some of this might be my ignorance/configuration, but figured I would report it either way.
Screenshot of the first thing:

This one is likely me being dumb, but for some reason I felt like the borders worked fine even on windows with a border radius of sorts.
The second thing:
I am seeing borders on workspaces for windows that aren't there/are on other workspaces maybe?/are hidden? ... I'm not entirely sure what is causing that.
Note: I don't have the scripting additions up and running at all, but I am down to try and get it going as well.
Thanks for all your work on this!

quick question: how are you grabbing an am64 version of yabai? Currently when i run brew install yabai I am receiving an x86_64 version

I’m waiting to see if Apple is going to release a 14" mbp before I order one.

Same here. Sounds promising with the new leaks.

I’m waiting to see if Apple is going to release a 14" mbp before I order one.

Same here. Sounds promising with the new leaks.

Is there any update to the could not spawn remote thread: (os/kern) protection failure error from running sudo yabai --load-sa on the macbook pro ARM cores?
From reading the discussion, it seems like the scripts add additional functionality but the basic functionalities work?

Is there any update to the could not spawn remote thread: (os/kern) protection failure error from running sudo yabai --load-sa on the macbook pro ARM cores?
From reading the discussion, it seems like the scripts add additional functionality but the basic functionalities work?

I just got my M1 and am trying to move this issue forward, I get the same error as the parent here, asked around on IRC and got this interesting link:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Looks like there are a bunch of new protections at play here, and it will probably be more difficult to get this to work on the M1 as far as I can tell.
Hope i'll be proven wrong =)

I just got my M1 and am trying to move this issue forward, I get the same error as the parent here, asked around on IRC and got this interesting link:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Looks like there are a bunch of new protections at play here, and it will probably be more difficult to get this to work on the M1 as far as I can tell.
Hope i'll be proven wrong =)

I think it is a problem with installation of the scripting addition. Not the loading part. No errors appear in my system logs when I do --load-sa, but with --install-sa a bunch of messages appear in my logs. Most also appear with killall dock (no scripting addition) with one exception:
fout	12:06:56.067133+0100	kernel	Sandbox: logd_helper(341) deny(1) file-read-data /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap

$ ls -l /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap
-rw-r--r--  1 root  wheel  50555 Jan 30 12:19 /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap

$ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap: Mach-O 64-bit dynamically linked shared library arm64

Let me know if I can help with testing anything.

I think it is a problem with installation of the scripting addition. Not the loading part. No errors appear in my system logs when I do --load-sa, but with --install-sa a bunch of messages appear in my logs. Most also appear with killall dock (no scripting addition) with one exception:
fout	12:06:56.067133+0100	kernel	Sandbox: logd_helper(341) deny(1) file-read-data /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap

$ ls -l /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap
-rw-r--r--  1 root  wheel  50555 Jan 30 12:19 /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap

$ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_bootstrap: Mach-O 64-bit dynamically linked shared library arm64

Let me know if I can help with testing anything.

I don't know specifically what the problem is, and will resume working on this in Q3 2021 when I can get a 14" mbp.

I don't know specifically what the problem is, and will resume working on this in Q3 2021 when I can get a 14" mbp.

Is there anything we with m1 hardware can do to help out? On top of becoming a patreon?

The first step of this issue at the moment that needs to be solved is how to successfully load a shared library inside a system process (e.g Dock.app) on the M1. This is not something I can work on without physical access to an M1 machine as it is an iterative process where I'd have to attempt some stuff, observe the result and/or errors that occur -> attempt some new stuff (repeat the process).
For now my assumption is that thread_create_running has additional security checks on the M1, similar to the iOS, causing the protection failure message seen above.

If you can do it in a M1 on Scaleway https://www.scaleway.com/en/hello-m1/, I'm sure we can sponsor it for you.

This may be incorrect, but I assume  that a service such as scaleway would not let me mess with SIP, AMFI, and other security mechanisms.

@koekeishiya I can give you access to my M1, it has SIP disabled and XCode installed, ping me at koen at schmeets.de

I just bought a mac mini M1 and want to better understand how this software works, so let me know how I can help.

@koekeishiya I can give you access to my M1, it has SIP disabled and XCode installed, ping me at koen at schmeets.de

There is a real Lord of the rings vibe coming here...
But yeah, I literally just took my MacBook air m1 out of the box, I can throw vnc on it (or whatever) and you can dork around with it for a weekend or a few days or what not.

I appreciate the offers, but I think I'd rather wait til I get one later this year. I'm not particularly active for the time being either way.
Sent from my iPhone

Had a quick read of the messages above, but would still like to confirm.
Getting the message even with SIP disabled
could not spawn remote thread: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!
However, I saw someone above managed to get it working. Does this mean at current state there's no way to get changing desktop? Currently only basic yabai functionality is working

Had a quick read of the messages above, but would still like to confirm.
Getting the message even with SIP disabled
could not spawn remote thread: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!
However, I saw someone above managed to get it working. Does this mean at current state there's no way to get changing desktop? Currently only basic yabai functionality is working

Thats right, yabai works but not the scripting additions.

Is there any workaround for switching spaces with skhd without the scripting additions library? It's one of my favorite features of Yabai.

Is there any workaround for switching spaces with skhd without the scripting additions library? It's one of my favorite features of Yabai.

I'm already doing this without yabai. in the keyboard shortcuts settings you can define custom shortcuts to jump to the next/previous space and also to directly jump to a specific index.
I'm pretty new to MacOs so there must be some gotchas that I don't know 😝

Is there any workaround for switching spaces with skhd without the scripting additions library? It's one of my favorite features of Yabai.
An idea that comes to mind is an AppleScript, but I haven't figured it out yet.

I created a shell script that seems to work okay
# Move Spaces
    move_spaces()
        {
            CURRENT_SPACE=$(yabai -m query --spaces| jq '[.[]|select(.focused==1)][0].index')
            TOTAL_SPACES=$(yabai -m query --spaces| jq '. | length')
            DESIRED_SPACE=$1
            echo $((CURRENT_SPACE - DESIRED_SPACE))
            echo Curent Space $CURRENT_SPACE Desired Space $DESIRED_SPACE Total Spaces $TOTAL_SPACES

            if [ $DESIRED_SPACE -lt $CURRENT_SPACE  ]; then
                echo 1
                n=0
                while [ "$n" -lt  $((CURRENT_SPACE - DESIRED_SPACE)) ]; do
                    osascript -e "tell application \"System Events\" to key code 123 using control down"
                    n=$(( n + 1 ))
                done
            fi

                if [ $DESIRED_SPACE -gt $CURRENT_SPACE  ]; then
                    n=0

                    while [ "$n" -lt $((DESIRED_SPACE - CURRENT_SPACE)) ]; do
                        osascript -e "tell application \"System Events\" to key code 124 using control down"
                        n=$(( n + 1 ))
                    done
            fi
        }

move_spaces $1

Call it with mspace NUMBER_OF_SPACES in skhd
You can also create spaces with
        create_spaces()
        {
            spaces=$(($1-$(yabai -m query --spaces | grep -c "id")+$(yabai -m query --spaces | grep -c '"native-fullscreen":1')-1))
            echo $spaces
            i=0
            while [ $i -le $spaces ]; do
            echo $i
            open -a "Mission Control"
            osascript -e 'tell application "System Events" to click button 1 of group "Spaces Bar" of group 1 of group "Mission Control" of process "Dock"'
            open -a "Mission Control"
            i=$(($i+1))
            done
        }

create_spaces $1

Creating spaces isn't exactly pretty. But for me I generally keep 5 spaces so I runs once at launch and that's it, which makes it tolerable for me.

Is there a way someone could sign up to get an alert when scripting is working for the M1?

Is there any workaround for switching spaces with skhd without the scripting additions library? It's one of my favorite features of Yabai.
An idea that comes to mind is an AppleScript, but I haven't figured it out yet.

You can switch spaces even without skhd or any script.
A simple alternative would be to use shortcuts to change desktop.
System Preferences --> Keyboard --> Shortcuts --> Toggle "Switch to Deskttop 1/2/3/4"
After that all you have to do is to  +  to swap to a particular desktop

@haley-yung thanks! This is exactly what I was looking for!
To recreate my previous setup, since all my skhd commands are bound to alt, do the following:

Remove alt - [1-6] commands in ~/.skhdrc
Restart skhd with brew services restart skhd
Go to System Preferences --> Keyboard --> Shortcuts --> Mission Control
Check shortcut Switch to Desktop [1-6]
Highlight a shortcut (ex: "Switch to Desktop 1")
Click on the right column over the keyboard shortcut (an input should appear)
Type the keyboard shortcut you want to use for that command (ex: "alt - 1")
Repeat steps 4-7 for all shortcuts you want.

Here is what I set mine too:

Screenshot macOS Big Sur Version 11.2.1 (20D74)

@jonashaag @haley-yung Thanks for this. Does anyone know how to remove the fade-in animation when you move between desktops?

@jonashaag @haley-yung Does anyone know how to remove the fade-in animation when you move between desktops when reduce motion is activated?

defaults write com.apple.dock workspaces-swoosh-animation-off -bool YES should do the trick. Still the ugly 1s delay, but no swoosh animation

When building from HEAD, the vertical gaps/padding seem to be shrunk inconsistently. So windows might tile with the edges overlapping. This doesn't seem to be an issue with the regular homebrew (x86) version.
I am not really sure what I could do to troubleshoot this and be more helpful I'm afraid.

When building from HEAD, the vertical gaps/padding seem to be shrunk inconsistently. So windows might tile with the edges overlapping. This doesn't seem to be an issue with the regular homebrew (x86) version.
I am not really sure what I could do to troubleshoot this and be more helpful I'm afraid.

I can't reproduce this. just recently build from HEAD. do you have screenshots?

just to have it explicitly:
current state of yabai on M1 is that the window tiling works, but due to an issue with install-sa or load-sa its not possible to switch windows.
correct?

@FinnFrotscher I think only the features requiring SIP disabled do not work. The list is here https://github.com/koekeishiya/yabai/wiki/Disabling-System-Integrity-Protection. So switching windows should not be affected.

Hey, just heard about Yabai because I asked this question on AskDifferent and an answer mentioned that I should use it:
https://apple.stackexchange.com/questions/416429/is-there-a-way-to-switch-virtual-desktops-on-my-monitors-simultaneously?noredirect=1#comment584226_416429
However, I have an M1 Mac and the marked answer suggests that I might have to disable SIP for it to work. @yanzhang0219 just said that "the features requiring SIP disabled do not work" on M1 Macs. Is that correct? Or do you think the feature I am looking for would also work without disabling SIP?
Would appreciate any help and will share the info on AskDifferent.

@MikhailRatner interesting idea of switching desktops at the same time.
I believe you can do something like this when M1 is properly supported, as of right now Yabai can't switch desktops on the M1 (even with SIP disabled).
Once it's working again I'm curious to see what solution you come up with.

When building from HEAD, the vertical gaps/padding seem to be shrunk inconsistently. So windows might tile with the edges overlapping. This doesn't seem to be an issue with the regular homebrew (x86) version.
I am not really sure what I could do to troubleshoot this and be more helpful I'm afraid.

I can't reproduce this. just recently build from HEAD. do you have screenshots?

Here are the screenshots, first with the prebuilt binary and the second with the compiled ARM64 version.

This window overlap does happen with other apps too and yes they don't overlap with a high padding value (e.g. over 10) but the padding is still much closer vertically.

Im still getting error on Mac Mini M1 (11.2.3). How to make it work?
❯ sudo yabai --install-sa

sudo: unable to execute /opt/homebrew/bin/yabai: Bad CPU type in executable

@anhthang I don't think you can use the scripting extension on M1 yet. Please correct me if I'm wrong.

@anhthang I don't think you can use the scripting extension on M1 yet. Please correct me if I'm wrong.

yes, im just following the instruction, it's installing the stable version, i think

@anhthang I don't think you can use the scripting extension on M1 yet. Please correct me if I'm wrong.

yes, im just following the instruction, it's installing the stable version, i think

The stable version is only compiled for Intel and runs through rosetta, afaik. The HEAD version runs into a kernel protection and fails to load (at least for me).

@koekeishiya for how long will this be status quo?

Anyone's focus follows mouse stop working entirely? The only change I'm aware of was running brew update; brew upgrade.

Is there any progress on getting M1 macs working? This hasn't been updated in some time.

If this doesn't work in M1 Macs, can you please at least mention this in the wiki during installation parts?
It absolutely sucks as a new user to go through the hassle of disabling SIP, go through installation and other things only to find out after a bit of searching and eventually reaching here that M1 Macs aren't supported. This information should be in the wiki to start with.
$ sudo yabai --load-sa
could not spawn remote thread: (os/kern) invalid argument
yabai: scripting-addition failed to inject payload into Dock.app!

Hmm I'm going through the process of installing it right now. I hope it works

:( same issue yabai: scripting-addition failed to inject payload into Dock.app! on HEAD

:( same issue yabai: scripting-addition failed to inject payload into Dock.app! on HEAD

Yabai can't work on M1 right now because the scripting addition works by injecting assembly code directly into the running Dock process. That assembly is currently made only for x86-64 processors like the Intel ones. M1 needs ARM assembly code which isn't yet present in Yabai because Åsmund doesn't have an M1 machine to compile and test on.
To get yabai working on M1 needs a lot of trial and error and coffee and swearing at the gods of the Darwin kernel because there's a new protection in place which doesn't allow injection as easily as it worked on Intel.
So the solutions are:

Try to learn some basic ARM assembly, compile the scripting addition on your ARM machine and then see what @koekeishiya has mentioned about the task ports vulnerability which might help us get the bytecode injected
Support the author of yabai who at the moment is making a measly $175/m for his tremendous work on yabai https://www.patreon.com/aasvi

We already know yabai doesn't work on M1 and won't work no matter how hard you try to run sudo yabai --install-sa so we should refrain from sending messages like not working for me either.

:( same issue yabai: scripting-addition failed to inject payload into Dock.app! on HEAD

Yabai can't work on M1 right now because the scripting addition works by injecting assembly code directly into the running Dock process. That assembly is currently made only for x86-64 processors like the Intel ones. M1 needs ARM assembly code which isn't yet present in Yabai because Åsmund doesn't have an M1 machine to compile and test on.

Oh I see, I now understand. Thanks

To get yabai working on M1 needs a lot of trial and error and coffee and swearing at the gods of the Darwin kernel because there's a new protection in place which doesn't allow injection as easily as it worked on Intel.

🤣

So the solutions are:
* Try to learn some basic ARM assembly, compile the scripting addition on your ARM machine and then see what @koekeishiya has mentioned about the task ports vulnerability which might help us get the bytecode injected

I'll try to explore that. tbh, I came from dwm, and having to use the mouse kills me and makes me hate the day I bought macbook

* Support the author of yabai who at the moment is making a measly $175/m for his tremendous work on yabai https://www.patreon.com/aasvi

definitely well do, thanks for the link

We already know yabai doesn't work on M1 and won't work no matter how hard you try to run sudo yabai --install-sa so we should refrain from sending messages like not working for me either.

👍

It’s been working for me for months including most of the config. I don’t know why it’s been repeated that it doesn’t work if directions were followed. Before I mentioned that focus follows mouse stopped working, it’s working again randomly. M1 is still buggy as heck. My monitors sometimes don’t receive RGB signals messing up calibration. So for the impatient please consider that as well, Apple still has a some way to go.
Can someone send him an M1?

It’s been working for me for months including most of the config. I don’t know why it’s been repeated that it doesn’t work if directions were followed. Before I mentioned that focus follows mouse stopped working, it’s working again randomly. M1 is still buggy as heck. My monitors sometimes don’t receive RGB signals messing up calibration. So for the impatient please consider that as well, Apple still has some way to go.
What’s the usual method of opening arm binaries? 1. Open package contents, find binaries, open in an editor? Do I need an extension for vscode/vim?

@carlosvigil the scripting addition and the features added by it don't work on M1. The rest of yabai does work.
If you want instant space switching, window shadow removal, Picture-in-Picture for all windows and other useful features, you need the scripting addition. You probably didn't use these features, that's why you don't notice them missing.

Thanks. Then, certain features aren't working.
Anyways, I tried peering into the problem and in case anyone else was curious you can start by:

Downloading Hopper Disassembler or some other app like it
Use it to open /System/Library/CoreServices/Dock.app/Contents/MacOS/Dock
For loader I left it at FAT, but changed the archive option to AArch64
Look for whatever represents these https://github.com/koekeishiya/yabai/blob/master/src/osax/x86_64/payload.m

Disclaimer: I don't know 90% of what's going on.

@carlosvigil, it is not the problem of finding function pointers. It is problem at injecting to the process (Dock).
Basically I am guessing it is related to PAC features of arm64e. [0]
Basically creating new thread on Dock process is ok, but setting state is the problematic part.
[0] https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

Thanks. Then, certain features aren't working.

Does auto-tailing works at least?, are you using 11.13?

Thanks. Then, certain features aren't working.

Does auto-tailing works at least?, are you using 11.13?

Yes, auto tiling works, that doesn't need the scripting addition. It works on every macOS version and on both M1 and Intel Macs.
And yes, I'm using the latest 11.3 Big Sur

Oh god, this is the main thing I need right now. Thanks @alin23 , I'm going to try one more time to setup yabai.

@koekeishiya I've managed to get scripting additions working on the M1.
Unfortunately, the approach I took is "quick and dirty" and very much a WIP, hence I include the following instructions, rather than a pull request.
A repository containing my WIP can be found here: https://github.com/xorpse/yabai/commit/04255f7cd6b3c3a2f211dc26deba41273b11ed9c.
Extending the payload to fully support arm64
For Dock on 11.3.1, I identified the following addresses for function pointers and ids:
// ids
const uint64_t dppm_addr = 0x100426550ULL;
const uint64_t dock_spaces_addr = 0x1004264D0ULL;

// functions
const uint64_t add_space_addr = 0x100225DE0ULL;
const uint64_t remove_space_addr = 0x1002D6A58ULL;
const uint64_t move_space_addr = 0x1002C8ED0ULL;
const uint64_t set_front_window_addr = 0x10004FBD8ULL;

Note that the id addresses correspond to pointers to ids, rather than code locations as in the x86-64 payload.
I used the following wrappers to call "add space" and "move space":
static void asm__call_add_space(id new_space, id display_space, void(*fptr)(void)) {
    __asm__ __volatile__(
        "mov x0, %0\n"
        "mov x20, %1\n"
        ::
        "r"(new_space),
        "r"(display_space)
        : "x0", "x20");
    fptr();
}

static void asm__call_move_space(id source_space, id dest_space, CFStringRef dest_display_uuid, id dock_spaces, void(*fptr)(void)) {
    __asm__ __volatile__(
        "mov x0, %0\n"
        "mov x1, %1\n"
        "mov x2, %2\n"
        "mov x20, %3\n"
        ::
        "r"(source_space),
        "r"(dest_space),
        "r"(dest_display_uuid),
        "r"(dock_spaces)
        : "x0", "x1", "x2", "x20");
    fptr();
}

To add support for pointer authentication in the payload, I signed all function pointers using:
ptrauth_sign_unauthenticated(fptr, ptrauth_key_asia, 0)

Finally, I altered the makefile to build the payload for arm64e and made sure it was not removed after compilation.
Injecting the payload
To inject the payload, I was able to use frida*. The following script emulates the existing loader implemented for x86-64:
function loadYabaiSA(sa_path) {
  var RTLD_NOW = 0x02;
  var _dlopen = new NativeFunction(Module.findExportByName(null, "dlopen"), 'pointer', ['pointer', 'int']);

  var path = Memory.allocUtf8String(sa_path);
  var handle = _dlopen(path, RTLD_NOW);
  if (handle.isNull()) {
    console.error("[e] failed to load scripting addition payload");
    return
  }

  // some debug to make sure things are working
  var _image_slide = new NativeFunction(Module.findExportByName(sa_path, "image_slide"), 'uint64', []);
  var _static_base_addr = new NativeFunction(Module.findExportByName(sa_path, "static_base_address"), 'uint64', []);

  console.log("[i] image_slide: ", _image_slide().toString(16));
  console.log("[i] static_base_addr: ", _static_base_addr().toString(16));
}

// path to scripting additions payload (compiled for arm64e(!))
var sa_path = "/path/to/yabai/src/osax/payload";
loadYabaiSA(sa_path);

The script can be launched using:
frida Dock -q -l install-yabai-sa.js

Note: to get frida to work, I had to compile from source, disable SIP and add -arm64e_preview_abi to my boot arguments.
I hope these instructions will prove useful :).

@xorpse Just to be sure: Window opacity works on the M1?
Maybe they will present something tomorrow wich is worth buying :-)

@24unix yes, from my testing, everything works (opacity, borders, spaces, etc., etc.). See below:

Thx. Opacity is the main reason I use yabai :-)

Works for me!! awesome! thank you so much!
I didn't have to compile frida from source, just got the latest one from pip:
pip3 install frida-tools
git clone https://github.com/xorpse/yabai.git yabai-m1
cd yabai-m1
make
sudo services yabai stop
./bin/yabai
# open new tab
frida Dock -q -l install-yabai-sa.js

I also removed the Switch to desktop NUM shortcuts in the System Preferences and added them back in my .skhdrc and instant space switching works again (thing I missed the most from the scripting additions)
I hope we can figure out a way to make the mach_loader in yabai work again so we don't need frida anymore.
Anyways, thanks so much for figuring this out! It's going to save me a lot of time and sanity!

@vespakoen If you're able to upload the 11.4 version of Dock somewhere I can provide updates to the offsets.
I used IDA Pro to perform the reverse engineering. The snippets in the comments correspond to code in Dock that can be used to help locate the offsets in later versions.
I'm happy to share the annotated IDA database I have, if it would be useful (e.g. to diff Dock between versions). Otherwise, I suspect the next steps we should take are to revert to the offset/pattern approach taken for x86 (which shouldn't be much work), and hope that it's more robust.
In regards to Frida, I agree, it's a bit unfortunate. I took a look at altering the existing loader and managed to inject into the dock, but it crashed almost immediately due to pointer authentication issues.

@xorpse I've uploaded it here: https://static.alinpanaitiu.com/Dock.zip
I'd also like to take a look at the offsets after you post them, to see what they correspond to so I can do this myself next time ^_^

Works for me!! awesome! thank you so much!
I didn't have to compile frida from source, just got the latest one from pip:
sudo nvram boot-args=-arm64e_preview_abi

# reboot computer (and disable SIP if it is not already disabled)

pip3 install frida-tools
git clone https://github.com/xorpse/yabai.git yabai-m1
cd yabai-m1
make
sudo services yabai stop
./bin/yabai

# open new tab
# edit the  `sa_path` variable at the bottom of install-yabai-sa.js (mine changed to: `/Users/koen/Projects/yabai-m1/src/osax/payload`)

frida Dock -q -l install-yabai-sa.js

No luck with these instructions:
when using frida I get this:
frida Dock -q -l install-yabai-sa.js

Failed to attach: unexpected error while starting thread (set_thread_state returned '(os/kern) protection failure'

I disabled SIP with
csrutil disable --with kext --with dtrace --with nvram --with basesystem
OS is 11.2.2 (20D80)

@stackpivot the current code only works on 11.3.1
@xorpse I'd love to take a look at that IDA database if you could share it.

I've pushed new offsets for 11.4.
@alin23 thanks for uploading the latest Dock. I've uploaded the IDA database for 11.4 here:

https://fugue.kr/reveng/macos/Dock/11.4/Dock.i64

The ID pointers are g_dppm and g_dock_spaces_ptr. The functions are:

getAddSpaceOffset
getMoveSpaceOffset
getRemoveSpaceOffset
getSetFrontWindowOffset

I've also uploaded two Diaphora databases that you can use for diffing.

https://fugue.kr/reveng/macos/Dock/11.3.1/Dock.sqlite
https://fugue.kr/reveng/macos/Dock/11.4/Dock.sqlite

Thanks xorpse! that works for me on 11.4 =)

Beautiful. It's working for me after I upgraded to 11.4.
Thanks so much @xorpse. Your efforts and the fact that you shared them here are much appreciated.

Is it possible this fix gets "merged" into the main brach?
Really missing using yabai in my m1?

Yes thank you very much @xorpse. I don't suppose anyone can help me with removing the window shadows?
I'm also running into the window alignment issue again with this version.

Thanks so much @xorpse! Been lurking this issue for months.
What's the best way to run this on login? Should I create a launchctl daemon or is there a smarter/cleaner way?

@rlch @vespakoen
If you check out the latest commit (i.e., https://github.com/xorpse/yabai/commit/867c57ad9976696a02263b2018cd00e0b5cdfee7), I've integrated a loader based on frida-core into yabai itself, so now yabai --load-sa and yabai --install-sa should work as before.
You'll have to build using make -f makefile.arm64; make -f makefile.arm64 sign, which should take care of everything (no need to install Frida now). Most of the instructions in the wiki should work exactly as described to get yabai running on login (after changing the path to your yabai binary).

How I missed this! It works perfectly, and the installation process is as smooth as before. Thanks a lot @xorpse !!
Too bad we miss the ability to run iOS apps when disabling SIP completely. I couldn't find the right csrutil configuration to allow yabai and frida and still keep the ability to run iOS apps.

Thanks for sharing @xorpse.
I tried also to install yabai on a mac m1, I updated to 11.4 but I face some problems.
I disabled System Integrity protection :
csrutil disable --with kext --with dtrace --with nvram --with basesystem
I probably also did: sudo nvram boot-args=-arm64e_preview_abi
because nvram -p | grep boot-args answer me : boot-args	-arm64e_preview_abi
When I type csrutil status :
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: enabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

I cloned your repository https://github.com/xorpse/yabai
Created the certificate following : https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD)
then editing sa-path in install-yabai-sa.js (not sure it is useful)
then run make -f makefile.arm64; make -f makefile.arm64 sign
then went to the bin
sudo ./yabai --install-sa which seems to works because it's reloading my dock
then sudo ./yabai --load-sa but I got this error [e] failed to establish session: Unexpected error while starting thread (set_thread_state returned '(os/kern) protection failure') [1]    4171 segmentation fault  sudo ./yabai --load-sa

@leglopy I think nvram restrictions need to be disabled.
So instead of csrutil disable --with kext --with dtrace --with nvram --with basesystem try csrutil disable --with kext --with dtrace --with basesystem

Thanks for quick response and your help @alin23 it is working with nvram disabled csrutil disable --with kext --with dtrace --with basesystem.
By the way, is there is a possibility to enable again System Integrity Protection after installation ? I guess not as we need to load the script every time on startup

@alin23 thanks for clarifying the requirements for disabling SIP (previously I'd completely disabled it and not tested any other configurations).
I've updated the arm64 specific README to explicitly state the extra requirements.

Hi! Reading the threads I followed the steps in this order:

Disabled SIP and did sudo nvram boot-args=-arm64e_preview_abi
Created a certificate following steps here
Added the yabai executable under accessibility
git cloned git clone https://github.com/xorpse/yabai.git yabai-m1
Ran make -f makefile.arm64; make -f makefile.arm64 sign
Ran yabai --install-sa and sudo yabai --load-sa ( in that order)

I haven't gotten an error in any of these steps, but I am not sure how to start and stop yabai since it was aliased from a repository that was cloned (can't use brew services).
When i just execute the binary, I get:

Even though it is checked under accessibility.

Also, if I follow these steps do I have to also install skhd for the scripting additions in a similar manner or can I follow the wiki there?

@bkbranden what I did is install yabai through brew (simple brew install yabai, no --HEAD or -s) and then build and replace only the binary so that I can take advantage of brew services (and brew upgrade when yabai gets updated on Github).
Here is the script I'm using from the yabai repo after a brew install yabai:
export yabai_bin=$(realpath $(which yabai))                       # Get yabai binary real path, not a symlink
make -f makefile.arm64 && make -f makefile.arm64 sign && \        # Build and sign yabai
sudo chflags noschg $yabai_bin && sudo chmod 777 $yabai_bin && \  # Make sure the yabai binary is mutable
sudo rm $yabai_bin && sudo cp bin/yabai $yabai_bin && \           # Replace the current yabai binary with the newly built one
sudo chmod 555 $yabai_bin && sudo chflags schg $yabai_bin && \    # Make the yabai binary immutable so that brew upgrade can't replace it unknowingly
sudo yabai --install-sa && sudo yabai --load-sa && \              # Install and load scripting addition
brew services restart yabai                                       # Start yabai

When I run make -f makefile.arm64; make -f makefile.arm64 sign in ~/yabai-m1 I get the following error:
> make -f makefile.arm64; make -f makefile.arm64 sign
rm -rf ./bin
mkdir -p ./frida
curl -L -o ./frida/devkit.tar.xz https://github.com/frida/frida/releases/download/14.2.18/frida-core-devkit-14.2.18-macos-arm64.tar.xz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   648  100   648    0     0    974      0 --:--:-- --:--:-- --:--:--   972
100 33.8M  100 33.8M    0     0  4459k      0  0:00:07  0:00:07 --:--:-- 6379k
tar xJf ./frida/devkit.tar.xz -C ./frida
rm ./frida/frida-core-example.c ./frida/devkit.tar.xz
clang -c ./src/osax/arm64/injector.c -o ./src/osax/arm64/injector.o -I./frida -isysroot "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk"
clang ./src/osax/payload.m -shared -fPIC -O2 -mmacosx-version-min=10.13 -o ./src/osax/payload -arch arm64e -framework Foundation -framework Carbon
xxd -i -a ./src/osax/payload ./src/osax/sa_payload.c
rm -f ./src/osax/payload
mkdir -p ./bin
clang src/manifest.m src/osax/arm64/injector.o src/osax/sa_payload.c -std=c99 -Wall -fPIC -g -O0 -fvisibility=hidden -mmacosx-version-min=10.13 -L./frida -lfrida-core -lbsm -lm -ldl -lpthread -lresolv -Wl,-framework,Foundation,-framework,AppKit -pthread -isysroot "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk" -Wl,-dead_strip -F/System/Library/PrivateFrameworks -framework Carbon -framework Cocoa -framework CoreServices -framework SkyLight -framework ScriptingBridge -o bin/yabai
ld: warning: object file (src/osax/arm64/injector.o) was built for newer macOS version (11.0) than being linked (10.13)
ld: warning: ignoring file ./frida/libfrida-core.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture x86_64:
  "___src_osax_mach_bootstrap", referenced from:
      _scripting_addition_install in manifest-6bb809.o
  "___src_osax_mach_bootstrap_len", referenced from:
      _scripting_addition_install in manifest-6bb809.o
  "___src_osax_loader", referenced from:
      _scripting_addition_install in manifest-6bb809.o
  "___src_osax_loader_len", referenced from:
      _scripting_addition_install in manifest-6bb809.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [bin/yabai] Error 1
codesign -fs "yabai-cert" ./bin/yabai
./bin/yabai: No such file or directory
make: *** [sign] Error 1

any ideas @xorpse ?
I've ran csrutil disable and sudo nvram boot-args=-arm64e_preview_abi + rebooted but still get the issue. I'm running GNU Make 3.81 and MacOS 11.4

@rlch
Looks like your clang binary is x86_64 (or maybe your terminal?).
Check where clang is executed from using which clang and realpath $(which clang) and make sure it's not an x86_64 binary using lipo -archs $(realpath $(which clang))
If it isn't (it could be a universal binary containing both arm64 and x86_64), then make sure you haven't opened the Terminal or shell using Rosetta.

@alin23
clang is being executed from /usr/bin/clang and the architecture is:
❯ lipo -archs $(realpath $(which clang))
x86_64 arm64e

Seems like you're right -- how could i disable x86_64? I tried doing some research but feel pretty unsafe tinkering with stuff I don't fully comprehend.
Can confirm my terminal isn't using Rosetta

It's normal for /usr/bin/clang to be universal. You don't have to disable x86, you just have to make sure you're not running from Rosetta.
Basically, any x86 process running through Rosetta, will also run its children processes also as x86.
So for example if make is strictly x86, then any process that make will spawn will be x86.
Try checking make: lipo -archs $(realpath $(which make)). I suspect you might be using the x86_64 version of brew

It's normal for /usr/bin/clang to be universal. You don't have to disable x86, you just have to make sure you're not running from Rosetta.
Basically, any x86 process running through Rosetta, will also run its children processes also as x86.
So for example if make is strictly x86, then any process that make will spawn will be x86.
Try checking make: lipo -archs $(realpath $(which make)). I suspect you might be using the x86_64 version of brew

Got it! Getting the same output formake: x86_64 arm64e

What does uname -m return when running it from the same terminal that gives you the compilation error?

What does uname -m return when running it from the same terminal that gives you the compilation error?

arm64 on the standard Terminal

I'm not sure what the problem is.
Try forcing arm64 using:
arch -arm64 make -f makefile.arm64
arch -arm64 make -f makefile.arm64 sign

I'm not sure what the problem is.
Try forcing arm64 using:
arch -arm64 make clean
arch -arm64 make -f makefile.arm64
arch -arm64 make -f makefile.arm64 sign

That ended up working after doing a clean install of homebrew and yabai! Thanks for all your help @alin23, it's very much appreciated :)

@rlch if @alin23's suggestion doesn't work, see if the changes I've just pushed work for you.

You'll have to build using make -f makefile.arm64; make -f makefile.arm64 sign, which should take care of everything (no need to install Frida now).

I do have a problem with the codesign.
~/b/yabai-m1 ❯❯❯ arch -arm64 make -f makefile.arm64 sign
codesign -fs "yabai-cert" ./bin/yabai
error: The specified item could not be found in the keychain.
make: *** [sign] Error 1

Probably an issue with my build environment. Any ideas how to setup the keychain? Might be worth adding this to the Makefile as maybe other people don't have a sign cert setup.

@stackpivot
The cert creation part is laid out in detail here: https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD)

@xorpse Thanks for spending your time figuring this out. I'm sure a lot of people will be happy with a workaround for now.
As for upstreaming said changes, I would like the arm64 changes to be structured equally to the x86_64 code; using patterns for lookup rather than exact locations. It should not be necessary to depend on Frida to perform the injection either; the built-in injector should be updated with the required changes. I don't expect said changes to be made by any of you, but this is just to let you know of my thoughts so far. My plan for the future also includes shipping a universal binary, and I'd like the installation process to be as streamlined as it currently is, regardless of the target architecture.
Unfortunately Apple has yet to announce the new mbps, so I assume that they will not be available until the end of this year.
Because of this the new machines will likely ship with macOS Monterey and if that is the case, I will not upstream support for Big Sur on Apple Silicon processors at all; but jump directly to macOS 12 support. You'll have to remain patient for a couple of more months for official support to arrive.

@koekeishiya I don't think reworking what's on my fork to adhere to your wants will be a lot more work.
In the latest commit, I've removed the Frida dependency and replaced it with a arm64 assembly stub, so modulo a clean up and replacement of offsets with patterns, everything should match the current experience for x86-64. Of course, it's your prerogative if you don't want to officially support the Apple Silicon right now :).

@alin23 Your script got it to work! thanks so much for your help!

@koekeishiya I don't think reworking what's on my fork to adhere to your wants will be a lot more work.
In the latest commit, I've removed the Frida dependency and replaced it with an arm64 assembly stub, so modulo a clean up and replacement of offsets with patterns, everything should match the current experience for x86-64. Of course, it's your prerogative if you don't want to officially support the Apple Silicon right now :).

so a solution, for the time being, could be clone your repo and build it and add it to a path or something like that? At l;east until @koekeishiya has the ability to test and implement on a real M1?

@itstheandre until official support is available, you can install my fork using:
brew install --HEAD xorpse/formulae/yabai

Everything else should work as documented in the wiki.

@xorpse I'm desperate to use brew install --HEAD xorpse/formulae/yabai build, but can't run the service after installation, have an error without a log. If I'm trying to run yabai directly the process is instantly killed. My OS version 11.4, SIP is disabled, I followed this https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(from-HEAD) instruction for generating self-signed certificates. What could I miss most likely?

@incerta Have added -arm64e_preview_abi to your boot arguments? If not, do the following and reboot:
sudo nvram boot-args=-arm64e_preview_abi

@incerta Have added -arm64e_preview_abi to your boot arguments? If not, do the following and reboot:
sudo nvram boot-args=-arm64e_preview_abi

yes, I missed it, now it is working thanks a lot

@incerta @xorpse I'm having some trouble getting the forked version up and running. Here are the steps I followed

entered recovery mode and disabled SIP csrutil disable --with kext --with dtrace --with basesystem
rebooted and added the boot arg sudo nvram boot-args=-arm64e_preview_abi
rebooted again and then installed yabai brew install --HEAD xorpse/formulae/yabai
installed SA sudo yabai --install-sa
loaded SA sudo yabai --load-sa
followed the Big Sur directions for automatically loading SA
started yabai brew services start xorpse/formulae/yabai
installed skhd brew install koekeishiya/formulae/skhd
started skhd brew services start skhd

I already had my yabairc (with the load-sa section) and skhdrc in place so I didn't need to manually copy those from the examples.
After doing all of those steps it still seems like only the non SA related commands work. If I try to create a new desktop, move the window to it, and follow focus nothing happens. I tried running some of the yabai commands directly in a shell and I don't get any errors but again nothing happens. For example I tried yabai -m space --focus 1 and focus wouldn't move despite being in the 3rd desktop when running that command. Do either of you have any insight into what I may have done wrong or what I could do to help debug further. My guess is that the scripting addition stuff isn't actually running but I don't know how to confirm that.

@JoshYork
I'm not sure you've missed anything, so here's a couple of things that spring to mind:

The fork only supports 11.3.1 and 11.4, so if you're not on one of those versions, it won't work (though I'd expect it to crash rather than do nothing).
Make sure that you have signed the yabai binary (see here).
Make sure that the yabai on your path is the correct one and has the right architecture, i.e., you should expect file $(which yabai) to give something like: /opt/homebrew/bin/yabai: Mach-O 64-bit executable arm64e.

If all else fails, see if it works with SIP completely disabled.

It's working for me now. I thought I was on the latest version of macOS already but I was only on 11.1. So I upgraded from 11.1 -> 11.4 and then followed all the other suggestions but was seeing the same issues. I then disabled SIP entirely by going into recovery mode and running crsutil disable. That seemed to do the trick and everything is working as expected 🎉. I really appreciate the quick response and all the effort spent getting this working on apple silicon!

Hi I'm having trouble compiling. Either brew install --HEAD xorpse/formulae/yabai or make -f makefile.arm64 in cloned dir won't success.
It just tells me
./src/osax/arm64/injector.c:15:10: fatal error: 'ptrauth.h' file not found

Running on Big Sur 11.4 M1 Macbook Air
Apple clang version 12.0.5 (clang-1<IP_ADDRESS>)
I'm pretty sure that zsh,make,clang are all running on arm64.
have done csrutil disable
have done sudo nvram boot-args=-arm64e_preview_abi and rebooted

The fork only supports 11.3.1 and 11.4

Is this specifically these two versions? Or just 11.3.1+?
I can't seem to get spaces working with 11.5 Beta.

The fork only supports 11.3.1 and 11.4

Is this specifically these two versions? Or just 11.3.1+?
I can't seem to get spaces working with 11.5 Beta.

Yes, specifically those versions. Each new version of macOS needs different code offsets to be added to yabai's source.

@Sduby22  had the same error, but for me clang was from Homebrew and did not have that header file.
Made some fixes to compilation c0ecbaa357db452b0686a9ed05722838f8a37163

@xorpse I had your fork working properly on 11.5 (sa included) but the sa won't load since the 11.5.1 security update.
I get the following message : scripting-addition payload (0x0) doesn't support this macOS version!

I'll try take a look this weekend. I've not yet had chance to update to
11.5..
On 27/07/2021 21:26, Jérémy Quilleré wrote:

@xorpse https://github.com/xorpse I had your fork working properly on
11.5 (sa included) but the sa won't load since the 11.5.1 security update.
I get the following message : |scripting-addition payload (0x0) doesn't
support this macOS version!|
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/725#issuecomment-887811240, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKF6U4P6YEQA4O72XIVD7TTZ4I6PANCNFSM4T2SNMWA.

@xorpse 11.4, 11.5, and 11.5.1 have same offsets.

@hunterliao29 thanks :). If you reopen your PR, I'll merge it.

I just tried to install xorpse's fork, it worked fine initially but after rebooting and turning on SIP after install it errors out with
yabai: could not access accessibility features! abort..
yabai: could not access accessibility features! abort..
'window_opacity_duration' cannot be changed on macOS Catalina/Big Sur because of an Apple bug in the WindowServer```

I'm assuming this fork only works when SIP is completely disabled? Or is it possible to reenable SIP at some point? No worries if it's not but I'd like to avoid leaving SIP off if it's not necessary.

@marshoepial that looks like you need to grant accessibility access in preferences. may have to sign the app to be able to do so

@mvllow Sorry, I forgot to mention that I did grant accessibility access to both yabai and skhd. I'm reinstalling it now so I'll see if I still run into that problem.

@xorpse When I try to install your fork, some errors occur. Could you give me some help?

@rotc It looks like you're building for the wrong architecture.
Try to see if you can build it directly from the repository (without homebrew) using the makefile for building a universal binary (makefile not makefile.arm64).

@xorpse Thank you for your help. But when I clone manually, I still get these error.
git clone https://github.com/xorpse/yabai.git
make -f makefile install

@rotc check if the terminal or shell is running under rosetta (intel) using activity monitor. e.g. type zsh/bash/fish/Terminal

@tami5 After checking activity monitor, it seems like my terminal is running under intel. And what should I do?

@tami5 After checking activity monitor, it seems like my terminal is running under intel. And what should I do?

Hmm is,  try to open zsh using Terminal.app. maybe this is caused wjth your terminal being built or configured to ran as rosetta

@tami5 @xorpse @JoshYork  Thank you very much for your help. I finally make it work.

Run zsh in Terminal.app instead of iterm2, so zsh is running under apple instead of intel.
Reinstall homebrew in /opt/homebrew.
Do as @JoshYork , except that I run csrutil disable in the first step

ouch, I have updated macos to 11.5.1 and now it xorpse/formulae/yabai is not working, luckily https://github.com/xorpse/yabai repo already merged required changes, I have cloned repo and followed README-arm64.md file instructions, and it is working again, thank you again @xorpse and @hunterliao29

@incerta  you can reinstall yabai using Homebrew by following this wiki Updating to latest HEAD

@incerta you can reinstall yabai using Homebrew by following this wiki Updating to latest HEAD

When I run codesign -fs "${YABAI_CERT:-yabai-cert}" "$(brew --prefix yabai)/bin/yabai"
It said error: The specified item could not be found in the keychain

ouch, I have updated macos to 11.5.1 and now xorpse/formulae/yabai from brew is not working, luckily https://github.com/xorpse/yabai repo already merged required changes, I have cloned repo and followed README-arm64.md file instructions, and it is working again, thank you again @xorpse and @hunterliao29

Confirming that this works well on my M1 mac mini as well.

he scripting-addition obviously needs a full rewrite for the ARM architecture and I do not actually have hands on experience with any ARM processor. This should not be a blocker, but will take time as the Dock.app ARM binary needs to be reverse engineered in the same way we did the x86-64 version.

Is there a link to how exactly the Dock.app was re-engineered? I remember chunkwm I think you were using hopper but was wondering if you had a link outlining more or less the process.

Is there a link to how exactly the Dock.app was re-engineered? I remember chunkwm I think you were using Hopper but was wondering if you had a link outlining more or less the process.

I use IDA Pro (free version) for x86 binaries and Ghidra for ARM at the moment. See https://github.com/koekeishiya/yabai/issues/971 for some general information as to how this is done.

I haven’t gotten to learning or exploring it. Here’s some general links for “how to reverse engineer arm apps”: https://zygosec.com/post1.html
https://azeria-labs.com/writing-arm-assembly-part-1/

On Aug 31, 2021, at 16:28, Åsmund Vikane @.***> wrote:

Is there a link to how exactly the Dock.app was re-engineered? I remember chunkwm I think you were using Hopper but was wondering if you had a link outlining more or less the process.
I use IDA Pro (free version) for x86 binaries and Ghidra for ARM at the moment. See #971 for some general information as to how this is done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

I'm about to try yabai on a mac mini M1, but I'm still in doubt about the "right" way to do. Should I go for the @xorpse fork or should just use the HEAD version? thx

The xorpse fork works fine. I've been using it for around a month now and I did not face any issues even with the sa.

Me too, the xorpse fork is great!

entered recovery mode and disabled SIP csrutil disable --with kext --with dtrace --with basesystem
rebooted and added the boot arg sudo nvram boot-args=-arm64e_preview_abi
rebooted again and then installed yabai brew install --HEAD xorpse/formulae/yabai
installed SA sudo yabai --install-sa
loaded SA sudo yabai --load-sa
followed the Big Sur directions for automatically loading SA
started yabai brew services start xorpse/formulae/yabai
installed skhd brew install koekeishiya/formulae/skhd
started skhd brew services start skhd

@clyra use this to install

If by catalyst you mean iPhone and iPad apps then I have no idea if they work because I only use mac apps on my M1 MBP.

Did anyone update to 11.6 yet? Some yabai commands don't seem to work like moving focus to another space etc..(xorpse fork)

Yes. I found that yabai —load-sa worked fine for me.
I am running —HEAD from the xorpse fork.
On Tue, Sep 14, 2021 at 5:37 AM Yassine Bridi @.***>
wrote:

Did anyone update to 11.6 yet? Some yabai commands don't seem to work like
moving focus to another space etc..(xorpse fork)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/725#issuecomment-919109117,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABEOIB2WRUHYUDUSGKLB4D3UB46ZHANCNFSM4T2SNMWA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hmm, i'm getting yabai: scripting-addition could not locate pid of Dock.app! when running sudo yabai --load-sa

I take it back and apologize ! Machine hasn’t restarted yet. I’m sure it
won’t work due to the lack of offset updating.
On Tue, Sep 14, 2021 at 06:42 Yassine Bridi @.***>
wrote:

Hmm, i'm getting yabai: scripting-addition could not locate pid of
Dock.app! when running sudo yabai --load-sa
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/725#issuecomment-919163715,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABEOIB4FB3KX3VO4CWUBADDUB5GN3ANCNFSM4T2SNMWA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

The xorpse fork works fine. I've been using it for around a month now and I did not face any issues even with the sa.

Does it work fine with Monterey?

I also updated today and didn't check if 11.6 was supported in the xorpse fork.
Here is what I did to make it work (on m1 / arm64): https://github.com/vespakoen/yabai/tree/11.6-tmp-fix
Apparently there is an "ATTRIB" missing, causing the scripting addition to bail out (over here: https://github.com/xorpse/yabai/compare/master...vespakoen:11.6-tmp-fix?expand=1#diff-d9239c24ade01451090774a6a6f82fc23aa527414ee76be040fb775b7de27688L243)
But disabling that makes things work for me again.
I also used Ghidra to try and find the new addresses, it kinda worked, but Ghidra was bugging / flickering a lot when comparing the versions and looking where the pointers ended up.
They all seem to have stayed the same, and it seems to work fine, but there might be a feature missing that I am not using.

@xorpse I updated to 11.6 but I get some issues, I could load-sa butyabai -m space --focus 2 doesn't seems to work anymore with https://github.com/xorpse/yabai.
I tried your fix @vespakoen but I am not sure how should I replace the Dock.app you provide in your zip, as I don't have permission do replace the Dock.app in /System/Library/CoreServices. I guess I need to do that in recovery mode? Is it really necessary as we didn't do it before with xorpse fix?

@leglopy I'm having the same problem as well -- scripting addition loads fine, but I can't focus spaces. Were you able to get vespakoen's fix working?

I uploaded the Dock for anyone who wants to reverse engineer it / compare it to older versions to see what addresses changed.
You do NOT need to install it!
You can however download my fork and compile and run it, or wait for someone else to find out all the correct new addresses and update it in xorpse's fork.

@unrooot no I get that error @vespakoen when I use your fork could not spawn remote thread: (os/kern) protection failure yabai: scripting-addition failed to inject payload into Dock.app! . this is the result of csrutil status : `System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: enabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem Verification: enabled
Boot-arg Restrictions: disabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.` Do you have any suggestion? Thanks

@vespakoen Thanks for the clarification!
I usually run brew install --HEAD xorpse/formulae/yabai to install xorpse's fork

@vespakoen Is possible to details all the steps to install your fork?

Hey, I have created a brew formulae for @vespakoen's fork, you can install it using:
brew install --HEAD yassinebridi/formulae/yabai

This is the formulae's repo if anyone is interested:
https://github.com/yassinebridi/homebrew-formulae
And it is working as expected, thank you @vespakoen.

Off-topic, but what tool are you using to for this screengrab? It looks great :).

Hey, I have created a brew formulae for @vespakoen's fork, you can install it using:
brew install --HEAD yassinebridi/formulae/yabai

I was also able to get everything working on 11.6 with this fork. These are the steps I took:
brew uninstall xorpse/formulae/yabai
brew install --HEAD yassinebridi/formulae/yabai
sudo yabai --install-sa
sudo yabai --load-sa

@yassinebridi Thanks for porting it to brew! I've also only ran yabai through brew, so I was mostly just guessing and trying stuff until I got it working.
(if anyone needs it)
I'm not sure if this is the correct way to do it, I got it working with these commands:
git clone https://github.com/vespakoen/yabai && cd yabai
git checkout 11.6-tmp-fix
sudo make install
sudo cp ./bin/yabai /bin
yabai &
skhd &

On the @xorpse and @yassinebridi forks of Yabai installed through Homebrew it just exits on me without any message when I attempt to run it:
$ yabai
Killed: 9

I am on an M1 and it is the version compiled for the M1 architecture:
$ file $(which yabai)
/opt/homebrew/bin/yabai: sticky Mach-O 64-bit executable arm64e

The x86_64 version works with my Yabai config, just with lots of stuttering.
I haven't installed the scripting additions because I don't really use them and I don't want to disable SIP. Do the scripting additions need to be installed in order to work? I'm not sure else would be causing this issue.

On the @xorpse and @yassinebridi forks of Yabai installed through Homebrew it just exits on me without any message when I attempt to run it:
$ yabai
Killed: 9

I am on an M1 and it is the version compiled for the M1 architecture:
$ file $(which yabai)
/opt/homebrew/bin/yabai: sticky Mach-O 64-bit executable arm64e

The x86_64 version works with my Yabai config, just with lots of stuttering.
I haven't installed the scripting additions because I don't really use them and I don't want to disable SIP. Do the scripting additions need to be installed in order to work? I'm not sure else would be causing this issue.

I have this issues too on 11.5.2:
❯ sudo yabai --install-sa
[1]    3257 killed     sudo yabai --install-sa
❯ yabai
[1]    3259 killed     yabai

I was following these instructions:

entered recovery mode and disabled SIP csrutil disable --with kext --with dtrace --with basesystem
rebooted and added the boot arg sudo nvram boot-args=-arm64e_preview_abi
rebooted again and then installed yabai brew install --HEAD xorpse/formulae/yabai
installed SA sudo yabai --install-sa
loaded SA sudo yabai --load-sa
followed the Big Sur directions for automatically loading SA
started yabai brew services start xorpse/formulae/yabai
installed skhd brew install koekeishiya/formulae/skhd
started skhd brew services start skhd

@clyra use this to install

@Holer90 I tried that and it seems that relies on SIP to be disabled. I noticed that Yabai worked when I disabled SIP, though.
Prior to running MacOS Monterey there was no need to disable SIP for Yabai to do its base functions. Will I need to leave SIP disabled for Yabai to work from now on?

Prior to running MacOS Monterey there was no need to disable SIP for Yabai to do its base functions. Will I need to leave SIP disabled for Yabai to work from now on?

I don't know what changes these forks have done, but no that will not be a requirement when I do add support for Apple Silicon.
I will be pre-ordering an Apple Silicon machine this october/november when they are announced and will work on this shortly after. My current mbp does not support Monterey, so I have not been following the changes that closely.

I have the same problem when upgraded to MacOS 11.6. I tried to install yabai like this:

Hey, I have created a brew formulae for @vespakoen's fork, you can install it using:
brew install --HEAD yassinebridi/formulae/yabai

This is the formulae's repo if anyone is interested: https://github.com/yassinebridi/homebrew-formulae
And it is working as expected, thank you @vespakoen.

I get this error:
Last 15 lines from /Users/username/Library/Logs/Homebrew/yabai/01.make:
mov x0, #0
        ^
./src/osax/arm64/sa_arm64e.s:56:15: error: brackets expression not supported on this target
ldp x29, x30, [sp], #0x10
              ^
./src/osax/arm64/sa_arm64e.s:57:1: error: invalid instruction mnemonic 'retab'
retab
^~~~~
./src/osax/arm64/sa_arm64e.s:59:3: error: invalid instruction mnemonic 'function'
; function pointers
  ^~~~~~~~
./src/osax/arm64/sa_arm64e.s:67:3: error: invalid instruction mnemonic 'data'
; data
  ^~~~
make: *** [src/osax/arm64/sa_arm64e.o] Error 1

Am I doing something wrong? I completely uninstalled the previous yabai version

I ran @JoshYork's instructions on Version 11.6 (20G165) and it's working on my M1 Mac Mini 👍

I am getting the following error after running @yassinebridi brew formula on M1 mac pro (11.6)
The brew install is fine but when i run sudo yabai --install-sa or just yabai I get the following errors respectively.
zsh: killed     sudo yabai --install-sa

zsh: killed     yabai

@razagill Have you tried the first two steps in this reply?
I just installed the same brew formula on my MacBook Air (11.6) and once ran into an issue very similar to yours. Disabling SIP and adding boot args fixed the problem.

@razagill Try those commands on the official Terminal app, with the default shell.

@yulanqing Thanks, that did it :)

I ran @JoshYork's instructions on Version 11.6 (20G165) and it's working on my M1 Mac Mini 👍

Can you help with what should I do next then? I have exactly the same version of MacOS as you. I also get same errors when I clone the repo and compile it on my own.

I have the same problem when upgraded to MacOS 11.6. I tried to install yabai like this:

Hey, I have created a brew formulae for @vespakoen's fork, you can install it using:
brew install --HEAD yassinebridi/formulae/yabai

This is the formulae's repo if anyone is interested: https://github.com/yassinebridi/homebrew-formulae
And it is working as expected, thank you @vespakoen.

I get this error:
Last 15 lines from /Users/username/Library/Logs/Homebrew/yabai/01.make:
mov x0, #0
        ^
./src/osax/arm64/sa_arm64e.s:56:15: error: brackets expression not supported on this target
ldp x29, x30, [sp], #0x10
              ^
./src/osax/arm64/sa_arm64e.s:57:1: error: invalid instruction mnemonic 'retab'
retab
^~~~~
./src/osax/arm64/sa_arm64e.s:59:3: error: invalid instruction mnemonic 'function'
; function pointers
  ^~~~~~~~
./src/osax/arm64/sa_arm64e.s:67:3: error: invalid instruction mnemonic 'data'
; data
  ^~~~
make: *** [src/osax/arm64/sa_arm64e.o] Error 1

Am I doing something wrong? I completely uninstalled the previous yabai version

I figured out what was wrong. So basically I realised I get the same error when installing xorpse fork, which worked before the MacOS 11.6 update. I looked in the history of this thread, and found that @rotc had the exact same problem. So I followed his solution and it is working now. (The issue was compiling yabai for wrong architecture).

Thanks @hackorum for your overview of the installation process. I was able to install on my M1 MBA very quickly!

Does any have a fork where the scripting addons work on Monterey (12.0.1)? I've tried xorpse/formulae/yabai and yassinebridi/formulae/yabai with no luck. I'm sure there needs to be code changes so it's not surprising those didn't work. I wasn't thinking and clicked upgrade before realizing it'd probably break some yabai functionality 🤦🏻

+1 Also interested in if there's a fork that works on Monterey.

I think this fork works but I have not tried it yet. I just upgraded to monterey

That fork - with the two proposed PRs - works well for me on the m1.
On Wed, Nov 3, 2021 at 20:00 Neil Sabde @.***> wrote:

I think this https://github.com/donaldguy/yabai fork works but I have
not tried it yet. I just upgraded to monterey
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/725#issuecomment-960415136,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABEOIB6TGV7VYE2CPSDT37DUKHZMJANCNFSM4T2SNMWA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

How did you install it?

@hackorum I just installed cxa's fork now. Since I just fired it up I can't speak to its stability but figured I'd doc the steps I took in case it helps.  I just built from cxa's canon rather than trying to also integrate his Monterey branch.  That looks like a single line change though so it would be easy to integrate the two if that's what @jonathanwilner means.
Here are the steps I took:
mkdir yabai-cxa
cd yabai-cxa
git clone git@github.com:cxa/yabai.git .
make ./bin/yabai-x86_64 # I'm on Intel still and get errors if I don't restrict the architecture.
# on M1 `make` may be all that is needed to build a universal binary
rm /usr/local/bin/yabai
cp ./bin/yabai-x86_64 /usr/local/bin/yabai # obviously adjust target path to suit personal usage

I'm on an m1 and have tried https://github.com/donaldguy/yabai (with merging the two open PRs) and cxa's canon branch directly. These are the steps I'm taking:

confirmed my SIP is still fully disabled and my boot args match this: https://github.com/donaldguy/yabai/blob/canon/README-arm64.md
blew away existing certs and created a new one using Keychain Access

git clone git@github.com:donaldguy/yabai.git
cd yabai
git remote add cxa https://github.com/cxa/yabai.git
git merge cxa/monterey-random-crash-workaround
git merge cxa/canon
make -j1
make sign
sudo ./bin/yabai --install-sa && sudo ./bin/yabai --load-sa
# ^ Output: yabai: scripting-addition could not locate pid of Dock.app!
./bin/yabai

Yabai starts up and the basics work but none of the SA stuff works which makes sense given the error message from --load-sa.
make -j1 also creates a yabai-arm64 bin, I would assume that's what we're supposed to use based on the naming but it fails in the same way for me.
I've also done the same process with cxa's repo directly which should be the same as using donald's as the base and then merging in cxas PRs but I had no other ideas.
I would not be surprised at all if I'm doing something wrong. This is my first time trying to build yabai from source and use it instead of grabbing a version from brew. Let me know if there's anything obvious I'm missing. Apologies for the spam to this thread. We can move this discussion / troubleshooting elsewhere if need be.

Hi,
The only differences (as I read this):

I didn't merge from cxa - I just cloned from the 3rd PR in the donaldguy/yabai repo.

I took the compiled yabai and put it into /opt/homebrew/bin & adjusted any homebrew symlinks to point there.

I removed any other existing yabai binaries that might be around - for a while the startup scripts were finding older, pre-Monterey versions.

Josh York @.***> writes:

I'm on an m1 and have tried https://github.com/donaldguy/yabai (with merging the
two open PRs) and cxa's canon branch directly. These are the steps I'm taking:

confirmed my SIP is still fully disabled and my boot args match this:
https://github.com/donaldguy/yabai/blob/canon/README-arm64.md
blew away existing certs and created a new one using Keychain Access

git clone @.***:donaldguy/yabai.git
cd yabai
git remote add cxa https://github.com/cxa/yabai.git
git merge cxa/monterey-random-crash-workaround
git merge cxa/canon
make -j1
make sign
sudo ./bin/yabai --install-sa && sudo ./bin/yabai --load-sa
^ Output: yabai: scripting-addition could not locate pid of Dock.app!
./bin/yabai
Yabai starts up and the basics work but none of the SA stuff works which makes
sense given the error message from --load-sa.
make -j1 also creates a yabai-arm64 bin, I would assume that's what we're
supposed to use based on the naming but it fails in the same way for me.
I've also done the same process with cxa's repo directly which should be the
same as using donald's as the base and then merging in cxas PRs but I had no
other ideas.
I would not be surprised at all if I'm doing something wrong. This is my first
time trying to build yabai from source and use it instead of grabbing a version
from brew. Let me know if there's anything obvious I'm missing. Apologies for
the spam to this thread. We can move this discussion / troubleshooting elsewhere
if need be.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Wanted to chime in here one last time to point others at the fork and docs that got this working for me on Monterey 12.1 https://github.com/koekeishiya/yabai/discussions/1042#discussioncomment-1590691

Why do I have upgraded to Monterey without checking this? 😢

It works on 12.1 beta

i would have to retry this to send my logs, but when i tried on my mbp 13" m1, every 30min WindowServer was crashing, logging me out everytime
pretty annoying :/

Yes same problem for me :(

All the apps would close

I've managed to get yabai working on M1 running Monterey using donaldguy's repo. Scripting additions are working but I cannot get Übersicht to work so most of my use case is gone. The windows still overlap each other vertically, no idea why.

Just a quick update..
I have received my new mbp (running Monterey 12.0.0 for various reasons) and have started doing some of this work, targeting the-future branch, as surprisingly enough, that's where the future is.
So far the mentioned branch will build a universal/fat binary containing both arm64e and x86-64 images.
The scripting-addition is updated for Monterey 12.0.0. The Apple Silicon version is confirmed working, but I cannot verify the Intel version as my old/Intel mbp does not support Monterey.
As I mentioned yabai includes an arm64e image, not an arm64 image. From what I understand this is basically just arm64 WITH pointer authentication: https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication
The thing that matter for us is that arm64 and arm64e are separate ABIs, and we need to be compatible with whatever ABI Dock.app follows. On Apple Silicon Macs, all system applications provided by Apple are targeting the arm64e architecture, and so for yabai to be able to inject code, we must also target arm64e.
The arm64e ABI is still in "preview" mode, and so a user is unable to run non-apple-signed binaries without manually adjusting the boot arguments: sudo nvram boot-args=-arm64e_preview_abi. To adjust boot arguments, SIP must be disabled.
Thus, users that run yabai without the scripting-addition/disabling SIP will NOT be able to run the pre-compiled Apple Silicon binary. They would need to manually edit the makefile and build an arm64 image instead of arm64e, from source.
--
I consider the actual changes required for Apple Silicon to be done, but I am going to keep this issue open until the wiki/documentation has been updated to reflect support, requirements, caveats and whatever else that should be mentioned.
That said, there are multiple other issues in Monterey that will need to be resolved. the-future branch is NOT release-ready in any form; this is just a progress update as I know many people are waiting..
Check #923 for future updates regarding the Monterey issues/status.

Hello @koekeishiya, I just tried out to build the the-future branch.
The yabairc configs seems to be correctly used, however I get the following bugs:

doing sudo yabai --load-sa gives me a notification: payload (0x04) doesn't support this macOS version!
I cannot execute any space with yabai -m space --focus ..

I have split the mach loader into a separate binary that is installed with the scripting-addition payload when running yabai --install-sa, and so yabai itself can remain an arm64 binary (instead of arm64e). This will allow users that do not use the scripting-addition to run the pre-built binary that will be released.
The mach loader itself is an arm64e binary and the scripting-addition will still require users to enable the arm64-preview boot-argument.  As mentioned before the scripting-addition is only updated for 12.0.0 at the moment, and I will work my way upwards when I feel comfortable that most issues have been sorted. Window borders cause applications to not be rendered correctly and also hang/become unresponsive, and should not be used for now. I will likely disable this functionality so that a release can be made, as I do not know if it is even possible to make this border system work again.
From my limited testing so far, the-future branch seems to be stable and I have not had any crashes (with the exception of the window borders). I say limited testing because I have not been running a session for more than probably ~4hours, as I am iterating on changes to yabai most of the times when I actually use my MacBook.
The only changes necessary to the documentation would be to mention the arm64e-preview boot-argument, for people who want to use the scripting-addition. If you plan to run yabai with SIP enabled, you can simply install the (upcoming) prebuilt binary.

@koekeishiya Thanks for the effort and the update!

I have decided to merge the-future branch into master. I believe it should be fairly stable as long as window borders are disabled. Note that this version will be released as v4.0.0 due to various breaking changes (that are unrelated to Monterey and Apple Silicon).
I will be running this version myself for some time and trying various things to see how well it holds up before thinking about doing an official release.

I have decided to merge the-future branch into master. I believe it should be fairly stable as long as window borders are disabled. Note that this version will be released as v4.0.0 due to various breaking changes (that are unrelated to Monterey and Apple Silicon).
I will be running this version myself for some time and trying various things to see how well it holds up before thinking about doing an official release.
I have updated the instructions for disabling SIP (and enabling arm64e on Apple Silicon) in the wiki page

Why is there always a tiny gap?
https://github.com/donaldguy/yabai doesn't have this.

@AurevoirXavier
The issue is caused by #793. If you run DonalGuy's fork, you should see windows not get positioned properly with various menubar+padding configurations, causing windows to overlap and window_gap to be wrong. The function that we use to detect the menubar is not working on Apple Silicon (always returns 0) where as the same function running under Rosetta does work fine.
The values that are there now are based on what I've seen on my MacBook in different config states. Are you on a MacBook with a notch or not? Do you use the default resolution or have you changed it?

@AurevoirXavier
The issue is caused by #793. If you run DonalGuy's fork, you should see windows not get positioned properly with various menubar+padding configurations, causing windows to overlap and window_gap to be wrong. The function that we use to detect the menubar is not working on Apple Silicon (always returns 0) where as the same function running under Rosetta does work fine.
The values that are there now are based on what I've seen on my MacBook in different config states. Are you on a MacBook with a notch or not? Do you use the default resolution or have you changed it?

I have just switched to the master from donalguy's fork.
I'm on MacBookPro 16 2021(with notch).
I'm on the default resolution.

Well this is just great; the height of the menubar changes based on the selected resolution this time around, so I guess we have to dig for a new kind of API. In default resolution the lowest y-coordinate usable on a display with notch is 38, where as with the 14" Max scaled resolution it changes to 44.

xavier in ~ takes 173ms
Fri Nov 19 16:35:33 2021 - 30%
λ sudo yabai --load-sa
could not set thread state: (os/kern) protection failure
yabai: scripting-addition failed to inject payload into Dock.app!

xavier in ~ takes 58ms
Fri Nov 19 16:35:36 2021 - 31%
✗ csrutil status
System Integrity Protection status: disabled.

Any idea on this?
I follow the latest wiki that you mentioned above.

I am unable to reproduce that error. What's the output of the following:
cat /Library/ScriptingAdditions/yabai.osax/Contents/Info.plist | grep -A 1 CFBundleVersion

ile /Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload

file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader

xavier in ~
Fri Nov 19 16:50:30 2021 - 36%
✗ cat /Library/ScriptingAdditions/yabai.osax/Contents/Info.plist | grep -A 1 CFBundleVersion

<key>CFBundleVersion</key>
<string>2.0.0</string>

xavier in ~ takes 21ms
Fri Nov 19 16:50:31 2021 - 36%
λ file /Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload: Mach-O 64-bit dynamically linked shared library arm64

xavier in ~ takes 26ms
Fri Nov 19 16:50:39 2021 - 36%
λ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: Mach-O 64-bit executable arm64

Well that is weird, my output is:
~ cat /Library/ScriptingAdditions/yabai.osax/Contents/Info.plist | grep -A 1 CFBundleVersion                 9:57
<key>CFBundleVersion</key>
<string>2.0.0</string>
~ file /Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload       9:57
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e
~ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader                                     9:57
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader (for architecture arm64e):	Mach-O 64-bit executable arm64e

Well that is weird, my output is:
~ cat /Library/ScriptingAdditions/yabai.osax/Contents/Info.plist | grep -A 1 CFBundleVersion                 9:57
<key>CFBundleVersion</key>
<string>2.0.0</string>
~ file /Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload       9:57
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/Library/ScriptingAdditions/yabai.osax/Contents/Resources/payload.bundle/Contents/MacOS/payload (for architecture arm64e):	Mach-O 64-bit dynamically linked shared library arm64e
~ file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader                                     9:57
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader (for architecture arm64e):	Mach-O 64-bit executable arm64e

I have also tried uninstall&install.

If you use the prebuilt binary I posted in: https://github.com/koekeishiya/yabai/issues/923#issuecomment-973353234 to install the scripting-addition. Run the same check as above. Does it show as a universal binary? I suspect there is an issue with brew compilation for whatever reason???

I've confirm installing with brew install koekeishiya/formulae/yabai --HEAD will cause arch to be arm64 not arm64e. With cloning to local and manual makeing, every thing is fine.

I enabled window border and there's inner shadows, as I investigated before, kCGSDisableShadowTagBit does not work anymore. You can check my workaround here https://github.com/donaldguy/yabai/pull/2/files if you would interest. @koekeishiya

I've confirmed installing with brew install koekeishiya/formulae/yabai --HEAD will cause arch to be arm64 not arm64e. With cloning to local and manual makeing, every thing is fine.

Fixed by building from source then replacing the binary.

There are some lines in the makefile at master which states -arch arm64 instead of -arch arm64e. Couldn't that be the culprit?

@cxa Borders cause the window server and/or random applications to crash; you probably should not use these. Regarding the shadow; I'll investigate that if I am able to get borders working properly. Chances are that borders will be removed, as I think the API we rely on is just not reliable anymore.
@storopoli The yabai binary itself is built as arm64 & x86_64, but the scripting-addition is built as arm64e & x86_64

Might be something related to this? In my machine homebrew clang takes over as the main compiler:
❯ which clang
/opt/homebrew/opt/llvm/bin/clang
❯ type -a clang
clang is /opt/homebrew/opt/llvm/bin/clang
clang is /usr/bin/clang

Ok, I think I got this. I've installed with brew install yabai --HEAD and them downloaded the prebuilt binary I posted in: #923 (comment) .
Then I did this (a kinda hack):
❯ cd Desktop/archive/bin/
mv yabai /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai
override r-xr-xr-x  storopoli/admin for /opt/homebrew/Cellar/yabai/HEAD-6bcf544/bin/yabai? (y/n [n]) y

It seem to be working now.

Closing in favour of #1054.

file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader

file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: cannot open `/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader' (No such file or directory)
m1 monterey 12.0.1    why ?

file /Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader
/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader: cannot open `/Library/ScriptingAdditions/yabai.osax/Contents/MacOS/mach_loader' (No such file or directory)

m1 monterey 12.0.1 why ?

Because there have been changes since 2021.
https://github.com/koekeishiya/yabai/issues/1287
https://github.com/koekeishiya/yabai/issues/1515#issuecomment-1344070256