Asus - N53SV: Could not get Starcraft II work with wine

[claos]

Hi,

Have done the usual test with glxgears and everything works fine. The problem is that I get this "Could not open display :1." message when trying to run SC2 through wine:

optirun32 wine ./StarCraft\ II.exe

• Starting Bumblebee X server bumblebee
  _PS0 Enabling nVidia Card Succeded. [ OK ] fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (2000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 2000 fixme:win:EnumDisplayDevicesW ((null),0,0x107c0ec,0x00000000), stub! fixme:ddraw:DirectDrawEnumerateExA flags 0x00000003 not handled fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (3000): STUB fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 3000
• Stopping Bumblebee X server bumblebee
  [VGL] ERROR: Could not open display :1.
• .
  _PS0 Disabling nVidia Card Succeded. [ OK ]

BTW, thanks for the great job!

[MrMEEE]

The problem here is that Starcraft forks into some child processes and the kills the original process... And I'm having a hard time finding out how to detect these children..

you should be able to launch the game by:

sudo /etc/init.d/bumblebee enable vglrun -c xv -d :1 -ld /usr/lib32/nvidia-current "wine Starcraft\ II.exe"

[claos]

Now I get this message:

vglrun -c xv -d :1 -ld /usr/lib32/nvidia-current wine ./StarCraft\ II.exe

[VGL] ERROR: Could not open display :1. [VGL] ERROR: Could not open display :1. [VGL] ERROR: Could not open display :1.

[claos]

Another try with the +v option:

vglrun +v -c xv -d :1 -ld /usr/lib32/nvidia-current wine ./StarCraft\ II.exe

[VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] Shared memory segment ID for vglconfig: 4554763 [VGL] Opening local display :1 [VGL] ERROR: Could not open display :1. [VGL] NOTICE: Replacing dlopen("/lib32/libdl.so.2") with dlopen("libdlfaker.so") [VGL] Shared memory segment ID for vglconfig: 4587531 [VGL] Opening local display :1 [VGL] ERROR: Could not open display :1. [VGL] Shared memory segment ID for vglconfig: 4620299 [VGL] Opening local display :1 [VGL] ERROR: Could not open display :1.

[rockorequin]

I get exactly the same thing. It's odd, I could have sworn I had it running successfully in the early days of bumblebee.

Is there a way to tell all new programs to run with vglrun by default? ie so that when the SC2 process forks a new child it gets run with vglrun?

[MrMEEE]

are you sure that you have executed:

sudo /etc/init.d/bumblebee enable

before running the vglrun command???

[MrMEEE]

I also think it worked earlier, I think maybe an update to wine or/and starcraft has changed the way starcraft forks it's processes....

[rockorequin]

OK, I did some more checking and with the original version of StarCraft 2:

• If you enable bumblebee and run it manually with vglrun, StarCraft 2 still runs under wine version 1.3.17. But it doesn't run under the latest version of wine. It doesn't crash with a complaint about display :1, though - it crashes before loading the splash screen with a 'send this error to the makers of starcraft?' error dialog in wine.
• I think it fails if run using optirun because (as mentioned already) the original process forks a child process and finishes early, so optirun sees this shutting down and shuts down the vgl server. I think the child process actually does try to use the vgl server though (and then fails because it has been shut down). The reason that I think this is because I hit the nvidia 'divide by zero' kernel oops several times when I tried to run something else using either optirun or vglrun afterwards. This, of course, requires a complete reboot because it borks the nvidia module.
• I did see the 'cannot access display :1' on at least one occasion. I suspect though that it was because the nvidia module had been borked. Or more likely because I forgot to run bumblebee-enablecard or because I had accidentally run bumblebee-disablecard in the meanwhile.

[rockorequin]

On my system starcraft2 runs a child process for SC2.exe. The child process always has a parent process with pid 1, which is /sbin/init. I guess this means it is created as a parentless process.

Is it possible to query vgl server to see which processes have tried to access display :1 recently? If so, a solution for starcraft2 could be to make optirun wait for a few seconds to allow child processes to start, then check with vglserver, then wait until all processes have finished before shutting down the vgl server, rather than shutting it down once the initial process has terminated. Or just not shut it down if it is still active.

[MrMEEE]

@rockorequin

I've been trying to find a way to detect the child processes... but I really haven't found a way to do it..

"wait" doesn't work because, as you say, the "childs" are parentless... xlsclients doesn't work, because it only show the processes shown on the selected x server.. not the ones executed there...

So right now, I'm really stuck here... if someone has got a good idea.. please shout :D...

[rockorequin]

@MrMEEE:

Here's an idea for a hack in optirun that captures child processes (I have tested it works with SC2, and it doesn't break other wine games):

• Store the pids of the user-created processes before running vglrun.
• After running vlgrun, sleep a bit and the read new set of pids for user-created processes
• Figure out which pids have been created since vglrun and wait for them to terminate before exiting.

It doesn't cater for the case where the user manually creates a new process in the interim, but I figure this is unlikely and the worst case is that optirun will not terminate until this manually-created process finishes, so all it means is that the user may have to manually terminate optirun and possibly shut down bumblebee.

The amount of time to sleep is probably important as it might vary from program to program (or PC to PC). One second is enough for SC2 on my L502x.

Here's the code I used in optirun32:

1. Immediately before vglrun:

   # Store pids, with LF replaced with spaces. Include a trailing space for matching purposes later
   ps1="$(ps -a -o pid=)"
   ps1=$(echo "$ps1 " | tr '\n' ' ')

2. Immediately after vglrun:

   # Store new set of pids. Sleep first to give the child processes time to run
   sleep 1
   ps2="$(ps -a -o pid=)"
   # Remove pids common to both sets to pids created since vglrun was run
   # This will always match the pid of the ps command itself but that isn't important since it has already terminated
   newpids=""
   for pid in $ps2; do
    # Note: check for trailing space ("$pid ") to avoid incorrectly matching "123" with process "1234"
    if ! [[ $ps1 =~ "$pid " ]]; then newpids+="$pid "; fi
   done
   
   if [ "$STOP_SERVICE_ON_EXIT" != "NO" ]; then 
   # Wait for newpids to complete
   for pid in $newpids; do
     while true; do
       # Break if no longer running
       if [ "$(ps -o pid= $pid)" == "" ]; then break; fi
       sleep 0.5
     done
   done
   
   if [ `ps aux |grep optirun |wc -l` -lt 4 ]; then

By the way, that last line detecting other bumblebee processes also catches the command "gedit /usr/local/bin/optirun32" and so optirun doesn't shut down bumblebee if you are editing it!

[rockorequin]

Something that might improve the hack is to time the vglrun command, and only wait for newly-created child processes if it has run for a short period of time (10 seconds? 30 seconds?). That way if you run an app that lasts for hours, optirun won't then wait for any new processes you might have started in the interim. Having said that, ps -a run from a gnome-terminal seems to only show processes opened from that gnome-terminal or other gnome-terminals, so it might not be all that important.

[tkalfaoglu]

This is probably naive, but why not have a popup on screen that says, click here when you are done with the game?

[rockorequin]

I think the idea is to make the power handling code automatic so the user doesn't have to worry about it, and having a popup would require extra user intervention that in most cases would be unnecessary. And since the optirun script can be modified to handle rapidly-forked parentless child processes, it isn't even really needed for SC2.

[MrMEEE]

This problem is fixed in newest version (1.6.31)...

Please reopen if problem persists...

[rockorequin]

The server keeps running, but the solution could be made more elegant. There are two issues with it:

1. These two error messages continually get spewed out:

   lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /root/.gvfs
        Output information may be incomplete.
   Another bumblebee powered application is running, keeping bumblebee alive.

I guess the first could be fixed by sending stderr to /dev/null, and the second could be fixed by only reporting it the first time through the loop.

1. If you are already running another nvidia-accelerated application (eg try running optirun glxgears first), the second optirun process never terminates even after you finish playing starcraft (and of course you get the error messages continually spewed out). In other words, each optirun script will keep running forever until every vglrun command is finished.

This could be fixed by looking for new child processes and only waiting on these before finishing.

[MrMEEE]

I think latest update should fix both problems...

[rockorequin]

Thanks, it does!

[rockorequin]

It does always say "Another bumblebee powered application is running, keeping bumblebee alive.", every time (and then shuts down the server). I think this must be because libnvidia-glcore stays running a bit longer than the application. Perhaps it should sleep for a second before the first lsof check?