State of wine-dxvk


The wine-dxvk package hasn’t seen version updates in almost two years at this point, so I was wondering: does anyone know what’s going on?

Asking here, since the maintainer flat-out ignores any questions posted on RHBZ.

You need to find the upstream project and ask them.

The package maintainer maybe as much in the dark as you are.


Probably generally fair advice - however, checking the upstream listed for that package shows that the maintainers of that project have released five subsequent versions over the past ~1 1/2 years, so I think it’s fair in this case to assume a packaging issue.

So, perhaps the more general question is, if the designated package/bug owner appears to be unavailable (assume good intent) to look at new upstream versions, but is still assigned as the maintainer, is there a recommended path for community members who may want to jump in and help?


You can try opening a pull request here. Also see One-Off Contributions. The maintainer may simply be too busy to get around to the update, but willing to merge a PR if somebody else does the work.

You can try to get yourself added as a comaintainer. See Joining the Package Maintainers. You will need to figure out an effective way of communicating with the current maintainer. Since bugzilla doesn’t seem to be working out, try email, or see if the maintainer hangs out in any online forums.

If neither approach bears fruit, then see the Non-Responsive Maintainer Policy.


What period of time can be considered to recognize the project as abandoned ?

Or maybe I should say, Why continue to rebuild a package that has not received maintnance for 2yrs and remove the package? Very much interested in knowing.

As @johnandmegh has pointed out, the upstream development remains active; otherwise I wouldn’t be asking.

Alas, but I simply do not possess the necessary know-how to maintain a package. Incidentally, the maintainer in question appears to be quite active in general.

Properly speaking, there were a few updates in that time frame – just not version ones. My only guess right now is that the package is intentionally held at a legacy version “with relaxed driver requirements”, though doing that on a leading-edge distro wouldn’t make much sense.

So I guess this is slightly off-topic, but is there any reason you couldn’t just add dxvk to the Wineprefix with winetricks -q dxvk? What does this package actually provide?

I don’t know that there is any specific period of time. The policy I mentioned gives a number of steps that must be taken, to give the maintainer opportunity to take action. Those steps require a minimum of 2 weeks.

Are you suggesting that the current wine-dxvk package is not useful? It isn’t the most recent version, certainly, but does it work at all? If so, then there is value in continuing to rebuild it.

1 Like

Maintaining a package is not necessarily hard. My experience has been that the majority of packages are very easy to maintain. There are some which are quite difficult, it is true. I don’t know how difficult wine-dxvk would be.

1 Like

It basically provides and enables DXVK for every prefix automatically (on Vulkan-capable hardware). It’s also a weak dependency of the wine package, so there’s a good chance you have it installed. See also Changes/DXVKwined3d.

As for Winetricks, let’s just say that I’m not fond of using it.

Nice name, by the way.

1 Like

I’m using the Bottles Flatpak at the moment, and Wine through an Arch Toolbox for various reasons. I like to have at least one WineD3D fallback prefix for those games that work better. Though I recently found out that Gamescope’s --force-grab-cursor solved a surprisingly common issue I was having with older games that I couldn’t interact with when using DXVK.

Well, I can’t blame you for having that opinion!


1 Like

1.10.3 is the last DXVK version before the 2.0 release that increased GPU requirements: Driver support · doitsujin/dxvk Wiki · GitHub

I don’t know where that would be an issue, but on Windows with Intel UHD 630 I have to use DXVK 1.10.3 (2.0+ is fine on Linux).

If you know you need a newer version of DXVK, it might be more appealing to get a daily/git build: Workflow runs · doitsujin/dxvk · GitHub

I have a general template for game installs and use DXVK and VKD3D-Proton from git builds. Here’s Diablo II Resurrected for example.

I’m pretty sure this is more of @frantisekz forgetting to do it. Both of us tried to combine the dxvk-native package that I maintain and the wine-dxvk package he maintains into one package for 2.0, but it didn’t work out.

So probably he just forgot to update wine-dxvk after I updated dxvk-native to 2.x.

1 Like

Yeah, bugzillas are more problematic, I am getting tens of them and they slip through, sorry.

The problem with dxvk >= 2.0 is that it requires to use dxvk’s dxgi (where 1.x worked fine with wine’s dxgi implementation). That shouldn’t be a problem, but requires some more testing that stuff doesn’t break. I am planning to take a look at it sooner than later, but I am juggling between bunch of things. If it’s going to break dx9 apps, we’'l need to either wait for win32u: Implement vulkan child / other process surface rendering for winex11. (!5573) · Merge requests · wine / wine · GitLab to land or backport it to the wine package.

Apart from that, I did an update last year backporting all the fixes that arrived in 1.10.x branch post-release: Commit - rpms/wine-dxvk - 7eae638106b9e5fbef7ece94752b956b30041405 -

I’ll try to set up copr for testing at least and post it here with dxvk rebased to 2.x.

1 Like

Yep, that was my theory as well.

And thanks for the links. I’ll take a closer look later.

Thank you for chiming in, and the detailed explanation; it all makes sense now. I would be interested in trying out the Copr release when/if it lands.

Keep up the good work!