Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

games using dxvk or vkd3d in Lutris aren't listed #363

Open
seeeeew opened this issue Mar 9, 2024 · 2 comments
Open

games using dxvk or vkd3d in Lutris aren't listed #363

seeeeew opened this issue Mar 9, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@seeeeew
Copy link

seeeeew commented Mar 9, 2024

Describe the bug
ProtonUp-Qt erroneously reports no games are using dxvk or vkd3d in Lutris, despite them being used.

To Reproduce
Steps to reproduce the behavior:

  1. List installed compatibility tools for Lutris
  2. "Show info" for any installed version of dxvk or vkd3d that is used by at least one game in Lutris

Expected behavior
Either the games actually using the selected version of dxvk or vkd3d in Lutris should be listed, or there should be an indication that ProtonUp-Qt doesn't detect which games are using the selected version of dxvk or vkd3d in Lutris.

Screenshots
Screenshot from 2024-03-09 03-20-38

Desktop:

  • Platform: Desktop PC
  • System: Ubuntu 22.04.4
  • Version: ProtonUp-Qt 2.9.1
  • How did you install ProtonUp-Qt?: Flatpak

Terminal output

Gtk-Message: 03:23:24.786: Failed to load module "canberra-gtk-module"
Gtk-Message: 03:23:24.787: Failed to load module "canberra-gtk-module"
qt.qpa.qgnomeplatform: Could not find color scheme  ""
Qt: Session management error: Could not open network socket
qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
ProtonUp-Qt 2.9.1 by DavidoTek. Build Info: DavidoTek Flathub build.
Python 3.10.13 (main, Nov 10 2011, 15:00:00) [GCC 12.2.0], PySide 6.5.2
Platform: KDE Flatpak runtime 6.5 Linux-6.5.0-21-generic-x86_64-with-glibc2.35
Loading locale de / de_DE
Loaded ctmod GE-Proton
Loaded ctmod Wine-GE
Loaded ctmod Boxtron
Loaded ctmod D8VK (nightly)
Loaded ctmod Kron4ek Wine-Builds Vanilla
Loaded ctmod Lutris-Wine
Loaded ctmod Luxtorpeda
Loaded ctmod Northstar Proton (Titanfall 2)
Loaded ctmod Proton Tkg
Loaded ctmod Proton Tkg (Wine Master)
Loaded ctmod Roberta
Loaded ctmod Steam-Play-None
Loaded ctmod SteamTinkerLaunch
Loaded ctmod SteamTinkerLaunch-git
Loaded ctmod vkd3d-lutris
Loaded ctmod vkd3d-proton
Loaded ctmod Wine Tkg (Valve Wine)
Loaded ctmod Wine Tkg (Vanilla Wine)
Loaded ctmod DXVK
Loaded ctmod DXVK Async
Loaded ctmod DXVK (nightly)
Gamepad error: No gamepad found.
@seeeeew seeeeew added the bug Something isn't working label Mar 9, 2024
@sonic2kk
Copy link
Contributor

sonic2kk commented Mar 9, 2024

Indeed, not sure if there's a good way to do this or not.

I wouldn't say this is a bug, though, this is more of a feature request.

@sonic2kk
Copy link
Contributor

sonic2kk commented Mar 9, 2024

DXVK version (and whether DXVK is enabled or not) is stored in the game's YML file (~/.config/lutris/games, or equivalent Flatpak path). It looks like this (vkd3d uses vkd3d keys):

wine:
  dxvk: false
  dxvk_version: v2.1

This will not be listed in the file unless DXVK information is configured explicitly for the game. When adding a game yourself, normally this is not set. For install scripts some may set this. So basically if you don't configure it yourself, the file won't have this information.


There is a gotcha though: The user can enable, say, DXVK, and this will be dxvk: true in the game's YML, but by default it uses the, well, default DXVK version, and this is not listed in this YML file! Fortunately, Lutris does track its defaults in ~/.cache/lutris/versions.json. Sample file structure:

{
  "runtimes": {
    "vkd3d": {
      "name": "vkd3d",
      "created_at": "2023-11-28T00:42:02.989003Z",
      "architecture": "all",
      "url": "https://github.com/lutris/vkd3d/releases/download/v2.11/vkd3d-2.11.tar.xz",
      "version": "v2.11",
      "versioned": true
    },
    "dxvk": {
      "name": "dxvk",
      "created_at": "2023-09-11T20:58:41.103087Z",
      "architecture": "all",
      "url": "https://github.com/lutris/dxvk/releases/download/v2.3/dxvk-2.3.tar.gz",
      "version": "v2.3",
      "versioned": true
    },
  }
}

So, if the game config yaml has dxvk: true (or vkd3d: true), but no dxvk_version or vkd3d_version, we can use the defaults defined in this file. We could store this on the LutrisGame objects.

In the CtInfo dialog, we can't use self.ctool.version because this isn't set for DXVK or vkd3d(-proton). And while we could use self.ctool.displayname, this is risky because of the naming. We append dxvk to the display name if it isn't already present. Lutris saves extracted DXVK versions as, for example, v2.1. For our games list we want to display this more obviously as DXVK, so we the runtime name, f.e. dxvk v2.1. But only if the runtime name isn't already there, so if the folder is named dxvk-2.3, we don't append, so that we don't end up with dxvk dxvk-2.3. See here:

def get_installed_versions(self, ctool_name, ctool_dir):
for ct in get_installed_ctools(ctool_dir):
if ctool_name not in ct.get_displayname().lower():
ct.displayname = f'{ctool_name} {ct.displayname}'
self.compat_tool_index_map.append(ct)

Perhaps storing the version for DXVK and vkd3d(-proton) is the better overall solution here, to avoid parsing out everything after the first space in the string conditionally if we have a certain ctool.ct_type. Not sure how feasible this is, though.

Maybe we need a data class to store general information like this on the LutrisGame, in case we want to get other information in future too, similar to what was described in #346 (comment). Although in that case, we were mapping JSON directly, whereas here we would be working with one yaml file and a JSON file if the runtime is enabled but no version is set...

I messed around with this versions.json file before when working on implementing marking Lutris Wine versions as "global" like we have for Steam, as a follow-up to #314. You can see some of it on a branch I have on my development fork of ProtonUp-Qt: sonic2kk@0171061#diff-2b509fae2fc1ae227755a3c4a401486f5bcbc17608dd2441e61c2dce586b6fdfR55-R90

The approach taken above would probably not apply if we want to generally parse and store the information in this file at the time we build objects.


Not really sure on how we'd want to architect this, but I guess now we know where we can get this information from. The question becomes how we want to retrieve it/store it/etc. We know where to get it, but I don't know the best approach to implement it.

This does not cover Heroic, but we'd probably have to tackle that separately anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants