Bug 500403

Summary: The 'integrated' and 'discrete' labels next to the GPUs are not shown on Wayland [solution found]
Product: [Applications] kinfocenter Reporter: John <ilikefoss>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DOWNSTREAM    
Severity: minor CC: nate, quarro, sitter, yanexbug
Priority: NOR    
Version First Reported In: 6.3.0   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: How the the labels are displayed on X11 session.

Description John 2025-02-19 12:55:01 UTC
Created attachment 178585 [details]
How the the labels are displayed on X11 session.

SUMMARY
The 'integrated' and 'discrete' labels next to the GPUs don't are not shown on Wayland

STEPS TO REPRODUCE
1. Use the Wayland session of Plasma.
2. Open Info Center.
3. Look at the right of GPU(s)' name(s).

OBSERVED RESULT
No colored 'integrated' (blue) or 'discrete' (green) labels are shown.
Like you can see them on X11 (see the attached printscreen from running the program on X11.
They are not appearing even without being colored. They are just not there at all.
I didn't even know they were missing on Wayland if I hadn't have to switch to the X11 to help with information for another bug report.

EXPECTED RESULT
They should be shown in Wayland too, like on X11.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 6.3.0
KDE Frameworks Version: 6.10.0
Qt Version: 6.7.2
Kernel Version: 6.12.13-amd64 (64-bit)
Graphics Platform: Wayland


HARDWARE SPECIFICATIONS
Hardware: Laptop Dell Inspiron 5770 (17" 1080p@60Hz screen)
CPU: Intel® Core™ i5-8250U CPU @ 1.60GHz
GPU 1: Mesa Intel® UHD Graphics 620 (main)
GPU 2: AMD Radeon R5 M465 Series
RAM: 8 GiB (7.7 GiB usable)


ADDITIONAL INFORMATION
Debian with the 'unstable' repository is fully up to date.
Comment 1 Greeniac 2025-02-19 13:31:13 UTC
I had all sorts off issues with some things not working in Debain unstable when Plasma 6 got released to the testing repos, and all of them were working fine in rolling release distros (Fedora, Thumbleweed and Arch). I'm guessing that it is an issue with the Debian package and not Plasma itself, but i could be wrong.
Comment 2 Harald Sitter 2025-02-19 13:51:48 UTC
Your vulkan stack is probably misbehaving. The pills are not there when detection runs through opengl instead of vulkan.
Comment 3 John 2025-02-19 14:44:16 UTC
(In reply to Harald Sitter from comment #2)
> Your vulkan stack is probably misbehaving. The pills are not there when
> detection runs through opengl instead of vulkan.

That's strange, but could be, considering that I'm following the 'unstable' repository of Debian.
And a bit strange also because I'm I'm playing a few Windows games on Steam through Proton, which uses DXVK and I assume it would either don't work or at least complain / show some warning somewhere.

But if that detection runs through OpenGL instead of Vulkan, was it made smart enough to check which GPU is capable of OpenGL only and which is capable of Vulkan also?
Because if I remember correctly while doing some tests with MangoHUD I saw that the secondary GPU, the dedicated one, so:
AMD Radeon R5 M465 Series
Doesn't have Vulkan support at all!
Just the first one
UHD Graphics 620
has Vulkan support and on this I'm playing games with DXVK. (the dedicated one is also as weak as this one, so it wouldn't matter if I used it).
Comment 4 John 2025-02-19 14:58:59 UTC
BTW, this is the output of: Info Center -> Graphics -> Vulkan (while on Wayland), if it's any help...
On PasteBin as it's too long to post here:
https://pastebin.com/wdnmfuR5
Comment 5 Harald Sitter 2025-02-19 15:03:50 UTC
> But if that detection runs through OpenGL instead of Vulkan, was it made smart enough to check which GPU is capable of OpenGL only and which is capable of Vulkan also?

That would lead to inconsistent results. It's a bit difficult because different APIs have different understandings of which GPUs are available. e.g. you may also have software based renderers that register as a device. So what we do is detect how many physical GPUs there are and then either get all of their labels through vulkan or all of their labels through opengl.
Comment 6 John 2025-02-19 16:30:50 UTC
(In reply to Harald Sitter from comment #5)
> > But if that detection runs through OpenGL instead of Vulkan, was it made smart enough to check which GPU is capable of OpenGL only and which is capable of Vulkan also?
> 
> That would lead to inconsistent results. It's a bit difficult because
> different APIs have different understandings of which GPUs are available.
> e.g. you may also have software based renderers that register as a device.
> So what we do is detect how many physical GPUs there are and then either get
> all of their labels through vulkan or all of their labels through opengl.

I understand!
I'm sorry it's this is difficult for you to fix!
If it were up to me I would've told you to just use Vulkan as that's the future and probably has better drivers.
Looking at the begining of that 'vulkaninfo' output that I've put on PasteBin, I see this:
Devices: count = 3
GPU id = 0 (Intel(R) UHD Graphics 620 (KBL GT2)) -> this is my integrated GPU that is the main one use everywhere most of the time and it has Vulkan support
GPU id = 1 (AMD Radeon R5 M465 Series (RADV ICELAND)) -> this is my discrete GPU that doesn't have Vulkan support as MangoHUD once showed me

GPU id = 2 (llvmpipe (LLVM 19.1.7, 256 bits)) -> this is some fake / virtual GPU I assume as I only have 2 physical ones.

I tried to see if there's any mention that the AMD only doesn't support Vulkan, but I don't see anything like that.
Maybe it cannot be determined just with vulkaninfo.

BTW, in the meantime I booted both KDE Neon (testing) and KDE Neon (unstable) that I have from 2-3 weeks ago (sorry I cannot get fresher ones as I'm on a limited mobile connection) on the same laptop from a USB pendrive.
The problem presents itself in both KDE Neon version and in both the pills / labels appear only in the X11 session.
So this is not a Debian unstable problem only.

Unfortunately this seems a hard problem to fix and it's ok if you want to postpone for some other time.
I was just surprised to see them in the X session and remembered reading about them in Nate's blog some time ago and wanted to let you know that for some reason I'm not seeing them in Wayland.
I don't have another computer next to me at the moment to try there too with other GPUs.
Comment 7 Harald Sitter 2025-02-19 17:25:55 UTC
Do you have any output when you start kinfocenter from a terminal?
Comment 8 John 2025-02-19 17:46:43 UTC
Yes, this:
qt.qml.typeregistration: Invalid QML element name "Hint"; value type names should begin with a lowercase letter
Failed to load vulkan: Cannot load library vulkan: vulkan: cannot open shared object file: No such file or directory
initInstance: No Vulkan library available
Failed to create platform Vulkan instance
Failed to create vulkan instance
GPU count mismatch (from vulkan) 0 2
Looking at QList("/usr/bin", "/usr/lib/qt6/libexec", "/usr/lib/qt6/libexec/kf6", "/usr/lib/x86_64-linux-gnu/libexec", "/usr/lib/x86_64-linux-gnu/libexec") "/usr/lib/x86_64-linux-gnu/libexec/kinfocenter-opengl-helper"
qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
Comment 9 John 2025-02-19 18:21:32 UTC
And on X11, where the pills work, this:
qt.qml.typeregistration: Invalid QML element name "Hint"; value type names should begin with a lowercase letter
Physical device 0: 'Intel(R) UHD Graphics 620 (KBL GT2)' 24.3.4 (api 1.3.296 vendor 0x8086 device 0x5917 type 1)
Physical device 0: 'AMD Radeon R5 M465 Series (RADV ICELAND)' 24.3.4 (api 1.3.296 vendor 0x1002 device 0x6900 type 2)
Physical device 0: 'llvmpipe (LLVM 19.1.7, 256 bits)' 0.0.1 (api 1.3.296 vendor 0x10005 device 0x0 type 4)
excess llvmpipe detected, ignoring
Comment 10 John 2025-02-24 13:29:14 UTC
In the meantime, Mesa 25 came with the updates yesterday:
glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
    Device: Mesa Intel(R) UHD Graphics 620 (KBL GT2) (0x5917)
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.0.0-1
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.0.0-1
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.0.0-1

kinfocenter (running from terminal in the Wayland session), still doesn't show the pills and has the same output:
qt.qml.typeregistration: Invalid QML element name "Hint"; value type names should begin with a lowercase letter
Failed to load vulkan: Cannot load library vulkan: vulkan: cannot open shared object file: No such file or directory
initInstance: No Vulkan library available
Failed to create platform Vulkan instance
Failed to create vulkan instance
GPU count mismatch (from vulkan) 0 2
Looking at QList("/usr/bin", "/usr/lib/qt6/libexec", "/usr/lib/qt6/libexec/kf6", "/usr/lib/x86_64-linux-gnu/libexec", "/usr/lib/x86_64-linux-gnu/libexec") "/usr/lib/x86_64-linux-gnu/libexec/kinfocenter-opengl-helper"
qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0

Is it possible that this new major upgrade of Mesa, with its Vulkan and OpenGL drivers also is packaged wrong, with something missing?
I think it's probably a low chance that both Mesa 24.3 and 25 is packaged wrong in Debian and whatever Mesa is in KDE Neon is also wrong.
Maybe some of these errors in the output mean something.
Shouldn't the underlying OpenGL or Vulkan functions used to get info about the GPUs work the same on X and Wayland?
To me it doesn't make much sense why it doesn't work only on Wayland, which is what I use by default for years and I have no intention to get back from it as all my computers intentionally use only AMD and Intel GPUs.
Feel free to close the report if this cannot be resolved now for whatever reason!
Comment 11 Harald Sitter 2025-02-24 13:38:45 UTC
> Failed to load vulkan: Cannot load library vulkan: vulkan: cannot open shared object file: No such file or directory

Depending on how you look at it this is either an upstream (Qt) or a downstream (distro) problem. qtwayland expects to find libvulkan.so, qtxcb also looks for libvulkan.so.1. As such a distribution that pulls in qtwayland without providing libvulkan.so is broken. At the same time qtwayland only looking for libvulkan.so is a bit unexpected.
Comment 12 John 2025-02-25 08:04:56 UTC
(In reply to Harald Sitter from comment #11)
> Depending on how you look at it this is either an upstream (Qt) or a
> downstream (distro) problem. qtwayland expects to find libvulkan.so, qtxcb
> also looks for libvulkan.so.1. As such a distribution that pulls in
> qtwayland without providing libvulkan.so is broken. At the same time
> qtwayland only looking for libvulkan.so is a bit unexpected.
Thank you very much for explaining the problem so well that I could understand what the code is looking for and not finding.
Knowing the file names I could search for them on my system to see if they are really not found or they just have different names, so I searched for them with this command: sudo fdfind 'libvulkan.so' /
That gave me this:
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/6.8/68d286c596aa5122502e092332f3cf9c549c822985f15a4b134e70bbff537b75/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/6.8/68d286c596aa5122502e092332f3cf9c549c822985f15a4b134e70bbff537b75/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.15-24.08/12d9dfd680aa5b016e8208baa2fced33215c336d801a0bb09e9797087b8e13a5/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.15-24.08/12d9dfd680aa5b016e8208baa2fced33215c336d801a0bb09e9797087b8e13a5/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/47/2e030588dbe16adbf696824be76ed2a70ed11504edb8a6a932b85deae8ae68e9/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/47/2e030588dbe16adbf696824be76ed2a70ed11504edb8a6a932b85deae8ae68e9/files/lib/x86_64-linux-gnu/libvulkan.so.1
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
/usr/lib/x86_64-linux-gnu/libvulkan.so.1.4.304
/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/24.08/7843a03291593f58bfd4583eaa48b65198be8a84ecd1a5885d0d65920d3a22a6/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/24.08/7843a03291593f58bfd4583eaa48b65198be8a84ecd1a5885d0d65920d3a22a6/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.freedesktop.Platform.Compat.i386/x86_64/24.08/5e988e1957382baf3d57d48597dcb41477ffd05839591b71f2e6dd27206af05a/files/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.freedesktop.Platform.Compat.i386/x86_64/24.08/5e988e1957382baf3d57d48597dcb41477ffd05839591b71f2e6dd27206af05a/files/libvulkan.so.1
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/6.8/68d286c596aa5122502e092332f3cf9c549c822985f15a4b134e70bbff537b75/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/6.8/68d286c596aa5122502e092332f3cf9c549c822985f15a4b134e70bbff537b75/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.15-24.08/12d9dfd680aa5b016e8208baa2fced33215c336d801a0bb09e9797087b8e13a5/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.15-24.08/12d9dfd680aa5b016e8208baa2fced33215c336d801a0bb09e9797087b8e13a5/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/47/2e030588dbe16adbf696824be76ed2a70ed11504edb8a6a932b85deae8ae68e9/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/47/2e030588dbe16adbf696824be76ed2a70ed11504edb8a6a932b85deae8ae68e9/files/lib/x86_64-linux-gnu/libvulkan.so.1
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
/usr/lib/x86_64-linux-gnu/libvulkan.so.1.4.304
/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/24.08/7843a03291593f58bfd4583eaa48b65198be8a84ecd1a5885d0d65920d3a22a6/files/lib/x86_64-linux-gnu/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.freedesktop.Platform/x86_64/24.08/7843a03291593f58bfd4583eaa48b65198be8a84ecd1a5885d0d65920d3a22a6/files/lib/x86_64-linux-gnu/libvulkan.so.1
/var/lib/flatpak/runtime/org.freedesktop.Platform.Compat.i386/x86_64/24.08/5e988e1957382baf3d57d48597dcb41477ffd05839591b71f2e6dd27206af05a/files/libvulkan.so.1.3.290
/var/lib/flatpak/runtime/org.freedesktop.Platform.Compat.i386/x86_64/24.08/5e988e1957382baf3d57d48597dcb41477ffd05839591b71f2e6dd27206af05a/files/libvulkan.so.1

I ignored all the things about Flatpak an concentrated just on these 2 files:
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
/usr/lib/x86_64-linux-gnu/libvulkan.so.1.4.304

I moved into that folder and did this custom ls -l command: ll libvulkan*
That gave me this:
0777 lrwxrwxrwx    - root root 16 Jan 14:38 libvulkan.so.1 -> libvulkan.so.1.4.304
0644 .rw-r--r-- 535k root root 16 Jan 14:38 libvulkan.so.1.4.304
0644 .rw-r--r--  21M root root 23 Feb 09:22 libvulkan_intel.so
0644 .rw-r--r--  17M root root 23 Feb 09:22 libvulkan_intel_hasvk.so
0644 .rw-r--r--  11M root root 23 Feb 09:22 libvulkan_lvp.so
0644 .rw-r--r--  16M root root 23 Feb 09:22 libvulkan_nouveau.so
0644 .rw-r--r--  14M root root 23 Feb 09:22 libvulkan_radeon.so
0644 .rw-r--r-- 1.3M root root 23 Feb 09:22 libvulkan_virtio.so
Seeing that an 'libvulkan.so.1' exists, but not also a 'libvulkan.so' file, I created one by making a symlink with absolute paths like this:

sudo ln -s /usr/lib/x86_64-linux-gnu/libvulkan.so.1 /usr/lib/x86_64-linux-gnu/libvulkan.so

After that I ran the  'kinfocenter' command as before, which gave me this output now:

qt.qml.typeregistration: Invalid QML element name "Hint"; value type names should begin with a lowercase letter
[2025-02-25 06:51:21.162] [MANGOHUD] [error] [overlay_params.cpp:148] Unrecognized key: '=Shift_L'
Physical device 0: 'Intel(R) UHD Graphics 620 (KBL GT2)' 25.0.0 (api 1.4.305 vendor 0x8086 device 0x5917 type 1)
Physical device 0: 'AMD Radeon R5 M465 Series (RADV ICELAND)' 25.0.0 (api 1.4.305 vendor 0x1002 device 0x6900 type 2)
Physical device 0: 'llvmpipe (LLVM 19.1.7, 256 bits)' 0.0.1 (api 1.4.305 vendor 0x10005 device 0x0 type 4)
excess llvmpipe detected, ignoring
qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0

The '[error]' after '[MANGOHUD]' is displayed in red color and last line still looks like an error...
But the pills are now working (they are displayed)! :-)
And they are displayed correctly for my GPUs, similar to the X session!
I closed it an reopened from the start menu also and it works as expected from here too!

If it's not much problem, can you please give a PM or ping to  Aurélien COUDERC, which seems to be one of the main maintainers / packagers of KDE software for Debian:
https://tracker.debian.org/pkg/plasma-desktop
https://salsa.debian.org/coucouf
https://invent.kde.org/aureliencouderc
To let him know about this problem on Wayland and the fact that it can be solved with that simple symlink?

I haven't tested KDE Neon again, but since it suffers from the same exact problem and it's not much different from Debian, maybe the symlink fix will also work there, so maybe you want to inform KDE Neon developers too.

Or maybe look again at the code if it's indeed looking for the 'libvulkan.so.1' file too in addition to 'libvulkan.so' file and if it really works, as maybe it doesn't since the file existed from the beginning and a simple symlink to  it was enough to fix it.
I'll set this as 'Reported' for the last time to make sure you read this reply.
Comment 13 Nate Graham 2025-04-02 15:17:16 UTC
In general I would recommend discontinuing your experiments with Vulkan. This isn't something we formally support yet, and lots of things are known to be horribly broken. You're just going to make life hard for yourself!