[BUG] Imager v. 1.8.5. opens in a blank screen window

[Rhuax]

I installed version 1.8.5. and whenever I open it I have a completely blank screen window:

Desktop (please complete the following information):

• OS: Windows 7 Home Premium
  Are you using OS Customisation?
  No
  Additional context
  I also tested v. 1.8.4. and it behaves equally

[maxnet]

Imager uses OpenGL graphics acceleration.
You do are using Imager locally (not through VNC or similar), and other GPU accelerated programs such as games are behaving correctly on your system?

[Rhuax]

I'm using Imager locally and I do not run (and never did on this PC) any kind of games or other GPU accelerated software.

[tdewey-rpi]

Thanks for the report, @Rhuax.

Your report made me go digging a little deeper into how Qt falls back from failing to operate OpenGL, and I found something I didn't expect - lots of reports of failure and instability, including on Windows devices that have some form of GPU acceleration but fail to offer something equivalent to OpenGL:ES 2.0 or DirectX 9:

https://stackoverflow.com/questions/27704529/deploying-qt5-on-windows-without-hardware-acceleration

I can't immediately see a good path forward, but I'll try to find some time to look into a more graceful fallback mechanism. In the meantime, depending on your level of comfort, you may want to explore environment variables to force Qt5 to use software rendering.

[joergschultzelutter]

@tdewey-rpi - I experienced the same issue on MacOS. You can restore an almost-complete version of the Imager by doing the following things:

• set the QT_QUICK_BACKEND=software environment variable
• then open the Imager via command line by running open Raspberry\ Pi\ Imager.app/

Most of the buttons will still be gone but if you navigate with caution, one can use the Imager for writing images to an SD card. Not sure if there is another env setting which might remove the remaining obstacles.

[tdewey-rpi]

@tdewey-rpi - I experienced the same issue on MacOS. You can restore an almost-complete version of the Imager by doing the following things:

• set the QT_QUICK_BACKEND=software environment variable
• then open the Imager via command line by running open Raspberry\ Pi\ Imager.app/

Most of the buttons will still be gone but if you navigate with caution, one can use the Imager for writing images to an SD card. Not sure if there is another env setting which might remove the remaining obstacles.

Thanks for the comment, @joergschultzelutter.

I would indeed expect your workaround to be operational - though I'm surprised you had any rendering issues (as we don't directly drive a 3D API inside the UI).

What's confounding the path forward here is that I would have expected Qt to perform some sort of routine to determine if the host OS was able to support the accelerated backend, and then if that failed, automatically revert to the software backend. That isn't happening - and that isn't something I would generally expect a project like rpi-imager to have to deal with, instead relying on the UI toolkit to do, well, UI toolkit things.

[joergschultzelutter]

Thanks @tdewey-rpi . For illustration purposes - this is the Imager without the env setting:

And this is how things look like if you set that environment variable:

As you can see, most of the buttons/dropdowns are no longer visible. Yet, they can still be used if you know where they are located at.

FWIW, I'm running MacOS Sonoma and had never any of these issues prior to the OS update.

[tdewey-rpi]

@joergschultzelutter Apologies - perhaps I misread - are you seeing this on an Apple-supported macOS device running Sonoma without any exotic configuration?

[joergschultzelutter]

@tdewey-rpi - I'm running a vanilla version of Sonoma without any exotic kernel extensions etc.

For completeness sake - I had similar issues with this German app: https://apps.apple.com/de/app/ausweisapp-bund/id948660805#?platform=iphone. The symptoms were exactly the same: fortunately, the developers hinted me on setting that environment variable - which then solved the issue. Other reviews on the App store show exactly the same behavior which makes me believe that this is not an isolated issue. As @Rhuax runs the imager on Windows, I have to assume that the issue in question is not related to MacOS.

[tdewey-rpi]

@tdewey-rpi - I'm running a vanilla version of Sonoma without any exotic kernel extensions etc.

For completeness sake - I had similar issues with this German app: https://apps.apple.com/de/app/ausweisapp-bund/id948660805#?platform=iphone. The symptoms were exactly the same: fortunately, the developers hinted me on setting that environment variable - which then solved the issue. Other reviews on the App store show exactly the same behavior which makes me believe that this is not an isolated issue. As @Rhuax runs the imager on Windows, I have to assume that the issue in question is not related to MacOS.

I'm specifically trying to determine if this issue is being reported against a commonly-deployed and currently-supported platform.

I have not had any other reports of a blank screen on Sonoma reported against a currently-supported Apple device, and I would be extremely surprised to encounter a situation where macOS was unable to offer an acceleration-friendly rendering pipeline.

Can you confirm the hardware you're running on?

[joergschultzelutter]

I just tried to verify the behavior on my workplace Macbook - to no avail. Seems as if the issue is related to my private 2015 MBP (using OCLP).

[tdewey-rpi]

@joergschultzelutter Thanks for confirming.

Unfortunately OCLP would indeed count as an 'exotic' modification - essentially, you've managed to convince Sonoma to run on hardware Apple do not support it on.

As such, your report matches that of the OP fairly well - a device that is unable to offer a hardware accelerated UI running a program that expected to find one.

As before - there isn't a great path forward here. I'm reticent to commit time to supporting rpi-imager on operating systems that the vendor does not support, not least because in the event of an immovable bug we would have no path forward - either in terms of requesting support from Qt or from the OS vendor.

If you still observe this issue on Monterey (macOS 12), I'd consider that a different bug - because it would be a version of macOS running on hardware it claims to support that is still receiving security updates.

[nfriacowboy]

Just a workaround for those running OCLP, install a Linux distro on a VM and Raspberry Pi Imaginer (v1.8.5) works. (Tested with Pop! on Parallels)