Hi togetter, after updating to eselect-wine > 2.0.0 I face issues on several wine games with vkCreateInstance errors. With vulkaninfo I saw: ERROR: [Loader Message] Code 0 : vkCreateInstance: Found no drivers! Cannot create Vulkan instance. This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan. It turnes out that setting the XDG_DATA_DIRS env on eselect-wine installation results in issues with the vulkan-loader. The vulkan-loader use this env as last order on the driver discovery (see https://github.com/KhronosGroup/Vulkan-Loader/blob/82d4232f0f348f66582dd4d5ac15cdb449e08ca1/docs/LoaderDriverInterface.md#driver-discovery-on-linux). If the env is unset it checks the /usr/share directory, where the actual icd manifest files reside (installed by the mesa package). This was the case before eselect-wine-2.0.0. If I unset the XDG_DATA_DIRS, vulkaninfo works as expected. I'm not sure if this is actually an issue. Maybe the env setting could be made optional? Or the vulkan-loader (or mesa) could also add the /usr/share path? For the latter one I could then create a new issue if needed. Hope that was descriptive to some extend. Thanks for reading. :-) Reproducible: Always More input on vulkan-loader discovery e.g. with: VK_LOADER_DEBUG=driver vulkaninfo --summary This only works with vulkan-headers >=1.3.234 (see https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderDebugging.md#debugging-possible-driver-issues)
That sounds odd given even without eselect-wine you'd still get: XDG_DATA_DIRS=/usr/local/share:/usr/share All eselect-wine does is add another directory resulting in: XDG_DATA_DIRS=/usr/local/share:/etc/eselect/wine/share:/usr/share Albeit seeing it I don't like the order much, does it work fine if instead use: XDG_DATA_DIRS=/usr/local/share:/usr/share:/etc/eselect/wine/share ? could just change the env.d priority then.
Note that I can't reproduce, both vulkaninfo and wine's vulkan works fine here, and it's finding the icd file: $ grep nvidia_icd vulkaninfo.* vulkaninfo.19858:access("/usr/share/vulkan/icd.d/nvidia_icd.json", F_OK) = 0 vulkaninfo.19858:openat(AT_FDCWD, "/usr/share/vulkan/icd.d/nvidia_icd.json", O_RDONLY) = 3 $ echo $XDG_DATA_DIRS /usr/local/share:/etc/eselect/wine/share:/usr/share
(In reply to Ionen Wolkens from comment #2) > $ echo $XDG_DATA_DIRS > /usr/local/share:/etc/eselect/wine/share:/usr/share Note that this is based on what you get if you `source /etc/profile`, if you get something else then it's possible something in your environment mangled it.
..also not the only package doing this, albeit gdm adds itself at the end (what I was asking about if it helped in comment #1) $ cat /etc/env.d/99xdg-gdm XDG_DATA_DIRS="/usr/share/gdm"
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77a11023eaa26a4403092173fd81ec6d828d5377 commit 77a11023eaa26a4403092173fd81ec6d828d5377 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-12-03 00:57:16 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-12-03 01:03:10 +0000 app-eselect/eselect-wine: use later (95) priority for env.d Shouldn't(?) have a real impact but it seems wasteful for its XDG_DATA_DIRS be searched earlier than 90xdg-data-base (aka >90 will cause it to add wine's after /usr/share). Also wouldn't want wine's semi-random binaries to have priority, albeit PATH already typically came last with 60. (reminder need to `. /etc/profile` to update in current shells) Bug: https://bugs.gentoo.org/884077 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../{eselect-wine-2.0.1.ebuild => eselect-wine-2.0.1-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Hello, I had this problem too the other day. I only use the hardened profile and use a window manager and no login manager and my setup is very specific mumble mumble. This results in no XDG_DATA_DIRS envvar set since no package installs a corresponding env.d file which in turn results into sane defaults getting used. So packages that rely on XDG_DATA_DIRS=/usr/share like vulkan-loader to find and load the icd or a whole slew of GNOME things that need /usr/share/mime to process png files during building break. It's not a problem with eselect-wine but the underlying gentoo install being a bit wonky.
Hi together, thanks for the quick reply and the effort! (In reply to Ionen Wolkens from comment #3) > (In reply to Ionen Wolkens from comment #2) > > $ echo $XDG_DATA_DIRS > > /usr/local/share:/etc/eselect/wine/share:/usr/share > Note that this is based on what you get if you `source /etc/profile`, if you > get something else then it's possible something in your environment mangled > it. (In reply to franklyfrank from comment #6) > Hello, I had this problem too the other day. > I only use the hardened profile and use a window manager and no login > manager and my setup is very specific mumble mumble. > > This results in no XDG_DATA_DIRS envvar set since no package installs a > corresponding env.d file which in turn results into sane defaults getting > used. I also do not use a display manager etc. so my /etc/env.d do currently only contain settings to XDG_DATA_DIRS for eselect-wine: grep -r XDG_DATA_DIRS /etc/env.d/ /etc/env.d/60eselect-wine:XDG_DATA_DIRS="/etc/eselect/wine/share" (In reply to Ionen Wolkens from comment #1) > Albeit seeing it I don't like the order much, does it work fine if instead > use: > > XDG_DATA_DIRS=/usr/local/share:/usr/share:/etc/eselect/wine/share > > ? could just change the env.d priority then. So this will probably not solve it on those setups. Hm, could it be sensible to add x11-misc/xdg-utils as a dependency? This package contains the needed env settings. Or might this be something for vulkan-loader or mesa? Or is this too much since the utils are not needed?
(In reply to tuxway+gentoo from comment #7) > Hm, could it be sensible to add x11-misc/xdg-utils as a dependency? This > package contains the needed env settings. Or might this be something for > vulkan-loader or mesa? Or is this too much since the utils are not needed? Yeah, I hadn't realized this was installed by xdg-utils and thought it was installed by something more common. This explains things. I'll have a quick look if there's a sane way to handle this without xdg-utils, but may depend on it otherwise.
(In reply to Ionen Wolkens from comment #8) > I'll have a quick look if there's a sane way to handle this without > xdg-utils, but may depend on it otherwise. (fwiw winetricks already depend on this so it's typically not overly new for most wine users)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79cce30abd02567f8465f879a91b273544126c84 commit 79cce30abd02567f8465f879a91b273544126c84 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-12-03 13:43:06 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-12-03 13:52:10 +0000 app-eselect/eselect-wine: optionally rdepend on xdg-utils Being optional makes some sense for headless system, albeit most desktop ones will typically want xdg-open from this around. Closes: https://bugs.gentoo.org/884077 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> ...lect-wine-2.0.1-r1.ebuild => eselect-wine-2.0.1-r2.ebuild} | 11 ++++++++--- app-eselect/eselect-wine/metadata.xml | 3 +++ 2 files changed, 11 insertions(+), 3 deletions(-)
Thanks for the fix. Works like a charm! I guess I will potentially do this with a manual env setting, since the xdg-utils package result in 15 new packages which I probably want to avoid. But the requirement is the better default solution! Thanks! :-)
Maybe just a tiny additional question: With the latest change, setting -xdg leads to not adding /etc/eselect/wine/share to XDG_DATA_DIRS at all. Does this works for eselect-wine?
(In reply to tuxway+gentoo from comment #12) > Maybe just a tiny additional question: With the latest change, setting -xdg > leads to not adding /etc/eselect/wine/share to XDG_DATA_DIRS at all. Does > this works for eselect-wine? Not really an issue, all you'll be missing wine.desktop visibility, but that's only relevant if opening .exe based on xdg Mime Type (through e.g. xdg-open from, guess what, xdg-utils). Odds are if you have a minimal system without xdg-open, nothing is even using this on your system. May re-evaluate handling if use XDG_DATA_DIRS for more things in the future, but right now its use is minimal.
So that works for me! Thanks for the clarification!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9d8c00974a9e9fca5e698f65bc0adc1a28367b62 commit 9d8c00974a9e9fca5e698f65bc0adc1a28367b62 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-12-03 22:22:49 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-12-03 22:40:03 +0000 app-eselect/eselect-wine: use a bit clearer USE=xdg description Could argue not many will even want this to work, albeit keeping IUSE=+xdg default to maintain what normally works out of the box with Wine. Bug: https://bugs.gentoo.org/884077 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-eselect/eselect-wine/metadata.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
