Closed koekeishiya closed 1 year ago
Thank you @FelixKratz this fix seems to fix my issue with occasionally having to click windows 3-4 times to get focus, as well.
@FelixKratz
Something seems to have changed regarding to how window ordering works in the SLSOrderWindow* function family, which makes the animations a bit rough:
The user-side functions appear to be unchanged, but there may have been changes with regards to how ordering is handled in the compositor. I get this weird flickering sometimes at random, it is not happening every time. The window order does change as expected.
The other issue is that window borders created by yabai are no longer able to have their system alpha changed (from Dock.app or by yabai itself -- might require some other property or tag for this to be activated on Ventura??? as it does work for other windows).
@FelixKratz
Something seems to have changed regarding to how window ordering works in the SLSOrderWindow* function family, which makes the animations a bit rough:
The user-side functions appear to be unchanged, but there may have been changes with regards to how ordering is handled in the compositor. I get this weird flickering sometimes at random, it is not happening every time. The window order does change as expected.
The other issue is that window borders created by yabai are no longer able to have their system alpha changed (from Dock.app or by yabai itself -- might require some other property or tag for this to be activated on Ventura??? as it does work for other windows).
If you patch out window ordering for the border like this: https://github.com/FelixKratz/yabai/commit/ad59b40a6db7f467e7bfcaac18ecb906927ccb1e system alpha changes are respected. System alpha seems to be reset on some order operation.
system alpha changes are respected. System alpha seems to be reset on some order operation.
Hm good catch. Guess the entire border system needs some rethinking at this point, as there are multiple problems when using borders and animations at the moment.
@FelixKratz
Super hacky workaround to animation flickering: https://github.com/koekeishiya/yabai/tree/sigh
system alpha changes are respected. System alpha seems to be reset on some order operation.
Hm good catch. Guess the entire border system needs some rethinking at this point, as there are multiple problems when using borders and animations at the moment.
Actually, when using synchronous SLSTransaction
s the border system alpha problems go away as well as the flickering problems and the patch is much more trivial than thought: https://github.com/FelixKratz/yabai/commit/d072e4f4cbac8ac6fc54ffdd46021d085ffa3006
The problem with disabling all connections on resize still is present though, but it is also present on previous macOS versions.
SLSTransactionCommit
with a 1
as a second argument is equivalent to SLSTransactionCommitUsingMethod
with a 1
as a second argument, which mean synchronous execution.
SLSTransactionCommit with a 1 as a second argument is equivalent to SLSTransactionCommitUsingMode with a 1 as a second argument, which mean synchronous execution.
I tried this, but it had no effect on the flickering for me.
SLSTransactionCommit with a 1 as a second argument is equivalent to SLSTransactionCommitUsingMode with a 1 as a second argument, which mean synchronous execution.
I tried this, but it had no effect on the flickering for me.
Ok, now this is interesting... it works for me, but only when I unload apples WindowManager before starting yabai:
launchctl unload -F /System/Library/LaunchAgents/com.apple.WindowManager.plist > /dev/null 2>&1 &
If I leave this process running I indeed still see the flickering as well, but with the process unloaded there is no more flickering.
mac m1 os ventura 13.0.1
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.
➜ ~ sudo yabai --load-sa
yabai: scripting-addition failed to inject payload into Dock.app!
ProductName: macOS
ProductVersion: 13.0.1
BuildVersion: 22A400
I've installed yabai from HEAD and signed the binary.
mac m1 os ventura 13.0.1
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.
➜ ~ sudo yabai --load-sa yabai: scripting-addition failed to inject payload into Dock.app!
ProductName: macOS ProductVersion: 13.0.1 BuildVersion: 22A400
I've installed yabai from HEAD and signed the binary.
Can confirm I have the exact same issue on an Macbook pro M1 Max with Ventura 13.0.1
I'm having issues with stack layout in Ventura that I didn't before. I can't do
yabai -m window --focus stack.prev
orstack.next
.Edit: It seems to happen sporadically. When I mean I can't switch focus, I mean that the focus changes, but the focused window does not surface to the top of the stack.
Edit 2: Fixed. Nothing to do with Ventura. Turns out these windows were being set as topmost. I recently turned on config for
window_topmost
and that reloading spaces/windows sometimes toggles that for windows that were not meant to be floating. Just needed to create a helper script for turning those off on appropriate signals.
I was having this issue too. And I had written a script that would turn off topmost
for stacked windows that weren't floating, but it didn't seem to resolve the problem. Even when querying the affected app it would say that ."is-topmost"
was false
. Turning window_topmost off
and then just setting a signal yabai -m signal --add event="window_created" app="Finder" action="yabai -m window $YABAI_WINDOW_ID --toggle topmost"
per app does seem to work so far. Though you could still make it cleaner writing a script, my point being the global topmost
setting seemed to be culprit.
Also I noticed that when I have turned on mission control displays have separate spaces
then yabai throws error 256 as brew service.
Made a release with the scripting-addition updated for Ventura 13.0.0-13.1.0. Other Ventura issues remain unresolved for now.
Made a release with the scripting-addition updated for Ventura 13.0.0-13.1.0. Other Ventura issues remain unresolved for now.
Doesn't work for me, now nothing works anymore. Keeps asking for Accessibility.
Also, when I reinstall, and I got to this step: yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa"
I keep getting: yabai-msg: failed to connect to socket..
Pretty sad, yabai is completely lost to me.
Made a release with the scripting-addition updated for Ventura 13.0.0-13.1.0. Other Ventura issues remain unresolved for now.
Doesn't work for me, now nothing works anymore. Keeps asking for Accessibility.
Also, when I reinstall, and I got to this step: yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa"
I keep getting: yabai-msg: failed to connect to socket..
Pretty sad, yabai is completely lost to me.
Ok, so I managed to make it work with this, everything is working fine like before:
git clone https://github.com/koekeishiya/yabai.git cd yabai make make sign sudo ./bin/yabai --uninstall-sa sleep 3 sudo ./bin/yabai --load-sa sleep 3 ./bin/yabai
fish_add_path ~/yabai/bin/ ln -s {which yabai} /opt/homebrew/bin/yabai (because I'm lazy, I wanted simple-bar to work, so I just symlinked)
@koekeishiya
I found that it is possible to exclude windows from being managed by the apple WindowManager process simply by not calling NSApplicationLoad()
at initialization. I have experimented with this for the SketchyBar window system recently and it seems to eliminate the XPC connection to the WindowManager and the overhead of reporting window changes to the manager. However, when doing that the ordering relative to managed windows does not seem to work properly, making the border and proxy solution look odd in yabai, but maybe there is a way to make it work for yabai as well?
I need NSApplicationLoad
for some of the event handling to activate. I could probably dig into what exactly that function is doing and figure out what to call at a lower level, but it didn't seem to be worth the effort at the time. I haven't used my Ventura a lot, so maybe things have changed and there would be some sort of measurable benefit in doing so now.
The new
WindowManager
process in Ventura is a bit of a performance monster. It uses so much CPU and all applications report changes in their window layout to it via an XPC connection regardless of wether StageManager is activated or not. I have found that it is OK to unload the process when using yabai, which makes a lot of things faster, battery last longer and stops the apple window manager interfering with yabai:launchctl unload -F /System/Library/LaunchAgents/com.apple.WindowManager.plist
(only works with SIP disabled I guess) I have added this line to the beginning of my
yabairc
.This also stops macOS Ventura from focussing any window on anothers windows destruction, such that yabai would be able to select an arbitrary window without having to deal with the systems default behavior.
Could you edit this, to include a message that says that shortcuts like Minimise(CMD + M
) won't work?
I need
NSApplicationLoad
for some of the event handling to activate. I could probably dig into what exactly that function is doing and figure out what to call at a lower level, but it didn't seem to be worth the effort at the time. I haven't used my Ventura a lot, so maybe things have changed and there would be some sort of measurable benefit in doing so now.
You can activate those events without calling NSApplicationLoad
by calling RunApplicationEventLoop()
instead of starting a CFRunLoop.
It seems I was misremembering. The call to NSApplicationLoad
was necessary to be able to call some functions belonging to NSScreen
, in particular[NSScreen screensHaveSeparateSpaces]
, but this function is not used in yabai, so I suspect it might be possible to just remove that call and everything should continue to work without further changes (with the exception of the border issues you mentioned).
@rsnullptr @attiliosbrana
I had problems with Accessibility on Ventura. I noticed all issues I had, popped up after I ran brew upgrade
(the old rule "if it ain't broke don't fix it" applied here as well). I went back to older versions and for me 5.0.1 works again.
My steps:
brew edit yabai
url "https://github.com/koekeishiya/yabai/releases/download/v5.0.1/yabai-v5.0.1.tar.gz"
# comment the SHA256 or change it into whatever the sha of 5.0.1 is
brew install yabai
Should 13.1 (22C65) work?
I still struggle with yabai: scripting-addition failed to inject payload into Dock.app!
with brew from HEAD
@rsnullptr @attiliosbrana I had problems with Accessibility on Ventura.
that happens, because you didn't sign the new binary
I noticed all issues I had, popped up after I ran
brew upgrade
(the old rule "if it ain't broke don't fix it" applied here as well). I went back to older versions and for me 5.0.1 works again. My steps:
- modify install file
brew edit yabai
- change the download url
url "https://github.com/koekeishiya/yabai/releases/download/v5.0.1/yabai-v5.0.1.tar.gz" # comment the SHA256 or change it into whatever the sha of 5.0.1 is
- install yabai
brew install yabai
I tried it, but I still have the error when I try to load-sa
❯ sudo yabai --load-sa yabai: scripting-addition failed to inject payload into Dock.app!
looks like we have to wait that @koekeishiya update it
Latest release (v5.0.2) works fine on Ventura 13.1 (22C65).
@koekeishiya just updated and can confirm that the problem persists.
Then you are not following the instructions written in the wiki; your system is not configured correctly.
Works for me, even with 5.0.1.
@Uzaaft try running yabai -m space --focus 2
on a different workspace and see if you get any errors.
That works fine for me. No errors. @guidiamond
i had to redo this part in the normal macOS, I remembered that I had to reset my nvram because of my monitor.
# Open a terminal and run the below command, then reboot
sudo nvram boot-args=-arm64e_preview_abi
That worked, thank u so much @luxus
Hey, has anyone any idea to fix apple pay issue?
Latest release (v5.0.2) works fine on Ventura 13.1 (22C65).
If it works fine, I'm curious what is preventing this issue from being closed?
It makes sense to have it open for a while after releasing a Ventura compatible release, in case anyone reports any issues.
Command-number window navigation in Terminal.app stops working if the user ever hides Terminal.app.
Easy to reproduce:
Open Terminal.app, and open two or three windows. It works to use command-1, command-2, etc to move between windows.
Hide Terminal.app (with Terminal > Hide Terminal, or with command-H).
Return focus to Terminal.app. Using command-1, command-2, etc to move between windows is now broken: an audible bell plays, and Terminal.app refuses to navigate between windows.
If it works fine, I'm curious what is preventing this issue from being closed?
That was a reply to the comments saying that the scripting-addition did not work on Ventura.
Command-number window navigation in Terminal.app stops working if the user ever hides Terminal.app.
Easy to reproduce:
- Open Terminal.app, and open two or three windows. It works to use command-1, command-2, etc to move between windows.
- Hide Terminal.app (with Terminal > Hide Terminal, or with command-H).
- Return focus to Terminal.app. Using command-1, command-2, etc to move between windows is now broken: an audible bell plays, and Terminal.app refuses to navigate between windows.
cmd-number is for switching spaces not windows. Maybe i use a different leader key?
Command-number window navigation in Terminal.app stops working if the user ever hides Terminal.app. Easy to reproduce:
- Open Terminal.app, and open two or three windows. It works to use command-1, command-2, etc to move between windows.
- Hide Terminal.app (with Terminal > Hide Terminal, or with command-H).
- Return focus to Terminal.app. Using command-1, command-2, etc to move between windows is now broken: an audible bell plays, and Terminal.app refuses to navigate between windows.
cmd-number is for switching spaces not windows. Maybe i use a different leader key?
Navigate to Terminal > Settings > General and uncheck "Use cmd-1 through cmd-9 to switch tabs." Then cmd-number will switch windows.
I'm running Ventura on a 2019 Macbook Pro (x86). I have SIP completely disabled. I'm having a hard time getting scripting additions to load at all:
>sudo yabai --load-sa Password: could not retrieve task port for pid: 664 yabai: scripting-addition failed to inject payload into Dock.app!
I've tried installing yabai normally, and through HEAD. Most other solutions others have come to this problem were specific to arm64, so I'm a bit unsure on what else to do.
@chinatsudori Did you remember to reconfigure the scripting addition? I just updated (also on x86) and after updating the hash of the yabai binary Everything was working fine again.
SLSTransactionCommit with a 1 as a second argument is equivalent to SLSTransactionCommitUsingMode with a 1 as a second argument, which mean synchronous execution.
I tried this, but it had no effect on the flickering for me.
Ok, now this is interesting... it works for me, but only when I unload apples WindowManager before starting yabai:
launchctl unload -F /System/Library/LaunchAgents/com.apple.WindowManager.plist > /dev/null 2>&1 &
If I leave this process running I indeed still see the flickering as well, but with the process unloaded there is no more flickering.
Without window manager process minimizing windows doesn't work, and I believe it will broke something else too.
scripting addition provided in the latest release (v5.0.2) works fine on Ventura 13.2 (22D49).
I've been too scared to update to Ventura because of yabai but I just got a new mac and 5.0.2 is working perfectly on Ventura 13.2. Excellent work!
Can confirm -- if you've been on git version before, make sure to run uninstall instructions here before installing the release version again
Can confirm -- if you've been on git version before, make sure to run uninstall instructions here before installing the release version again
To whoever follows this (including myself), make sure to keep a backup of your ~/.yabairc
if you want to keep your settings (or just don't delete it at all).
I'm on Ventura 13.2 and I'm still seeing this error with Yabai 5.0.2:
$ yabai -m space --focus 1
cannot focus space due to an error with the scripting-addition.
Any idea what the problem might be?
$ 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.
My configuration:
$ cat ~/.yabairc
yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa"
sudo yabai --load-sa
yabai -m config layout bsp
I'm on Ventura 13.2 and I'm still seeing this error with Yabai 5.0.2:
$ yabai -m space --focus 1 cannot focus space due to an error with the scripting-addition.
Any idea what the problem might be?
$ 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.
My configuration:
$ cat ~/.yabairc yabai -m signal --add event=dock_did_restart action="sudo yabai --load-sa" sudo yabai --load-sa yabai -m config layout bsp
Everything was working for me and now I'm getting this error too. I'm going to have to muck with it and see if I can figure out how I got it to work the first time.
sudo yabai --load-sa
without a password. yabai
myself, manually ran --uninstall-sa
and --load-sa
and different orders just to try to make it work. Nothing worked.$ yabai -m space --focus 2
cannot focus space due to an error with the scripting-addition.
What did I miss?
Hi, I'm also facing the issue of
❯ sudo yabai --load-sa
could not spawn remote thread: (os/kern) invalid argument
yabai: scripting-addition failed to inject payload into Dock.app!
I use the last yabai stable release 5.0.2
Apple Silicon MacBook Air M1, 2020.
macOS 13.2 (22D49)
output 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
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
For Apple Silicon, is arm64e enabled: nvram -p | grep boot-args
boot-args -arm64e_preview_abi
Following the debugging guide from here, when I execute sudo yabai --load-sa
, I get:
EDIT: I tried following this debugging guide now multiple times (also using pkill Dock
as root) and suddenly got logged out of macOS. After logging in again it now seems to work. ^^
scripting addition provided in the latest release (v5.0.2) works fine on Ventura 13.2 (22D49).
Are we ok for the 13.2.1 ?
This is the collective yearly thread for macOS betas. Please use this to discuss instead of opening new issues.