protonscr

Feature Request: support default section in config file

dxvkclosed
doitsujin/dxvk#1072 · opened 2019-05-21 by pchome · updated 2019-05-28 · 9 comments · github
Ppchome 2019-05-21 github

In addition to per-app-configuration could you please add [DEFAULT] and/or[default] section support?

  • Would look more like INI file
    [DEFAULT]
dxvk.option = true

[app.exe]
dxvk.option = false
  • Easier to use with python's configparser (requires section, default_section == "DEFAULT")
    #!/bin/env python

import configparser

config = configparser.ConfigParser()
config.read('dxvk.conf')
print('dxvk.option: ' + config['DEFAULT']['dxvk.option'])
    At least protonfixes using this to generate DXVK config files (and likely broken now).
Ddoitsujin maintainer 2019-05-22 github

DXVK config files are no ini files and I refuse to implement anything that breaks current configuration files that people might be using.

Why do we suddenly need support for python libraries that were made for a different purpose?

Ppchome 2019-05-22 github

I don't think it should break current configuration files.

I just think that currently [DEFAULT] treated as a game executable named DEFAULT, but could be just default section. Could be either present or not.

Python is just a simple example.

Ddoitsujin maintainer 2019-05-22 github

I'm just asking for a good reason to add code which is completely useless to the way DXVK functions. Yes, it's easy to add, but it's also the kind of nonsense that makes code a nightmare to maintain if you add enough of it.

Ppchome 2019-05-22 github

I understand.
Unfortunately I have no other reasons. Only those:

  • users can better organize their config file, e.g. placing default options at the end of file.
  • to edit a config file using INI file editor, e.g. a few more strings to python example for zenity support and it could be a simple GUI over dxvk.conf
    I personally using protonfixes, it's the only reason I currently care about. But protonfixes should just add/clean fake sections in generated config files.

The default section shouldn't be exactly named "DEFAULT", use any name you like ("general", "dxvk", ...). I suggest only a default section which don't be compared to exe.

Anyway, feel free to close this request.

LloathingKernel 2019-05-22 github

I hope you don't mind if I offer my two cents on this. I dislike the current ability to specify an exe name for localized options in a system-wide config because games can have their executables with the same names. NFS comes to mind which uses speed.exe as names in some titles.

A different approach to this would be config merging, i.e. setting DXVK_CONFIG="<global_path>;<local_path>" would iterate them sequentially and merge the configs. Configuration from the exe dir could be prefixed or suffixed depending on the merge order. I don't know how easy it would be to implement but to me it is seems like a more unified way to handle this.

That being said, I am neither for nor against said change as I am not actively using it.

Ddoitsujin maintainer 2019-05-22 github

I really don't get why there's so much fuss about the config file.
Here's a rule on how it should be used 99% of the time:

  1. Don't use it.

The only valid reason to use the configuration file is to try out workarounds that aren't enabled by default for a given game yet, or to force-enable/disable Vsync in some games that don't have an in-game option. If there's a game which doesn't work without a given option set, please file a pull request or bug report so that DXVK can apply it by default in the next release.

The global config thing was requested because it allows Lutris scripts to enable workarounds before they make it into a DXVK release, which was a good reason to add it.

Multiple games using the same exe name are a problem, yes, but it's also an issue for the built-in workarounds which probably cannot be solved in any reasonable way. It's also fairly rare so it shouldn't be much of an issue in practice.

In any case, you can still just put a separate dxvk.conf next to the game exe and put your per-game options there. None of this is rocket science, and it shouldn't be; I just get the feeling that some of you want to make it rocket science for no good reason.

Mmisyltoad 2019-05-22 github

The global scope is just the same as the default section you are proposing. This is completely unnecessary.

Ppchome 2019-05-22 github

I just get the feeling that some of you want to make it rocket science for no good reason.

Not me :)

I don't usually use nor global config, neither config in game's directory.
But that thing (protonfixes) generates temporary config file for current game, and all "rocket science" is under the hood:

  • creates empty config
  • merges dxvk.conf from game's directory (if any)
  • applies additional options (if any)
  • sets DXVK_CONFIG_FILE=/tmp/protonfixes_dxvk.conf
  • well, keeping a "garbage" in config file, which previously was ignored by DXVK

Useful tool for me, even if I want to on/off Vsync. But now there is a problem. And I want to know, if proposed change won't happen in DXVK, then I just going to change protonfixes code.

Ddoitsujin maintainer 2019-05-28 github

And I want to know, if proposed change won't happen in DXVK, then I just going to change protonfixes code.

That's probably the better solution.

Launch options