Imager opens and freezes OS

[howley6]

Everytime I open Imager V1.5 on either Raspberry pi 0S 32 bit or Twister Os. The imager opens in a large window and freezes my screen. I then have to reboot by powering off. I am currently using a PI400 4GB.

I have installed OS in a a variety of different ways running them off both an SSD and a SD card.

Anyone have any ideas.

Pi imager works great on Windows 10.

[maxnet]

Imager V1.5 on either Raspberry pi 0S 32 bit or Twister Os.

Did you install it using "apt install rpi-imager" from the official Raspberry Pi repository?
Or in any other way?

[howley6]

Yeah it's always been installed from the terminal as you have described above. It's very strange. Every app I've installed that is known to work on a Debian OS works except pi imager. As I've said I've installed the OS several times! Very strange indeed.

[maxnet]

Other OpenGL applications like "glxgears" from "mesa-utils" package do start without hanging the system?

Executing "xrandr" shows your display reports normal physical dimensions (e.g. 477mm x 268 mm), and not some very small value?

[howley6]

So just tried glxgears and runs fine. I also tried xrandr and these are the results that I have got back.

[howley6]

[maxnet]

Your screenshot does not show.

In case monitor reports physical dimension is low and resolution is high, like normally is only the case with say a high resolution "Retina" laptop screen, it do can happen that Qt sizes the window larger than normal to compensate for high dpi. Still should not hang the system though.

Don't know what is the problem.
Does work fine for others on RPI OS.

[howley6]

It's a strange one, I may just wait until imager v 1.6 comes out. Thank you so much for all your help. I'll get there eventually I hope.

[JJSlabbert]

I had the same issue with vlc and rpi-imager. Check this forum https://forum.videolan.org/viewtopic.php?t=144265
The solution that work for me was to add the line QT_AUTO_SCREEN_SCALE_FACTOR=0 to /etc/environment file
Both vlc and rpi-imager is fixed

[maxnet]

I had the same issue with vlc and rpi-imager.

Same issue as the TS in that it also hangs the system for you?
Or only that the window is larger than expected?
(The latter is expected if your screen has wrong physical dimensions in edid, hang should not happen though).

[howley6]

I had the same issue with vlc and rpi-imager. Check this forum https://forum.videolan.org/viewtopic.php?t=144265
The solution that work for me was to add the line QT_AUTO_SCREEN_SCALE_FACTOR=0 to /etc/environment file
Both vlc and rpi-imager is fixed

I'm going to ask a very silly question. How to add the above line? Is it through terminal etc. I've tried searching but it has left me more confused!

[maxnet]

For testing purpose -to see if it solves your problem first- you can just try setting that env variable while starting rpi-imager from terminal:

QT_AUTO_SCREEN_SCALE_FACTOR=0 rpi-imager

If you confirmed it helps you can make it permanent by adding to /etc/environment
with something like echo 'QT_AUTO_SCREEN_SCALE_FACTOR=0' | sudo tee --append /etc/environment

Also still curious about the screen dimensions reported by xrandr. Your previous screenshot did not upload correctly.

[howley6]

So I tried the first launch from terminal and SUCCESS.

After this I tried the 2nd command and rpi-imager was hanging and froze my pi like before.
`echo 'QT_AUTO_SCREEN_SCALE_FACTOR=0' | sudo tee --append /etc/environment'

I ran xrandr in terminal and here is the result
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680 HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 16mm x 9mm 1920x1080i 60.00*+ 50.00 59.94 1920x1080 60.00 50.00 59.94 24.00 23.98 1280x960 37.88 1280x768 17.09 1280x720 60.00 50.00 59.94 720x576 50.00 720x576i 50.00 720x480 60.00 59.94 720x480i 60.00 59.94 640x480 60.00 59.94

EDIT: Both commands working, Imager is now working.

[maxnet]

16mm x 9mm

The system indeed thinks your screen is very very small.

[howley6]

Strange!! Thank you for all your help in getting this sorted. I can sort the screen through the config.txt file.

[lurch]

If 37cc9e8 has been reverted (see #159 ), does this issue need to be reopened? 🤷‍♂️

[maxnet]

If 37cc9e8 has been reverted (see #159 ), does this issue need to be reopened?

Yeah, probably.

The problem is as follows:

• It would be nice if we were able to disable high DPI scaling in cases the EDID is clearly invalid.
• To determine if the EDID is invalid, we need to query physical screen dimensions. In Qt this information is normally only available once a Q(Gui)Application object is created.
• However we need to decide wheter or not to enable scaling, before it is created.
  We tried to work around this by creating a QApplication object temporarily, querying the dimensions, freeing the temporary QApplication object, and creating a new QApplication object again.
  This works In Debian and Ubuntu. However it seems to confuse Fedora enough that when we ask the operating system to show a file open selection dialog, the desktop environment is not sending the name of the selected file back.

[lurch]

Hmmm, how awkward. Probably one of those annoying situations where you can't tell if it's a bug in QT, a bug in Fedora, a bug only in the version of QT used by Fedora, or a bug somewhere else entirely! 😕

[maxnet]

Hmmm, how awkward. Probably one of those annoying situations where you can't tell if it's a bug in QT, a bug in Fedora, a bug
only in the version of QT used by Fedora, or a bug somewhere else entirely!

Yeah, and Qt has different platform plugins.
May be using the Xcb protocol on Debian/Ubuntu and Wayland on Fedora, etc.

Anyway, the bad EDID workaround -now reverted- was a bit quirky anyway.
Hopefully there are not that many monitors out there with EDID that is so incorrect. The monitor of the TS claims to be physically smaller than a postage stamp.
And if workarounds for that do are desired it may be better to have them at the operating system side, than in our application.
I may have been too quick with wanting to fix this, without taken into account possible side effects (as demonstrated by the problem starting to show with Fedora).
So perhaps this should be willnotfix instead.

[lurch]

Hopefully there are not that many monitors out there with EDID that is so incorrect. The monitor of the TS claims to be physically smaller than a postage stamp.

Yeah the EDID reporting 16mm x 9mm probably means that the monitor-manufacturer put the aspect ratio (16:9) in the wrong field or something? (Only a guess, I know nothing about EDIDs 😉 )

[CollinChaffin]

Also doing this on Windows 7x64 much of the time, opens and hangs.

[tdewey-rpi]

Closing this as stale - we've had no further community update since '22.

If we're seeing this against v1.8.5, that deserves a new issue.