Native X11 support on Apple Silicon

[markiv810]

I am used to running apps via macports with Xquartz (X11) on Macs. I have been using macports for over 10 years. Now, since the shift to arm (Apple Silicon) I cannot install apps via macports due to lack of compatible apps and compatible libraries.

These apps mactex and various other linux based scientific apps that can/could be installed via macports (that are not available otherwise) are very helpful for undergrad/grad students pursuing engineering, equally helpful for student pursuing M.S./ Ph.D in basic sciences and mathematics. I think this is a very important issue and Apple should try and make sure that native X11 support is available on Apple Silicon based Macs asap.

 

[cal6n]

X11 hasn't been officially supported since Mountain Lion, I believe.

I used to use fink to run unix binaries rather than macports. I don't use them any more, so I'm out of the loop. I believe fink is waiting for an update to support Big Sur. As for Apple Silicon, who knows? But unix on Arm has been around for decades, so it's probably only a matter of time...

*edit* MacTeX 2020 already supports Arm and is available as a standalone:

MacTeX - TeX Users Group

 

[jdb8167]

Have you tried? Most of the ports I’ve tried are Arm64 and have worked fine. There is a report on these forums that Xquartz works fine. I don’t have much use for X11 but I’ll try and install it.

 

[haralds]

Brew has a cask install that is still Rosetta2. They're working to port all the pieces.

 

[cal6n]

Macports latest version's change log includes "Allow building ports for x86_64 on arm64 systems if they don't support arm64."

macports-base/ChangeLog at release-2.6 · macports/macports-base

The MacPorts command-line client. Contribute to macports/macports-base development by creating an account on GitHub.

github.com

 

[markiv810]

X11 hasn't been officially supported since Mountain Lion, I believe.

I used to use fink to run unix binaries rather than macports. I don't use them any more, so I'm out of the loop. I believe fink is waiting for an update to support Big Sur. As for Apple Silicon, who knows? But unix on Arm has been around for decades, so it's probably only a matter of time...

*edit* MacTeX 2020 already supports Arm and is available as a standalone:

MacTeX - TeX Users Group

While mactex can be installed on M1 based Macs, the support is via Rosetta 2. https://www.tug.org/mactex/aboutarm.html next year we shall be having native M1 (Apple Silicon) support.

While X11 support discontinued by Apple, we had option of xquartz on Mac. Xquartz has not updated since ages (29th October 2016), I also tried install alternative as mentioned in https://www.xquartz.org/releases/index.html but to no avail. I sincerely hope that it's only a matter of time.

 

[markiv810]

Macports latest version's change log includes "Allow building ports for x86_64 on arm64 systems if they don't support arm64."

macports-base/ChangeLog at release-2.6 · macports/macports-base

The MacPorts command-line client. Contribute to macports/macports-base development by creating an account on GitHub.

github.com

I have tried installing via macports but due to unavailability of many libraries (ports) for arm64 I have not been able to install many apps. While I am able to install many apps that do not require X11 but many that do cannot be installed or run currently like xplot, xpdf, etc.

 

[jdb8167]

I have tried installing via macports but due to unavailability of many libraries (ports) for arm64 I have not been able to install many apps. While I am able to install many apps that do not require X11 but many that do cannot be installed or run currently like xplot, xpdf, etc.

I've had a lot of luck building various library requirements through their GitHub or other repositories. But yeah, it isn't perfect yet. It's pretty amazing that a lot stuff is already Arm64 compatible.

 

[markiv810]

Macports latest version's change log includes "Allow building ports for x86_64 on arm64 systems if they don't support arm64."

macports-base/ChangeLog at release-2.6 · macports/macports-base

The MacPorts command-line client. Contribute to macports/macports-base development by creating an account on GitHub.

github.com

I am using the latest version of 2.6.4 while I am able to install some apps, the other apps I am not able to require libraries that have not yet been ported to arm64. I think it should only be a matter of time. Meanwhile since there has been no update in xquartz since 29th October 2016, Apple should again have their own version of X11 as they used to back in the day. Linux is quite popular on the arm64 platform, there also it should only be a matter of time before X11 is ported to Mac arm64.

 

[palter]

X11 in MacPorts is functional and native on the M1. (I should know, I did some of the work to get it running.)

sudo port install xorg

MacPorts equivalent of Xquartz.app is X11.app.

 

[markiv810]

Have you tried? Most of the ports I’ve tried are Arm64 and have worked fine. There is a report on these forums that Xquartz works fine. I don’t have much use for X11 but I’ll try and install it.

I have tried the small apps like axel, I am able to install but I also need gnuplot/ xplot, which cannot be used without X11.

 

[markiv810]

Brew has a cask install that is still Rosetta2. They're working to port all the pieces.

After I could not install the apps I wanted to using MacPorts I tried brew, but as it was via Rosetta2, I think I should wait till brew has native support for m1 (Apple Silicon).

 

[markiv810]

X11 in MacPorts is functional and native on the M1. (I should know, I did some of the work to get it running.)

sudo port install xorg

MacPorts equivalent of Xquartz.app is X11.app.

I did install xorg, but could not get it to work. I am looking for documentation so that I can use the installed xorg. What did you have to do to get it working, could you please point me in the right direction.

 

[Gnattu]

I think I should wait till brew has native support for m1 (Apple Silicon).

I'm using brew and it is native.
brew does not officially support arm64 atm, but you can install it natively. You can even have 2 brew installed(x86 and arm) on your system in case the formulas does not compile in native.

 

[markiv810]

I'm using brew and it is native.
brew does not officially support arm64 atm, but you can install it natively. You can even have 2 brew installed(x86 and arm) on your system in case the formulas does not compile in native.

I will try and install brew again today.

 

[Gnattu]

I did install xorg, but could not get it to work. I am looking for documentation so that I can use the installed xorg. What did you have to do to get it working, could you please point me in the right direction.

You have to logout and then log back in.
I can confirm the X11 from MacPorts is arm64 native

 

[markiv810]

You have to logout and then log back in.
I can confirm the X11 from MacPorts is arm64 native
View attachment 1689993

Dude, I just checked the folder /Applications/Macports and I found that X11 was already there, now all I have to do is set path in the terminal so that when I give command in Terminal it launches X11 that exists in the /Applications/Macports folder.

The X11 is installed in /usr and I have to set path by creating softlinks. Just a query where do I have to set paths.

 

[Gnattu]

The X11 is installed in /usr and I have to set path by creating softlinks. Just a query where do I have to set paths.

This is somehow strange as MacPorts install them to /opt/local as default

A side note is that MacPorts overrides the $DISPLAY set by launchd, and it will cause problems for X11 forwarding. You can edit your .zprofile and comment out the export DISPLAY=:0 added by MacPorts.

For some reason xauth does not work with modern Linux, so you have to use ssh -Y or addForwardX11Trusted yes to your ssh_config if you want to use X11 forwarding.

 

[markiv810]

This is somehow strange as MacPorts install them to /opt/local as default

A side note is that MacPorts overrides the $DISPLAY set by launchd, and it will cause problems for X11 forwarding. You can edit your .zprofile and comment out the export DISPLAY=:0 added by MacPorts.

For some reason xauth does not work with modern Linux, so you have to use ssh -Y or addForwardX11Trusted yes to your ssh_config if you want to use X11 forwarding.

Thanks a lot man, I shall try this in the evening.

 

[markiv810]

X11 in MacPorts is functional and native on the M1. (I should know, I did some of the work to get it running.)

sudo port install xorg

MacPorts equivalent of Xquartz.app is X11.app.

Btw, I looked around in the /usr folder and subsequent sub-folders and found Xquartz in /opt/local/bin and running the Xquartz via terminal launches X11. I just commented out the export DISPLAY=0 in .zprofile and everything was ok. I don't know why I did not remember that zsh was the default in Big Sur, I have been so used to bash being default that it never occurred to me that in Catalina too zsh was default shell. Thanks to @Gnattu for your help.

 

[mr_roboto]

X11 in MacPorts is functional and native on the M1. (I should know, I did some of the work to get it running.)

sudo port install xorg

MacPorts equivalent of Xquartz.app is X11.app.

Thanks for this!

Unfortunately, I'm having some problems which make it a better choice to run the ancient x86 binary release from xquartz.org through Rosetta. I have no idea if it's easy to track down what might be causing this, and I know all open source is volunteer effort, but for what it's worth here's what I'm seeing:

1. If Preferences -> Output -> Colors is set to anything but 256 Colors, I see weird performance issues in the main X11 program I care about, the text editor 'nedit'. This affects operations like switching from one tab to another, text selection, almost anything really. Sometimes things draw very quickly, other times it bogs down and they don't, and this is variable from moment to moment. This is very noticeable because normally nedit is a lightweight and fast editor by modern standards (it's pretty old school).

2. When Preferences -> Output -> Colors is set to 256 Colors, X11.app frequently crashes. For example, I was able to reproducibly crash by launching nedit from terminal.app with no options, control-O to open one text file, then control-O again to open another text file. Upon picking the second file, X11.app always crashes.

What's incredibly weird is that these crashes go away when the colors preference is set to thousands, millions, or From Display. So I can have normal speed, or crashes.

 

[leman]

I am used to running apps via macports with Xquartz (X11) on Macs. I have been using macports for over 10 years. Now, since the shift to arm (Apple Silicon) I cannot install apps via macports due to lack of compatible apps and compatible libraries.

These apps mactex and various other linux based scientific apps that can/could be installed via macports (that are not available otherwise) are very helpful for undergrad/grad students pursuing engineering, equally helpful for student pursuing M.S./ Ph.D in basic sciences and mathematics. I think this is a very important issue and Apple should try and make sure that native X11 support is available on Apple Silicon based Macs asap.

I haven't encountered a single scientific package that has a hard requirement on X11, with an exception of some R packages (that can usually be configured around it). Also, as others have mentioned, LaTeX distributions don't need X11 and work very well on Apple Silicon Macs.

 

[markiv810]

I haven't encountered a single scientific package that has a hard requirement on X11, with an exception of some R packages (that can usually be configured around it). Also, as others have mentioned, LaTeX distributions don't need X11 and work very well on Apple Silicon Macs.

I have got the X11 to work anyhow, that is not an issue anymore. The only issue is lack of supporting libraries. Till then I shall be using my old setup at office.

 

[palter]

Thanks for this!

Unfortunately, I'm having some problems which make it a better choice to run the ancient x86 binary release from xquartz.org through Rosetta. I have no idea if it's easy to track down what might be causing this, and I know all open source is volunteer effort, but for what it's worth here's what I'm seeing:

1. If Preferences -> Output -> Colors is set to anything but 256 Colors, I see weird performance issues in the main X11 program I care about, the text editor 'nedit'. This affects operations like switching from one tab to another, text selection, almost anything really. Sometimes things draw very quickly, other times it bogs down and they don't, and this is variable from moment to moment. This is very noticeable because normally nedit is a lightweight and fast editor by modern standards (it's pretty old school).

2. When Preferences -> Output -> Colors is set to 256 Colors, X11.app frequently crashes. For example, I was able to reproducibly crash by launching nedit from terminal.app with no options, control-O to open one text file, then control-O again to open another text file. Upon picking the second file, X11.app always crashes.

What's incredibly weird is that these crashes go away when the colors preference is set to thousands, millions, or From Display. So I can have normal speed, or crashes.

I am seeing similar performance problems with the application I support. (It's a 30-year old emulator for Symbolics Lisp Machines.)

When I first got X running native, there were no such performance issues. Something changed when MacPorts updated the version of X that they're distributing. I haven't yet been able to track down the cause. If I ever find it, I'll submit a PR to fix it.

 

[rlhamil]

X11 in MacPorts is functional and native on the M1. (I should know, I did some of the work to get it running.)

sudo port install xorg

MacPorts equivalent of Xquartz.app is X11.app.

quartz-wm has a binary-only library (libquartz-wm-ds.apsl.dylib), apparently with Dock interfaces. Was that recompiled for Apple Silicon? Or is quartz-wm in its entirety running through Rosetta 2? (assuming a native binary cannot use an emulated dylib)

edit: never mind, I saw "The functionality provided by this binary has been merged into libXplugin on newer versions of OS X"