Hello, I am expericing a problem due to updating my wine to 20050524 debian unstable package from wine 20050310. I think there could be a bug as OpenGL stopped working. I have included the info below, so hope someone will be able to confirm, or point me in the right direction if I need to revise my previously all working config.
I could not find any mention of OpenGL config of wine, this is the only mention i found:
http://www.sdconsult.no/linux/wine-doc/opengl-configure.html
I tried this suggestion, it did not fix the problem.
I wonder why my wine install stoped replacing opengl32.dll ?
My nvidia kernel module is functioning fine, glxgears gives me 700FPS, and direct renderering is enabled etc. Call of duty ran fine before I installed this new package.
Please include my email address in any replies.
Kind regards JG
COD MP 1.5 build win-x86 Nov 10 2004 ----- FS_Startup ----- [...] ----- Initializing Renderer ---- ------------------------------- ----- Client Initialization Complete ----- ----- R_Init ----- Initializing OpenGL subsystem ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 1024x768 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 800x600 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 640x480 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL ----- CL_Shutdown ----- RE_Shutdown( 1 ) ----------------------- Hunk_Clear: reset the hunk ok Could not load OpenGL. Make sure that you have the latest drivers for your video card from the manufacturer's web site.
$ wine ./CoDMP.exe trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\user32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\wsock32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"C:\opt\games\CoD\mss32.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\ddraw.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\shell32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "gdi.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "user.exe" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\winex11.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\imm32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "mmsystem.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\msacm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\msacm.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\windows\system\midimap.drv" : builtin fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. Wine exited with a successful status
Hi,
Just responding to my own post. I was discussing with people on #winehq and found the cause of the problem.
...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed
This seems to be because debian unstable package had opengl disabled for as opengl support seems to be in a separate package, libwine-gl in debian unstable now..
Could the important wine config such as this be clearly stated in the output when it is the cause of a fault like this please? (If there is a sane way to do it.. such as seeing the opengl32.dll does not exist before the software fails?)
If it is not mentioned as at present, every user has to hunt for the skel dll and find it is 0 bytes and then discover that indicates wine was not configured with opengl support enabled.
audio does not seem to work in 20050419 from winehq deb. I have "HardwareAcceleration" = "Emulation" in [dsound] which got it working with my old wine install.
I have to force it with "Drivers" = "wineoss.drv" to get it to work.
Is the audio stuff not deciding for its self anymore?
In addition 20050419 package is 1 month older than debian unstables 20050524, is there a plan for a 20050524 winehq deb?
I would also encourage winehq to work with debian maintainers so there are not two groups of people creating packages for debian.
Kind regards JG
On 6/11/05, J. Grant jg@jguk.org wrote:
Hi,
Just responding to my own post. I was discussing with people on #winehq and found the cause of the problem.
...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed
This seems to be because debian unstable package had opengl disabled for as opengl support seems to be in a separate package, libwine-gl in debian unstable now..
Could the important wine config such as this be clearly stated in the output when it is the cause of a fault like this please? (If there is a sane way to do it.. such as seeing the opengl32.dll does not exist before the software fails?)
If it is not mentioned as at present, every user has to hunt for the skel dll and find it is 0 bytes and then discover that indicates wine was not configured with opengl support enabled.
Why not build from source?
audio does not seem to work in 20050419 from winehq deb. I have "HardwareAcceleration" = "Emulation" in [dsound] which got it working with my old wine install.
I have to force it with "Drivers" = "wineoss.drv" to get it to work.
different people have different audio setups.....
Is the audio stuff not deciding for its self anymore?
In addition 20050419 package is 1 month older than debian unstables 20050524, is there a plan for a 20050524 winehq deb?
I would also encourage winehq to work with debian maintainers so there are not two groups of people creating packages for debian.
Again if you build from source who cares if there are 50 debian maintainers. This is why Gentoo is far superior to all those other want-to-be Linux distro's you have no other choice but to build from source :-)
Tom
Kind regards JG
Hi Tom,
[...]
Why not build from source?
Do you mean from source tgz? I do not wish to polute my install, so I would not want to do that. If you meant build the package I think that is an option
Something like this:
apt-get build-dep wine
apt-get --build source wine
audio does not seem to work in 20050419 from winehq deb. I have "HardwareAcceleration" = "Emulation" in [dsound] which got it working with my old wine install.
I have to force it with "Drivers" = "wineoss.drv" to get it to work.
different people have different audio setups.....
I wonder why automatic audio config stopped working since March..?
Is the audio stuff not deciding for its self anymore?
In addition 20050419 package is 1 month older than debian unstables 20050524, is there a plan for a 20050524 winehq deb?
I would also encourage winehq to work with debian maintainers so there are not two groups of people creating packages for debian.
Again if you build from source who cares if there are 50 debian maintainers. This is why Gentoo is far superior to all those other want-to-be Linux distro's you have no other choice but to build from source :-)
I'm thinking you mean tgz rather than package src? Because winehq deb source packages are dated 20050419 and HL2 does not work with them. So me rebuilding from source winehq src deb 20050419 would not make a difference I think.
Also, HL2 does not work with official debian 20050524 either.
Has anyone got HL2 running with either of these unpactched releases please? (I just copied native dlls as in the Howto)
Kind regards JG
On Sun, Jun 12, 2005 at 01:00:14AM +0100, J. Grant wrote:
Could the important wine config such as this be clearly stated in the output when it is the cause of a fault like this please? (If there is a sane way to do it.. such as seeing the opengl32.dll does not exist before the software fails?)
Well, this is a 'feature' in the Debian packaging and I wonder why Wine should do something special just to work around some policy in the Debian world.
And even if Debian shipped the OpenGL32.dll from Wine, it would still fail if the user did not install any GL library on his box...
The question is simply how much fool-proofing we should put in the Wine code to work around basic stuff like that.
Lionel
Hi,
Thanks for your reply. [...]
The question is simply how much fool-proofing we should put in the Wine code to work around basic stuff like that.
I spoke to the Debian package maintainer, their policy is to separate it all so users who do not need cups support do not have to install it seems.
So I think you are right it is probably not wine's responsibility if they must do this separation.
Sorry to disturb, I was unaware of this package separation in debian.
Kind regards JG
-
J. Grant -
Lionel Ulmer -
Tom Wickline