because coming from windows only days ago, i have a large project that uses windows based plugins that don’t work in Linux natively, as far as I can tell at least. My intention originally was to dual boot but since I don’t actually own Windows, and I don’t want to purchase a license, and I have experience with Linux, and I was willing to cut my losses, and so on… one thing led to another. I fully get there’s some chores involved figuring out the mountains of RTFM that are inherent to the deal, but maybe someone else out there has already been on that RTFM trail. Also, new to arch and it’s fun. Manjaro seems to be a pretty cool bunch as far as I can tell.
I see. I never use Vital before and I don’t have the same hardware as the one you’re using with. So I can only guess a workaround for your problem. You may also ask Vital’s developer and users about this on their forums. Again, good luck.
The developer, Matt Tytel, has stated he doesn’t support for WINE, but I’m sharing my findings on a thread at his website just for the sake of science.
Is this your output from glxinfo? (edit: I took that from the link you gave)
glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel® HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.2.1
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 21.2.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Have you tried using environment variable to force mesa to use compatibility context? Run
MESA_GL_VERSION_OVERRIDE=4.5 wine 'path/to/your/app.exe' (or just use explorer instead of path to the app. I use that a lot.) and test that app again.
For science, lol, you can run
MESA_GL_VERSION_OVERRIDE=4.5 glxinfo | grep OpenGL and look at your shading language version again.
This fixes it! i repeat, this works!
MESA_GL_VERSION_OVERRIDE=4.5 wine ‘/home/username/.wine/drive_c/Program Files/REAPER (x64)/reaper.exe’
Now all I need is to make persistent “MESA_GL_VERSION_OVERRIDE=4.5”
Good to know. I don’t recommend to pass that environment variable widely on your system, but if you really want to, you can set that per user only or make a shortcut to the wine app with that env on.
Here’s the thread someone started at the Vital forum and I gave you a mention in.
I’m the only user of my system, so where would I set the variable for whenever WINE is started? Otherwise I guess I could build it into a symlink for my Digital Audio Workstation software?
Oops, turns out you won’t be able to pass env on a symlink, but you’re free to try. Anyway, this arch wiki mention about how you can set env globaly, per user, or per session. Maybe worth checking: Environment variables - ArchWiki
Edit: If you’re using KDE desktop, you can pass env by making a .sh file (ie; glcompat.sh) in
export MESA_GL_VERSION_OVERRIDE=4.5 to that file and make it executable. Again, this is only works in KDE desktop. I’m KDE user, btw.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.