[VGL] ERROR: Could not open display :8 if a program forks and exits optirun

[isness]

Hello,

Today I got bumblebee updated to v3.0 and there seems to be a problem. Although optirun works for simple apps like glxgears and so on, I got trouble running some games with wine. I get this this error "[VGL] ERROR: Could not open display :8.". Other minor wine apps work with optirun just fine. Power management also seems to be working now. My laptop is Dell Inspiron N5110
Xorg.8.log: http://pastebin.com/CFJLbyFU
syslog: http://pastebin.com/HvUEvp8Q

uname -a: 3.2.0-10-generic-pae #17-Ubuntu SMP Thu Jan 19 21:44:50 UTC 2012 i686 i686 i386 GNU/Linux

Thank you.

[Samsagax]

There is a known problem with some wine applications that fork and kill the parent process without keeping track of it. Maybe we can figure our way around this.

This is a known issue of VGL

[Lekensteyn]

That error is caused by some applications to fork and quit optirun. Workaround: start a shell with optirun and run the wine program from it:

$ optirun bash
$ wine yourprogram

When done, exit bash to notify the daemon that there are no more clients.

[Samsagax]

Maybe we can add an optirun option like --extra-shell that would run this sequence?

[isness]

Thank you, Lekensteyn, it works now. A more user-friendly way of doing this would be great, too. :)

[Lekensteyn]

@Samsagax The extra shell option would not help because optirun cannot be sure when a program exits. Perhaps bumblebeed should wait a bit longer before quitting X.

[Thulinma]

Hmm... We should be able to track the children of these processes using cgroups, just like systemd does. That would require kernel support for those to be enabled though. Enable only if available, perhaps?

[Lekensteyn]

cgroups sounds good, but what if you really want to detach a process and it does not use X?

[Thulinma]

Then why are you running it through optirun? ;-)

[Lekensteyn]

Updated http://wiki.Bumblebee-Project.org/Troubleshooting

I don't know, perhaps to keep the device enabled? It is indeed impossible to know whether the user really wants to use the nvidia card or not for a program started indirectly from optirun.

[Samsagax]

Could you try this:

$ optirun bash wine <your-wine-program>

If that work then my suggestion could work

[Thulinma]

@Samsagax bash will return just as much as our forking method does.

[melroy89]

Can ptrace help us futher maybe?
http://linux.die.net/man/2/ptrace

[raysarvatt]

Does anybody found a solution ?
this bug doesn't afflict the previous version

[Lekensteyn]

@raysarvatt Do you have it with all programs? (even glxspheres?). Have you tried the workaround?

[raysarvatt]

yes,the workaround works.. it's so busy,but it works
I have this bug with some wine applications .. ,the same that worked perfectly,before the latest upgrade ..

[Lekensteyn]

Perhaps you were running other optirun programs at the same time? That's what this workaround basically does.

[raysarvatt]

no,only one application is running with optirun

[Samsagax]

This is related on how we manage power of the card. If bumblebeed notice no instance of optirun is running, then it will kill the second X server. As optirun can't track the forked child then it will exit and won't notice.

[raysarvatt]

I've changed PMMethod=none to PMMethod=auto,but nothing has been changed except

glxgears 1862.182 FPS (before)

1356.261 FPS (after)

[flowerdealer]

I have the same issue trying to run two propietary 3d/fx software packages, Nuke and Houdini. The work if I launch them from the shell like this:
optirun bash
optirun houdini (for example).
However there is no way to run them from the default menu entries in KDE or gnome.

[Lekensteyn]

As a workaround, you can create a wrapper after optirun:

1. Save the below code as /path/to/wait-for-quit:

#!/bin/sh
"$@"
if [ -x /usr/bin/zenity ]; then
    zenity --info --text "Press OK to quit $*"
else
    kdialog --msgbox "Press OK to quit $*"
fi

2. Make it executable: chmod +x /path/to/wait-for-quit
3. Modify your desktop file to run: optirun /path/to/wait-for-quit your-program arguments-for-program

This is still not suboptimal because it'll present a dialog, but it avoid having to open a terminal. If you do not care about power saving at all, edit /etc/bumblebee/bumblebee.conf and set KeepUnusedXServer=true and PMMethod=none (twice)

[raysarvatt]

the script works very well for me .. thanks, Lekensteyn :)

[double-thinker]

Add this fragment to the end of a sh file (INSPIRED IN IRONHIDE)

HERE RUN COMMAND (in my case: wine starcrafII.exe)

while :; do
    if lsof -n -w /usr/lib*/nvidia-current/libnvidia-glcore.so* >/dev/null; then
        sleep 1
    fi
done

To developers: can you add a option --follow-forks or similar??

[derekchiang]

Hello Lekensteyn, I used your script but here is a problem: the dialog pops out in front of my game (Fronzen Throne), and there is no way that I can change focus to my game. I can only click OK to close the dialog, but then my game is also closed. Would you please tell me how to solve this problem? Thanks a lot!

[Lekensteyn]

@derekchiang Then try manually opening the shell as described in #42 (comment)

[derekchiang]

@Lekensteyn Oh yes I tried. It works very well. Just a question: is there a difference between:

optirun bash
wine your-program

and

optirun bash
optirun wine your-program

?

[Lekensteyn]

The second form is redundant. I've never considered whether there are side-effects, but you're suggested to use the first form.

[derekchiang]

@Lekensteyn OK thank you so much!

[ghost]

since most people here are having wine/gamelauncher related issues, I wanted to share the workaround that I found recently:

$> optirun bash -c "wine [your game] && wineserver -w"

this will keep optirun running as long as a wineserver is running, which is typically what you want when you run a game :)

I hope I don't violate any rule by posting this here, but I thought this is the best place to spread the word.

Cheers,
Andy

[ArchangeGabriel]

primus is solving this issue.

[jleclanche]

@ArchangeGabriel Really? I'm having the same issue with primusrun

[ArchangeGabriel]

@jleclanche Could you open a new issue stating what does work and what does not while trying all of optirun -b virtualgl, optirun -b primus and primusrun (plus eventually running a shell using all of those and running you application within that shell)? Thanks.

[sammcj]

Howdy, This is still an issue even with the latest (24/10/2016) bumblebee.

• NVidia drivers x86_64-367.57
• Fedora 25, all updates applied daily
• Stable kernel 4.8.3-300.fc25
• PCI Device: 01:00.0 3d controller: NVIDIA Corporation Device 134b (rev a2)
• Xiaomi MI laptop

Error:

bash Bumblebee daemon reported: error: [XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission Denied

primusrun gives the exact same error.

I have tried the following suggestions:

• Ensuring my user is a member of the 'video' group
• The little zenity script @Lekensteyn wrote
• Updating /etc/bumblebee/xorg.conf.nvidia to add the 'Screen' section
• Disabling power saving and setting KeepUnusedXServer to true
• Tried running an application as the root user itself
• Trying another driver version

Interesting part:

as some others have mentioned, dmesg shows ACPI Warnings about

\_SB.PCI0.RP01.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95)

vgaarb: this pci device is not a vga device

To me, it looks like ACPI is looking at the wrong PCI address, or the wrong identifier (if thats the correct term for the last digit i.e. .0 or .1 on a PCI address?

[Lekensteyn]

@sammcj the last digit of a PCI address is called a function. If you have an Optimus laptop with multiple GPUs, please check with your distro documentation on properly installing/configuring Bumblebee.