Jump to content

markusdd

Members
  • Posts

    7
  • Joined

  • Last visited

  1. One required patch is this one to wine-tkg itself: https://gitlab.winehq.org/wine/wine/-/commit/48ba724640dcf4364f78058b2882866a297acc40 A second one I don't have handy right now but that changes the return value of a DPI scaling function. When they eventually rebase to the newer upstream wine this first patch will be in it but right now it needs to be taken in. Whats a bit more tricky and might cause a conflict is that normal vkd3d is not enough to run on1, as it does not implement all DX12 calls to support DirectML. So you need to run vkd3d-proton in the wine prefix. So it might be possible to have the same wine-tkg but maxybe not the same wine-prefix. (although I think Affinity tools would not be hurt by using vkd3d-proton instead of normal vkd3d) As said we still have 2 issues remaining that need figuring out. Did you publish the patchset from the elemental warrior wine somewhere? Maybe I could play around with my build locally to see how it behaves, I own licenses for On1 and Affinity so it would be easy to check.
  2. This is a very good effort. I have worked with some of the guys on the Nobara Linux discord to get ON1 Photo Raw to run and we've made great progress so far, having it completely running except the AI sharpener and denoiser. If we can get that merged together somewhen to have on workable wine-tkg platform that can run the whole affinity suite and On1 that would be super nice.
  3. @Wanesty The only thing does not work even with the arch distrobox approach above is the export of raster formats like PNG installing mfc140 does noting, installing vcrun2015 breaks all afphoto etc. formats, so is useless and needs rollback. Has there been any consensus what helps here? Is it arch related? Would it be worth trying the distrobox with another distribution?
  4. sure no problem. I should add that to the readme.
  5. yeah I would investigate that if I were you this seems to be some underlying permission issue in your homedir or some other setting. None of this requires root except the /opt/wines dir creation outside the distrobox. EDIT: just saw your edit. Ok, this is a Docker problem. I would advise to use podman instead, which has much less issues in that regard. If you want to keep using docker make sure your user has the proper docker group on your system so the distrobox can access the socket properly in non-root mode. The docker-ce install is not really clean on Fedora and related RedHat distros anymore out of the box.
  6. uh, that should not be necessary actually. using --root is not really recommended for security reasons.
  7. Hi Guys! I just signed up to a) thank @Wanesty and others for their outstanding work on this and b) to confirm that at least under Fedora/nobara 40 the distrobox method seems to work best. I got that running without issue while with the classic approach Wine would not even compile for me anymore after I upgraded from 38/39 a while ago. So I figured I might as well put in the effort and document everything I did to make that work. I also pieced together the info from this long thread about .desktop files with distrobox and and managed to make them generic so the homepath isn't hardcoded and icons are properly found. They are in the doc repo linked below as well. Pull Requests to these docs are welcome. I do want this to be a competition to the original docs but I was lacking an easy 'copy paste' guide for the distrobox approach so I figured I would make one here: https://github.com/markusdd/affinity-linux-distrobox/ I hope this also brings in more stability across base system updates because the distrobox is kind of self-contained, I really do not facny repeating this whole process with each large OS update 😅 I hope this helps somebody!
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.