[Solved] Anki broken after qt6-webengine update to 6.11.0-2

neXyon · 2026-03-28 15:41:04

Hi all,

after the update of qt6, anki crashes during start-up. I found out that the issue is the qt6-webengine package as when I downgrade to the previous version (6.10.2-2), it works again.

I'm currently waiting to get my account allowlisted on the arch gitlab to open an issue there. I actually found a similar looking one where the issue only seems to appear on Intel GPUs.

I wanted to ask if other people have the same issue with Intel or other GPUs. Also, I wonder if I can find another workaround on my machine, as I am using a laptop with Intel+Nvidia hybrid graphics.

Cheers

Last edited by neXyon (2026-04-03 18:25:24)

Galicarnax · 2026-03-29 09:07:05

I use qutebrowser based on qt6-webengine, laptop with Wayland/Sway, Intel+Nvidia, and nouveau driver. Also experiencing issue after today's upgrade. The browser starts and its UI elements are ok, but the page area shows glitchy sand-like patterns and nothing else. Downgrading to qt6-webengine-6.10.2-2 removed the issue.

Last edited by Galicarnax (2026-03-29 09:07:42)

meowgoo · 2026-04-01 02:59:53

Similar issue here, Anki crashes after partially loading the interface, also Intel and Nvidia GPU laptop, Nvidia driver. I'm not exactly sure why or how, but it seems that forcing Anki to launch with dedicated GPU using "DRI_PRIME=1 anki" makes it launch

seth · 2026-04-01 07:02:04

https://bbs.archlinux.org/viewtopic.php … 8#p2292418
https://archlinux.org/packages/extra/x8 … kan-intel/ ?

neXyon · 2026-04-03 18:24:57

Perfect, thanks a lot! Installing vulkan-intel indeed fixed it.

seth · 2026-04-04 08:42:23

\o/

If you don't mind, there's some question about the nature of the bug.
While in the end I suppose you want to use the intel vlkan implementation, but if you don't mind you could help to figure what's going on by removing it again, adding initcall_blacklist=sysfb_init to the https://wiki.archlinux.org/title/Kernel_parameters and reboot w/ that.
This should™ result in the simpledrm device to be blocked, the card order become intel/nvidia

lspci -d ::03xx
ls -l /sys/class/drm

and the theory would be that QtQuick then doesn't try to use nvidia's vulkan implementation along the intel GPU.

@Galicarnax since you're using nouveau

pacman -Qs vulkan

(before fixing anything ) might provide additional insight.

neXyon · 2026-04-04 11:32:40

I tried removing it again (anki crashes again) and then added the kernel parameter and rebooted. Anki still crashes afterwards. According to the linked thread nvidia-drm.modeset=1 should disable simpledrm too, so it should be double disabled for me?

# cat /proc/cmdline
root=UUID=<REMOVED> rw initrd=\intel-ucode.img initrd=\initramfs-linux.img nvidia-drm.modeset=1 initcall_blacklist=sysfb_init

You are right however, that the kernel parameter switched the cards' order:

# lspci -d ::03xx
00:02.0 VGA compatible controller: Intel Corporation TigerLake-H GT1 [UHD Graphics] (rev 01)
01:00.0 VGA compatible controller: NVIDIA Corporation GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] (rev a1)
# ls -l /sys/class/drm # before reboot (without initcall_blacklist=sysfb_init)
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0-DP-5 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DP-5
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0-DP-6 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DP-6
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0-DP-7 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DP-7
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0-DP-8 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DP-8
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-1
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1-DP-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-2
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1-DP-3 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-3
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1-DP-4 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-4
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1
lrwxrwxrwx 1 root root    0  4. Apr 12:50 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128
lrwxrwxrwx 1 root root    0  4. Apr 12:50 renderD129 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129
# ls -l /sys/class/drm # after reboot (with initcall_blacklist=sysfb_init)
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0-DP-2 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-2
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0-DP-3 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-3
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0-DP-4 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-4
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1-DP-5 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-5
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1-DP-6 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-6
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1-DP-7 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-7
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1-DP-8 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-DP-8
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-HDMI-A-1
lrwxrwxrwx 1 root root    0  4. Apr 19:52 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128
lrwxrwxrwx 1 root root    0  4. Apr 19:52 renderD129 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129

Since it still crashes with the new order: Why would it not try to use nvidia's vulkan implementation? Because from a Vulkan point of view (vulkaninfo) there's of course always only the nvidia device if vulkan-intel is not installed.

Last edited by neXyon (2026-04-04 17:53:46)

seth · 2026-04-04 14:19:20

I don't expect any surprises here, but do you still have the complete ls output (the render device order isn't deterministically linked to the card order)

Why would it not try to use nvidia's vulkan implementation?

Because you're running on the intel device, see #3
The question is why it would try to use the nvidia vulkan implementation (other than "it's there") - and apparently not because of the card order

neXyon · 2026-04-04 18:03:52

I edited the post to contain the rest of the output. How can you tell the render device order from it?

With DRI_PRIME=1 it also works without vulkan-intel as well.

How does it try to use the intel device when there's no Vulkan driver installed for it? I don't even know how you would try to use the intel device with Vulkan if Vulkan doesn't report it (with vkEnumeratePhysicalDevices)?! You can't get the VkPhysicalDevice necessary to create a device with vkCreateDevice. https://registry.khronos.org/vulkan/spe … sandqueues

seth · 2026-04-04 19:37:16

lrwxrwxrwx 1 root root    0  4. Apr 12:50 card0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
lrwxrwxrwx 1 root root    0  4. Apr 12:50 card1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card1
lrwxrwxrwx 1 root root    0  4. Apr 12:50 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128
lrwxrwxrwx 1 root root    0  4. Apr 12:50 renderD129 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129

lrwxrwxrwx 1 root root    0  4. Apr 19:52 card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0
lrwxrwxrwx 1 root root    0  4. Apr 19:52 card1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1
lrwxrwxrwx 1 root root    0  4. Apr 19:52 renderD128 -> ../../devices/pci0000:00/0000:00:02.0/drm/renderD128
lrwxrwxrwx 1 root root    0  4. Apr 19:52 renderD129 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD129

I stand corrected… there's your easter surprise
The card flips its order but the render device does not (the hint is the PCI index, 0000:01:00.0 & 0000:00:02.0 for GPU and IGP)
The first render device (renderD128) sticks to the IGP no matter what - no matter the card order.

How does it try to use the intel device when there's no Vulkan driver installed for it?

The IGP is used for overall rendering, the compositor and EGL

@Galicarnax, this makes the nouveau situation even more interesting.
The nvidia drivers unconditionally ship a vulkan implementation, but for nouveau you'd need https://archlinux.org/packages/extra/x8 … n-nouveau/
So if you had similar crashes w/o *any* vulkan implementation and can fix it by installing https://archlinux.org/packages/extra/x8 … kan-intel/ that would mean QtQuick doesn't grab the wrong one but wrongly uses vulkan at all (w/o any implementation available)

Galicarnax · 2026-04-11 08:48:20

seth wrote:

@Galicarnax, this makes the nouveau situation even more interesting.
The nvidia drivers unconditionally ship a vulkan implementation, but for nouveau you'd need https://archlinux.org/packages/extra/x8 … n-nouveau/
So if you had similar crashes w/o *any* vulkan implementation and can fix it by installing https://archlinux.org/packages/extra/x8 … kan-intel/ that would mean QtQuick doesn't grab the wrong one but wrongly uses vulkan at all (w/o any implementation available)

I do have vulkan:

$ pacman -Qs vulkan      
local/spirv-tools 1:1.4.341.0-2 (vulkan-devel)
    API and commands for processing SPIR-V modules
local/vulkan-icd-loader 1.4.341.0-1 (vulkan-devel)
    Vulkan Installable Client Driver (ICD) Loader
local/vulkan-mesa-implicit-layers 1:26.0.4-1
    Mesa's implicit Vulkan layers
local/vulkan-nouveau 1:26.0.4-1
    Open-source Vulkan driver for Nvidia GPUs

And installing vulkan-intel has no effect. In fact, I don't have crashes. It's just that qutebrowser renders gibberish instead of pages (its UI elements are still Ok). I have now tried to upgrade to newer qt6-webengine v. 6.11.0-3, same thing, so I downgraded to 6.10.2-2 again.

seth · 2026-04-11 12:29:13

Please open a new thread and post a screenshot illustrating the "gibberish", what happens if you "DRI_PRIME=1 qutebrowser"? Does it have some "about:gpu" feature?

Galicarnax · 2026-04-11 14:29:22

"DRI_PRIME=1 qutebrowser" does the job, thanks. Seemingly, some regression in the bundle of "Wayland + Qt WebEngine + nouveau". If the issue will persist with newer updates, I'll open a new thread.

seth · 2026-04-11 14:43:37

Still sounds as if the wrong™ vulkan driver is picked.
After installing vulkan-intel, try "VK_DRIVER_FILES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json qutebrowser" or "VK_DRIVER_FILES=/usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json qutebrowser" (no prime)

Origin is likely https://qt-project.atlassian.net/browse/QTBUG-145574

Arch Linux

#1 2026-03-28 15:41:04

[Solved] Anki broken after qt6-webengine update to 6.11.0-2

#2 2026-03-29 09:07:05

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#3 2026-04-01 02:59:53

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#4 2026-04-01 07:02:04

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#5 2026-04-03 18:24:57

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#6 2026-04-04 08:42:23

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#7 2026-04-04 11:32:40

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#8 2026-04-04 14:19:20

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#9 2026-04-04 18:03:52

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#10 2026-04-04 19:37:16

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#11 2026-04-11 08:48:20

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#12 2026-04-11 12:29:13

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#13 2026-04-11 14:29:22

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

#14 2026-04-11 14:43:37

Re: [Solved] Anki broken after qt6-webengine update to 6.11.0-2

Board footer