Black screen on client when Mac server has no GPU acceleration

[gbelmont22]

First, I want to say I love NoMachine.  I use it for my RPi, Mac, Linux and even a few Windows boxes.  It’s a fantastic piece of work.  Second, the problem I am about to describe is NOT a problem with NoMachine per se, but I’m hoping there is a work-around in NoMachine that I can use…

Here is the background, without which, my question won’t make any sense…

I have a 2019 MacBook Pro that seems to have developed a problem with one or both of the GPUs (or something very closely associated with the GPUs).  I have been experiencing random crashes of the macOS window server and GPU related Kernel Panics when booting the system.  These problems have only increased in frequency over the last few weeks until I am no longer able to boot the system at all.  I’ve done all the normal troubleshooting like resetting the SMC and the NVRAM; I re-installed the OS; I even installed a clean copy of macOS to a USB drive…  None of these things help – except when I use ‘Safe-Boot’ (hold the Shift key when starting the Mac).

Performing a ‘Safe-Boot’ works perfectly – and it was very obvious that this was because ‘Safe-Boot’ will only load the most basic drivers required to manage the system.  The kernel extensions (kext) for the Intel and/or Radeon graphics are skipped and so my system would function perfectly but without any graphics acceleration.  For example, launching a program like iMovie will politely tell you that your graphics are unsupported, and screen savers are awful (if they work at all).  But I could live with these deficiencies because most of what I do doesn’t require super-crazy graphics anyway.

After backing up my system, and feeling like I had little to lose, I did some isolation work and discovered that if I removed the following list of Kext files from /System/Library/Extensions the system would boot normally and operate just fine (except for the lack of graphics acceleration).

• AppleIntelKBLGraphics.kext
• AppleIntelKBLGraphicsFramebuffer.kext
• AppleIntelKBLGraphicsGLDriver.bundle
• AppleIntelKBLGraphicsMTLDriver.bundle
• AppleIntelKBLGraphicsVADriver.bundle
• AppleIntelKBLGraphicsVAME.bundle
• AMDRadeonX4000.kext
• AMDRadeonX4000GLDriver.bundle
• AMDRadeonX4000HWServices.kext

This seems to jive with the Windows server crashes and kernel panics pointing to the graphics subsystem, and lines up with my model of Mac which has an Intel UHD Graphics 630 (which I think is Kaby Lake hence the KBL) and Radeon Pro 560X (Polaris 21 / Generation 4?).

Now I fully understand this is not a ‘suggested’ way of operating my notebook (somewhere in cyberspace an Apple kernel developer is having a fit reading about this mutilation of their hard work).  Frankly, if Apple handed out new motherboards like candy I would prefer to have it repaired.  But the repair costs are probably higher than the value of the notebook, so I’m trying to make lemonade out of lemons…

So that’s the background.  Here is where NoMachine comes in…

When running NoMachine 8 Server on the afflicted MacBook Pro and attempting to connect from my NoMachine 8 client (running on an older Mac Mini) the client will only display a black screen.  I know things are working because I can control the mouse on the MacBook Pro – but the client isn’t rendering the desktop at all.  The first thing that occurs to me is, “Ah well, of course, NoMachine is probably relying on the graphics acceleration APIs exposed via the Kext files that I just deleted.”  So the first thing I tried was to fiddle with the Use hardware encoding and Use acceleration for display processing settings on the server, but alas, they did not help.  Interestingly, plugging a physical HDMI monitor into the MacBook Pro does help and the connected client starts showing content as expected but the performance is terrible (and this isn’t really the most practical solution).

If indeed NoMachine is looking at a screen buffer or kernel driver that doesn’t exist, then this feels similar in nature to running a headless server, where NoMachine would have to ‘create’ a display to send to the client.  I think I have seen anecdotal references to this ‘headless’ problem in relation to Linux/RPi servers, but I have no direct experience.  I did not see anything about ‘headless’ problems for Mac, probably because it should never happen under normal operation.  Alternately, perhaps I’ve created a bizarre scenario that the NoMachine developers never expected could happen (on a normal functioning Mac) and a uncaught exception is being thrown somewhere.

So I am hoping there might be a setting (maybe not exposed in the UI) that might be my magic bullet.  Is there a way to ‘force’ the server to send the screen to a client when the Mac graphics acceleration has been removed/deleted and is unavailable?

[Britgirl]

Hi gbelmont22,

thanks for sharing your story with us. We feel your pain 😛

As much as we would love to be able to “create a display” on macOS, which would be what we call a “virtual display” in NoMachine jargon, it’s not because it’s a limitation of NoMachine, it’s because we can’t even if we wanted to. As you probably know already, given you’re running NoMachine on Linux, a virtual display (so, headless in your particular case) is possible with NoMachine for Linux products. When NoMachine can’t find the X server on a Linux host, NoMachine will create its own for you. This is not possible with macOS or Windows.

When you write “plugging a physical HDMI monitor into the MacBook Pro does help and the connected client starts showing content as expected but the performance is terrible”, are you referring to the NoMachine session?

What macOS version are you using, it would be useful to know.

You could try inserting the following key in the node.cfg file DisplayServerExtraOptions "-nostreamgrab" which disables the method we use to capture the screen in more recent Mac versions and enables the legacy method. We can’t guarantee that it will work, but it’s worth a try.

Let us know 🙂

[gbelmont22]

Thanks for the reply.  I am currently running Catalina 10.15.7 which is a little behind the times.  I did try some newer versions of macOS installed to a thumb drive, but none of them helped with my underlying GPU problems and so I never progressed any further – so I can’t say if NoMachine behaves any differently on any newer version of macOS.

Now to expose my ignorance, could you kindly direct me to the node.cfg file on Mac?  It’s probably staring me in the face…

[gbelmont22]

Ok, as usual, 2 minutes after my last post I was able to locate the node.cfg in

/Applications/NoMachine.app/Contents/Frameworks/etc/

I tried adding the DisplayServerExtraOptions key as suggested and the effect was a step in the right direction. The client now renders the top-left corner of the desktop.  The best way I can describe it would be to think of the client as ‘cropping’ the top-left of desktop and scaling it up to fill the entire client window/display area.  This means the right side and bottom of the desktop are completely missing on the client.  However, the mouse tracking is still correct so clicking a menu requires placing the mouse at the ‘true’ position instead of the overly-large ‘rendered’ position.  I tried fooling around with various display options on the client but no joy.  I also tried connecting from two different clients (my Mac Mini and my RPi) both rendered the desktop identically ‘cropped’, which tells me again this is related to how the server is ‘transmitting’ the data.

Still, that was a pretty impressive first try.  I’m open to further suggestions! 🙂

 

[gbelmont22]

Ah ha!  Just to follow up my previous posts (again).  After (even more) fooling around with the client I discovered if I set the Display settings to ‘Scale to window’ and then click ‘change settings’ I can enter a custom resolution for the client.  Bingo!

Initially I tried 2880 x 1800 (which is the native resolution of the Retina display), but that produced an overly-small scaled output.  Assuming that I needed to use half of that to compensate for the Retina display, I proceeded to try 1440 x 900, which was too far in the other direction.

In the end, the Goldilocks values seem to be 1728 x 1080 (which is 60% of the native resolution – no idea why – feel free to educate me here!).

I also tried a second client (connecting from the RPi to the Mac), which seemed to work equally well.

So I think, mission accomplished! – although I would continue to welcome any comments or suggestions.

[Britgirl]

So that’s certainly good news. Thanks for providing feedback and do keep us updated if things change 🙂

[Author]

Posts