Wine question, I realize it’s not exactly a Manjaro deal.
Any Ideas what needs to happen to upgrade WINE’s OpenGL?
I need OpenGL 1.4 functionality in WINE.
AFAIK wine is using the GPU driver, here is an example from my end:
So please share from terminal:
inxi -Fazy
2 Likes
I’m using the Intel i5’s inbuilt GPU.
Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (Intel Corporation)
I don’t see the OpenGL info in WINEcfg. Can you tell me how you found that information?
The OpenGL Version is just like DirectX. So a GPU which can run DirectX9 cannot run Directx12 and therefore if the GPU can run OpenGL 1.3, it cannot run OpenGL1.4. There is no way to upgrade the software. You need to upgrade the GPU.
I use a software that requires it and can’t work without it. Once it works it displays that information.
But you can open up terminal and check:
glxinfo | grep version
that can’t be true because I can use the software fine in windows on the same machine.
Are you sure about the version numbers. OpenGL 1.4 is very old, it is more then 20 years old. And OpenGL 1.3 is even older.
1 Like
Then please show us?
EDIT: I searched and it must be some sort of this GPU:
And there it say:
OpenGL 4.3
NOT 1.3 
3 Likes
For whatever reason, WINE is not reporting that to the program I am trying to run. The developer does not support running his software in WINE.
How can I check the version of OpenGL that WINE is using? I can easily do glxinfo | grep OpenCL which shows the expected information from Konsole in Manjaro’s KDE environment, but how can I see what WINE is seeing and what hooks or whatever are available for windows software to see when I’m trying to run them?
Run your program like this:
WINEDEBUG=+wgl wine your_3d_app.exe &> wine.log
It will save the log to wine.log.
There you should see which version and why it is reported.
Upload the log or post it here as code.
Just a thought: Maybe for some reason it fallback to software rendering?
i executed the command:
winedebug=+wgl wine Vital.exe &> wine.log
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found.wine: Unhandled page fault on write access to 0000000000000000 at address 00007FAA5262E9BB (thread 0070), starting debugger…
0070:err:seh:start_debugger Couldn’t start debugger L"winedbg --auto 96 64" (1115)
Read the Wine Developers Guide on how to set up winedbg or another debugger
I’ve been searching around and found that to fix that vulkan error you need DRI3 enabled.
To enable DRI3, you need to create a config for the integrated card adding the DRI3 option:
Section “Device”
Identifier “Intel Graphics”
Driver “intel”
Option “DRI” “3”
EndSection
So the problem was not OpenGL, but Vulkan? 
this is the error that the program gives me, along with a black window where graphics should be:
and wine.log makes no mention of OpenGL at all. There is a native Linux version that works, as well as Windows and OSX. But I need the Windows version to run in WINE for reasons.
I’m pretty sure the problem is related to the Haswell-Vulkan thing, going by the output in wine.log
I tried to go into xorg.conf (i know, scary) and it appears to be blank and I don’t want to create anything in there because I’d like there to be a Manjaro-y way to ‘enable DRI3’
That clearly says, that there is no file called “Vital.exe”. Vital.exe must be in your working dir.
Nope sorry. It is not. Have you installed DXVK? If not, then not related.
So, come on. If you want to solve you problem with that app yourself, then go for it, but if you want help, then let us not poke in the dark.
How did you install that program?
Which program?
1 Like
The program has a windows, linux, and OSX installer and is found at:
I used the windows installer thru WINE on a fresh installation of Manjaro, (which does not work) in addition to the Linux native installer, which does work no problem. Which is why I’m leaning towards this being a WINE configuration issue but I can’t see anything in WINE about which OpenGL version it thinks it is using other than the strange error message that says this:
wine taskmgr:
the debugger code I’m using:
winedebug=+wgl wine Vital.exe &> wine.log
the contents of wine.log is now the following, regardless if Vital.exe is already running or if it is being instantiated by the winedebug command:
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found.
and yes, it does feel like I am shooting in the dark over here, but I’ve been around long enough to not lash out and get angry at folks trying to help me so never fear!
here’s a screeny of the WINE window where the GUI ought to be:
I just saw it. WINEDEBUG in uppercase is important. Type it just as I wrote.
I run this program myself… this part is important:
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GL version : 4.6.0 NVIDIA 470.63.01.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GL renderer : NVIDIA GeForce GTX 1050 T
i/PCIe/SSE2.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Server GLX vendor: : NVIDIA Corporation.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX version : 1.4.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Client GLX vendor: : NVIDIA Corporation.
00fc:trace:wgl:X11DRV_WineGL_InitOpenglInfo Direct rendering enabled: True
So it looks for the GLX Version, which is 1.4 for me. But yours have to be 1.3 then. I guess this is not upgrade-able since it is fixed version for the GPU and you are on a bleeding edge mesa driver. It is hardcoded into the code and ensures that only GPUs, which are capable with the additional features of the next version, will work.
To unlock that, you have to hack the mesa code and compile it yourself. But don’t expect it will work flawless.
At least you know it asks for the GLX Version and not for GL Version.
glxinfo | grep "GLX version"
Why does it work on Windows on the computer? I guess the driver is here to blame. But indeed changing DRI2 to DRI3 could probably solve this problem.
- Add a file:
/etc/X11/xorg.conf.d/20-intel.conf
- Put this into it:
Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "3"
EndSection
- Reboot
Possible it will not work and you end with a black screen. It is good to have a Manjaro Boot Disk ready, just in case. To revert it, just delete this file on a Live Session.
2 Likes
I’ve done the WINEDEBUG thing a few times, no wonder I got different results in subsequent tries after having forgotten to write it rude.
but the plot thickens: (this is before writing any conf file. a true mystery why WINE is confus.)
I’ve written the conf file to the directory you specified. battening down the hatches and got my trusty bootable USB stick with Manjaro KDE in tow. See you on the flip side 
edit:
Ok I’m back, and there was a bit of jitter happening on reboot, and WINE needed to do some reconfiguring, but the GUI of Vital is still black. Now however the ‘exception’ messages are gone. I’ll have to see if I will leave that conf file in place, maybe it’s useful but not sure.
[edited] First you can open wine regedit, create a new registry key named Direct3D in HKEY_CURRENT_USER\Software\Wine if it’s not already there, create a new DWORD string in Direct3D, name it MaxVersionGL and add 10004 as the value. That will/may force wine to report higher opengl (and direct3d) support up to v1.4 to the apps. But it’ll comeback to your actual hardware capabilities and driver. If by any chance mesa is the one that doesn’t report correctly, then you can force it by environment variable MESA_GL_VERSION_OVERRIDE=1.4
Good luck.
I’ll try that suggestion with Regedit in WINE and see what happens. I have no idea what to think after searching this topic and getting results that only deepened the waters.
If I may ask, why using WINE if the app have native linux version?