Okular and other Qt applications do not create any visible windows

[johnfoot]

Hi there,

Since the mid-may stable update, I’ve been experiencing that okular, kvantummanager, qt6ct, and maybe other qt-related applications launch, but I can’t see any window afterwards.

For example, okular only prints this to the terminal:

QAbstractAnimation::pause: Cannot pause a stopped animation

The 5.1.1 static build and manjaro package binary of telegram-desktop prints this:

QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
QXcbSystemTrayBackingStore: Failed to create Picture with format 1e2 for window 340000c, error code 9
QRhiGles2: Failed to make context current. Expect bad things to happen.
Failed to create QRhi for QBackingStoreRhiSupport
QOpenGLFramebufferObject: Framebuffer incomplete attachment.
QOpenGLFramebufferObject: Framebuffer incomplete attachment.
QOpenGLFramebufferObject: Framebuffer incomplete attachment.
QOpenGLFramebufferObject: Framebuffer incomplete attachment.
QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.

I have read this thread, but in my case, the applications do not segfault: they run but do not show anything.

inxi -xxx -S -G output

System:
  Host: shibboleth Kernel: 6.6.32-1-MANJARO arch: x86_64 bits: 64
    compiler: gcc v: 14.1.1 clocksource: tsc
  Desktop: i3 v: 4.23 with: i3bar vt: 7 dm: LightDM v: 1.32.0
    Distro: Manjaro base: Arch Linux
Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
    vendor: Gigabyte driver: i915 v: kernel arch: Gen-7.5 ports: active: none
    empty: HDMI-A-1,HDMI-A-2,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0412
    class-ID: 0300
  Device-2: NVIDIA GM107GL [Quadro K620] vendor: Hewlett-Packard
    driver: nvidia v: 550.78 arch: Maxwell pcie: speed: 5 GT/s lanes: 16 ports:
    active: none off: DP-1 empty: DVI-I-1 bus-ID: 01:00.0 chip-ID: 10de:13bb
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.13 driver: X: loaded: nvidia
    gpu: nvidia,nvidia-nvswitch display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2160x3840 s-dpi: 162 s-size: 338x605mm (13.31x23.82")
    s-diag: 693mm (27.28")
  Monitor-1: DP-1 note: disabled model: Dell S2721QS serial: HSSLM43
    res: 2160x3840 hz: 60 dpi: 163 size: 336x597mm (13.23x23.5")
    diag: 685mm (27") modes: max: 3840x2160 min: 640x480
  API: Vulkan v: 1.3.279 layers: 5 surfaces: xcb,xlib device: 0
    type: discrete-gpu driver: nvidia device-ID: 10de:13bb
  API: OpenGL Message: Unable to show GL data. glxinfo is missing.

Thanks

EDIT: Here is a summary of info spread across this thread:

• the bug seems to be restricted only to qt6 applications. qt5ct and qt5-based apps such as vlc 3.0.20 launch as expected
• I did not find anything suspect inside the Xorg or journald logs
• I tried to remove my ~/.cache folder from a tty after logging out from my graphical session
• Added the output of telegram-desktop inside this post

[andreas85]

Do you have any AUR-packages ?

[johnfoot]

Yes, I use this driver, but I’d not guess it could mess with qt-related things.

[johnfoot]

Maybe this info is a hint: qt5ct launches right (opens a window), while qt6ct does not.

When I launch the apps from a terminal, it hangs (= the application does not terminate), as expected I guess… I just do not see anything.

[cscs]

Do you have something like (in /etc/environment or elsewhere)

QT_QPA_PLATFORMTHEME=qt5ct

???

I might suggest instead something like

QT_QPA_PLATFORMTHEME=qt5ct:qt6ct

Which should cover both qt5 and qt6 applications.
(by trying qt5ct first and then qt6ct)

Similarly you may try as a one line execution. for example

QT_QPA_PLATFORMTHEME=qt6ct okular

[cscs]

@johnfoot

Unfortunately, I had tried changing the value of this variable to qt6ct (was qt5ct inside ~/.xprofile)

Unless you do something to source that … changes wont take effect until you reboot (or at least log out and in again).

@johnfoot

launching okular using this one line execution, without success

If you tried to launch the application with the environment variable prefacing it then I guess I would only suggest to make sure qt6ct settings are configured.

[johnfoot]

@cscs

If you tried to launch the application with the environment variable prefacing it

Yes, this is what I meant, sorry for the confusion. I tried launching okular using both values: the first time using the ~/.xprofile user session value, then with the env variable prefacing okular.

@cscs

then I guess I would only suggest to make sure qt6ct settings are configured.

qt6ct doesn’t load either… should I remove my existing config inside ~/.config/qt6ct ?

[cscs]

@johnfoot

qt6ct doesn’t load either…

Oh right.

You might need to remove the variable then?

QT_QPA_PLATFORMTHEME="" qt6ct

Or maybe unset it like

unset QT_QPA_PLATFORMTHEME && qt6ct

[johnfoot]

Still no luck

I get these message when launching qt6ct. Doesn’t look too bad to me

QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix
Configuration path: "/home/raphael/.config/qt6ct"
Shared QSS paths: QList("/home/raphael/.local/share/qt6ct/qss", "/usr/local/share/qt6ct/qss", "/usr/share/qt6ct/qss", "/var/lib/snapd/desktop/qt6ct/qss")
Shared color scheme paths: QList("/home/raphael/.local/share/qt6ct/colors", "/usr/local/share/qt6ct/colors", "/usr/share/qt6ct/colors", "/var/lib/snapd/desktop/qt6ct/colors")

[cscs]

Drat.

I note all your problem examples are qt6. So it feels like the right direction.

Well. Except kvantummanager which does not exist in the repos or the AUR.
Typo? If it is indeed a super-alien then maybe it is creating incompatibilities.

[johnfoot]

@cscs

Well. Except kvantummanager which does not exist in the repos or the AUR.
Typo? If it is indeed a super-alien then maybe it is creating incompatibilities.

Oh I thought that the kvantummanager binary was provided by one of these packages that are installed on my system, but I might be wrong:

$ pacman -Qs kvantum
local/kvantum 1.1.1-1
    SVG-based theme engine for Qt6 (including config tool and extra themes)
local/kvantum-manjaro 0.13.5+5+g0179d45-4
    Maia and Breath themes for Kvantum
local/kvantum-qt5 1.1.1-1
    SVG-based theme engine for Qt5
local/kvantum-theme-matcha 20190810-3
    Matcha theme for Kvantum

[cscs]

@johnfoot

kvantummanager

Sorry, I took that to mean a package.
Yes the kvantummanager binary is provided by the kvantum package.
(and is also qt6)
So nevermind about it being foreign.

[johnfoot]

Would it be of any help to try to reinstall some qt6 packages ?

Is there some kind of X11 journal I could look into for window spawning failure ?

[cscs]

@johnfoot

Is there some kind of X11 journal

I would normally use journalctl for most lookups.

But Xorg will have its own logs.

If it is rootless then its probably in ~/.local/share/xorg/Xorg.log

Otherwise in /var/log/Xorg.0.log (or related earlier files in same directory).

[Aragorn]

@johnfoot

Would it be of any help to try to reinstall some qt6 packages ?

Negative. UNIX isn’t Windows — it has no Registry.

Reinstalling packages only causes the already installed versions to be overwritten, and that’s not going to change anything when the cause of the problem lies with the user-specific configuration files in your home directory — commonly under ~/.config and ~/.local/share, although corrupted files in ~/.cache may (and often do) also throw a spanner in the works.

This sort of problems can often be remedied by logging out of the GUI environment completely, logging in at a tty, and then emptying ~/.cache.

[johnfoot]

@cscs

I would normally use journalctl for most lookups.

@cscs

Otherwise in /var/log/Xorg.0.log (or related earlier files in same directory).

I see nothing in those logs unfortunately

@Aragorn

This sort of problems can often be remedied by logging out of the GUI environment completely, logging in at a tty, and then emptying ~/.cache.

Thanks for the suggestion. Just to be sure: is it OK if I still have my lightdm greeter after exiting my session before switching to a tty or do I have to kill a process ?

I just tried to remove the cache folder from a tty after switching from the greeter screen, without success. After entering my graphical session, there were some new directories inside the cache directory, among which a qtshadercache-x86_64-little_endian-lp64/ directory.

[Aragorn]

@johnfoot

Just to be sure: is it OK if I still have my lightdm greeter after exiting my session before switching to a tty or do I have to kill a process ?

For this purpose, it should be okay to keep it running.

@johnfoot

I just tried to remove the cache folder from a tty after switching from the greeter screen, without success. After entering my graphical session, there were some new directories inside the cache directory, among which a qtshadercache-x86_64-little_endian-lp64/ directory.

That is possible, yes.

[johnfoot]

Thanks for the confirmation. I still had a Xorg process running while I was inside the tty, but I guess this is expected since the greeter appears inside some graphical environment.

Well, as stated above, I tried to log out my graphical session (to my greeter, that is) and remove the directory as suggested, then login again, but that did not resolve the issue

[soundofthunder]

@johnfoot

local/kvantum-theme-matcha 20190810-3
    Matcha theme for Kvantum

I seem to recall a recent thread with similar issues (I say recent though it may have been up to 2-3 months ago). The solution (or, at least part of it) was to remove the (then) unsupported kvantum-theme-matcha package; as it was no longer relevant for Qt6. Apologies for this not being more specific, as I was unable to find the thread. Note that this is only based on a vague recollection.

This might at least warrant some research.

Cheers.

[johnfoot]

Thanks for your suggestion, alas removing this package does not seem to change much while trying to launch the aforementioned applications.