Apple Silicon M1 - Githubissues

koekeishiya commented 4 years ago

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

cxa commented 3 years ago

Wow, so quick and nice!

Does this https://github.com/koekeishiya/yabai/commit/4410fef0fd272fc00a527f317351bb007bafe073 mean we can run script additions on M1 now?

koekeishiya commented 3 years ago

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 as window borders, opacity, layers (sticky windows) and such, but none of the spaces functionality will work yet.

Edit: For people with experience in reverse engineering; basically locate the functions and object instances using the patterns provided in the osax/x86_64/payload.m file in the x86_64 binary, look for patterns that let you identify the same function in the arm64 binary, and fill out osax/arm64/payload.m. These patterns are then resolved in the function init_instances() in osax/payload.m. There is some inline x86_64 specific code in osax/payload.m when both resolving and calling some of these functions that also require changes.

cxa commented 3 years ago

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

1.txt

koekeishiya commented 3 years ago

Should be resolved now.

fielding commented 3 years ago

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!

koekeishiya commented 3 years ago

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

cxa commented 3 years ago

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.

koekeishiya commented 3 years ago

Can you post the output of the following commands:

cxa commented 3 years ago

koekeishiya commented 3 years ago

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#L94

koekeishiya commented 3 years ago

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?

cxa commented 3 years ago

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

koekeishiya commented 3 years ago

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

cxa commented 3 years ago

Still the same.

koekeishiya commented 3 years ago

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

cxa commented 3 years ago

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.

koekeishiya commented 3 years ago

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

cxa commented 3 years ago

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

koekeishiya commented 3 years ago

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

ut0mt8 commented 3 years ago

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

typkrft commented 3 years ago

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.

jonathanwilner commented 3 years ago

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 notifications@github.com 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 .

typkrft commented 3 years ago

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.

ndom91 commented 3 years ago

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

TonyWu20 commented 3 years ago

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!

ndom91 commented 3 years ago

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

TonyWu20 commented 3 years ago

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.

jonathanwilner commented 3 years ago

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 notifications@github.com 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.

koekeishiya commented 3 years ago

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

ndom91 commented 3 years ago

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

ChiefMateStarbuck commented 3 years ago

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

edit: you're installing from --HEAD gotcha

okkdev commented 3 years ago

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.

psiionik commented 3 years ago

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?

vespakoen commented 3 years ago

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

wietsedv commented 3 years ago

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.

koekeishiya commented 3 years ago

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

hypergig commented 3 years ago

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

koekeishiya commented 3 years ago

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 iOS, causing the protection failure message seen above.

jonashaag commented 3 years ago

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.

Evyerone, react with 🚀 to commit to sponsoring 1 M1-day on Scaleway! (~$3)

koekeishiya commented 3 years ago

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.

vespakoen commented 3 years ago

@koekeishiya I can give you access to my M1, it has SIP disabled and XCode installed, ping me at ... edit: removed my email

joshmedeski commented 3 years ago

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

hypergig commented 3 years ago

@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 going on 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.

koekeishiya commented 3 years ago

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

haley-yung commented 3 years ago

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

lrangell commented 3 years ago

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.

joshmedeski commented 3 years ago

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.

GustavoKatel commented 3 years ago

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 😝

typkrft commented 3 years ago

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. It could be cleaned up a lot.

NOTE: Your path to yabai might be different

#!/bin/sh

# Get arguments
VARS=$1

MOVE=$(osascript - "$VARS" <<EOF
-- Notes
-- Either make sure that the desired is less than or equal to the total or create more if needed 
-- Negative Numbers move to the left and Positive to the right
-- Desired    Current    Move
-- 1          3          -2 
-- Desired    Current    Move
-- 4          3          1  
-- Desired    Current    Move
-- 3          3          0

-- Get Arguments
on run argv -- argv is a list of text

    -- Set Variables
    set currentDesktop to do shell script "/opt/homebrew/bin/yabai -m query --spaces | grep -a5 \\\\\"focused\\\\\":1 | grep index | sed -r 's/.*([[:digit:]]).*/\\\\1/'"
    set totalDesktops to do shell script "defaults read com.apple.spaces | sed -n '/\\\\\"Display Identifier\\\\\" = Main/,/\\\\\"Collapsed Space\\\\\"/p' | grep -c ManagedSpaceID"
    set toTheRight to (totalDesktops as number) - currentDesktop as number
    set toTheLeft to (currentDesktop as number) - 1
    set desiredDesktop to item 1 of argv as integer -- From Arguments passed to it

    -- Logs
    -- log toTheRight
    -- log toTheLeft
    -- log desiredDesktop
    -- log currentDesktop
    -- log desiredDesktop - currentDesktop

    -- Setup Checks

    -- Main Logic

    if desiredDesktop - currentDesktop < 0 then
        set a to desiredDesktop - currentDesktop
        set a to a as string
        set moves to item 2 of a as integer
        tell application "System Events"
            repeat moves times
                key code 123 using control down
                delay 0.1
            end repeat
        end tell
    else if desiredDesktop - currentDesktop > 0 then
        tell application "System Events"
            repeat desiredDesktop - currentDesktop times
                key code 124 using control down
                delay 0.1
            end repeat
        end tell
    else if desiredDesktop - currentDesktop is 0 then
        log "Desired Desktop is Current Desktop"
    else
        log "failed"
    end if

end run
EOF
)

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')))
  open -a "Mission Control"
  osascript -e "repeat \"$spaces\" times" -e "tell application \"System Events\" to click button 1 of group \"Spaces Bar\" of group 1 of group \"Mission Control\" of process \"Dock\"" -e "end repeat"
  open -a "Mission Control"
}

create_spaces $1

Creating spaces isn't pretty, but for me it works because I generally keep 5 spaces so it runs once at launch and that's it. Edit: Slightly prettier now.

haley-yung commented 3 years ago

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 "Ctrl + Desktop number" to swap to a particular desktop

koekeishiya / yabai

Apple Silicon M1 #725