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

[staff009]

On Win7 these two environment vars disabled OpenGL and I could use the Raspberry Pi Imager 1.8.5.

QT_OPENGL = angle
QT_ANGLE_PLATFORM = warp

from:
https://raspberrypi.stackexchange.com/questions/137481/how-to-run-raspberry-pi-imager-in-old-windows-computer-without-opengl-2-0-or-wit

[joergschultzelutter]

@staff009's suggestion improves the situation a little bit; the buttons and dropdowns are still gone, but at least the proper text from the dropdown menu shows up if you know where it is located.

To summarize, my machine's .bash_profile contains

export QT_QUICK_BACKEND=software
export QT_OPENGL=angle
export QT_ANGLE_PLATFORM=warp

If I open the imager via command line, those settings restore 90% of its functionality. Thanks!

[staff009]

@joergschultzelutter, on Win7 with no GPU and a Intel Core Duo T9400 CPU it just looks fine. I had the impression all buttons and dropdown menus seemed genuine.
Without the env vars the imager shows the content of background window, in this case the device manager:

With the env vars, everything OK:

[tdewey-rpi]

I must thoroughly applaud you, @joergschultzelutter and @staff009, for identifying a solid workaround.

I can't see a clean way to have Imager automatically make use of this, without having Imager gain some more concrete knowledge of the host operating system. As I've said before, I expected Qt to handle this entirely internally - that it has not is disappointing, but also not entirely unexpected - as Windows 7 is no longer actively supported by the Qt project.

I'm going to do two things from here:

First, I'm going to pin this issue as an excellent example of the community working together to provide a workaround where a code change is impractical.

Second, I'm going to close the issue as Won't fix, because I can't see a way to fix it from inside the Imager codebase in a clean manner.

[shindekokoro]

This "bug" is present of all 1.8.x releases for macOS Sonoma. Resolution of loading through terminal above does allow some visual functionality. The issue is not present for 1.7.x release

[lurch]

@shindekokoro What hardware are you running macOS Sonoma on?

[tdewey-rpi]

Echoing @lurch 's comment, the only macOS systems we have had this reported on are those where the user has circumvented an Apple restriction to run a newer OS on unsupported hardware.

I can confirm from my own testing that v1.8.5 renders and works correctly on Sequoia* on a macBook Pro M1 (2021).