Xpra: Ticket #320: Xpra + VirtualGL

I use Xpra to run applications remotely and it works fine for 2D applications. I did as follows:

  1. on the remote server, run
        xpra start :100
        DISPLAY=:100 firefox
    
  2. on the local machine
        xpra attach ssh:user@remoteserver:100
    

i can see the firefox display at local machine correctly. Then, i try a 3D game (with OpenGL) but the game cannot display at local machine correctly. (note that server have hardware 3d acceleration and can run the game itself correctly).

Then, i try to use virtualgl to solve this problem and i did like this:

  1. on the remote server, run
        xpra start :100
        DISPLAY=:100 vglrun 3Dgame
    

however, it does't work. I don't know the reason, any can help me? or have other method to achieve my goal? thanks~



Sun, 21 Apr 2013 03:26:52 GMT - Antoine Martin: description changed

VirtualGL does work with xpra.
"it doesn't work" isn't very descriptive, I suspect there were some error messages you aren't telling us about. Check the server log file.
You are probably using Xvfb which does not support GL, so you want to switch to using Xdummy.


Sun, 21 Apr 2013 06:59:35 GMT - liyusen:

thanks for you quick reply.

I really did not use Xdummy. When I run the 3D game with vglrun on the server, the error message of this xpra session is as follows (I didn't see any picture in the client side):

"Error parsing property WM_TRANSIENT_FOR (type window); this may be a misbehaving application, or bug in Wimpiggy
  Data: '\x00\x00\x00\x00'[...?]
"

Is this error caused by Xvbf? If I use Xdummy, it should work? thanks!


Sun, 21 Apr 2013 08:20:49 GMT - Antoine Martin:

The Error parsing property WM_TRANSIENT_FOR ... may or may not be related, it's hard to tell. What is the application (3d game?) you are using? Can I try to run it? It seems to be setting WM_TRANSIENT_FOR for one of its window to an invalid window (id=0x0000), which means that we correctly discard the invalid data. This should not in itself be a showstopper for the application to run.
In any case, I believe that you will not be able to use GL in any application without running it on an X11 server that does support GL, and in this case that means using Xdummy with xpra.


Sun, 21 Apr 2013 08:29:27 GMT - liyusen:

thanks very much. I am trying to use Xdummy to test again. Currently i use vmware to install fedora 17/18 to do the test. However, 3d acceleration is supported by vmware for fedora 17 but fedora 17 cannot run Xdummy... Fedora 18 can run xpra with Xdummy but the 3d acceleration is not supported by vmware...

I think i need to install a real fedora 18 system with Nvidia drivers. then i will discuss with you again.


Sun, 21 Apr 2013 08:35:32 GMT - Antoine Martin:

I am pretty sure that Fedora 17 can use Xdummy as it ships with:

And I have used it successfully for months before Fedora 18 came out.

Again:

What is the application (3d game?) you are using? Can I try to run it?

BTW, here is the documentation for WM_TRANSIENT_FOR


Sun, 21 Apr 2013 08:47:34 GMT - liyusen:

The game is openarena, "yum install openarena" can install it easily. The xpra.conf in Fedora 17 have the following options:

The default one after installation is (3). When i choose (2), the xpra server cannot start correctly. Do you know the problem? thanks.

I also tried another option:

xvfb=xpra_Xdummy -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf

, the server can start, but we have the following errors: Xlib: extension "RANDR" missing on display :105.


Sun, 21 Apr 2013 08:57:14 GMT - liyusen:

I installed fedora 17 on windows (with Nvidia drivers) by using vmware and open the 3d acceleration provided by vmware player. So, i am not sure it has some problems?


Sun, 21 Apr 2013 08:58:15 GMT - Antoine Martin:

(1) and (3) are the same. The reason why (2) cannot be used is because Xorg is installed suid on Fedora. In an ideal world, Fedora 17 should be using the xpra_Xdummy wrapper you posted above, but because Fedora ships Xorg non world-readable by default, it cannot be used either and we are forced to use Xvfb as a fallback instead. (this is all explained on the Xdummy page).


In your case, you do really want to be using xpra_Xdummy, so make sure Xorg is world-readable and please post its log output. The point of using Xdummy is that you can use the extensions we specify on the command line (which include RANDR and GLX) - so the Xlib warning is very odd here.


Sun, 21 Apr 2013 09:08:13 GMT - liyusen:

the following is the log to start :110 when i use the xpra_Xdummy, before that i use chmod +r /usr/bin/Xorg to make the Xorg readable:

** (xpra:1872): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (xpra:1872): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (xpra:1872): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Xlib:  extension "RANDR" missing on display ":110".
Xlib:  extension "RANDR" missing on display ":110".
Xlib:  extension "RANDR" missing on display ":110".
2013-04-21 01:04:49,356 server uuid is 3e52397bd41d466ba088235042458df9
2013-04-21 01:04:49,362 Warning: X server does not support required extension Randr
2013-04-21 01:04:49,440 error loading or registering our dbus notifications forwarder:
2013-04-21 01:04:49,440   the name 'org.freedesktop.Notifications' is already claimed on the session bus
2013-04-21 01:04:49,440 if you do not have a dedicated dbus session for this xpra instance,
2013-04-21 01:04:49,441   you should use the '--no-notifications' flag
2013-04-21 01:04:49,441
2013-04-21 01:04:49,446 pulseaudio server started with pid 1882
2013-04-21 01:04:49,447 xpra server version 0.8.8
E: [pulseaudio] pid.c: Daemon already running.
2013-04-21 01:04:49,488 xpra is ready.
2013-04-21 01:04:51,101 New connection received: SocketConnection(/home/user1/.xpra/localhost-110)
2013-04-21 01:04:51,104 connection closed after 0 packets received (0 bytes) and 0 packets sent (0 bytes)
2013-04-21 01:04:51,104 Connection lost
2013-04-21 01:04:51,448 Warning: pulseaudio has terminated. Either fix the pulseaudio command line or use --no-pulseaudio to avoid this warning.

Sun, 21 Apr 2013 09:13:50 GMT - ahuillet:

This seems unrelated to VirtualGL, and feels to me more like a request for help than an actual bug.


Sun, 21 Apr 2013 09:17:43 GMT - liyusen:

yeah, its a help not a bug...


Sun, 21 Apr 2013 10:55:42 GMT - Antoine Martin:

Half those warnings already tell you what to do:

The GFlags warnings are GTK things and beyond our control, I believe you can just ignore those.

Apart from that I don't see any new errors - just the odd RANDR one, but please post:


It's also worth trying to launch xpra with the --xvfb= switch to really make sure that you are using Xorg via xpra_Xdummy and not Xvfb. My bet is that you are using the latter for whatever reason. When I use Xorg, I get the Xorg launch messages shown on screen, version and all.


Sun, 21 Apr 2013 11:39:34 GMT - liyusen: attachment set


Sun, 21 Apr 2013 11:39:49 GMT - liyusen: attachment set


Sun, 21 Apr 2013 11:40:01 GMT - liyusen: attachment set


Sun, 21 Apr 2013 11:40:12 GMT - liyusen: attachment set


Sun, 21 Apr 2013 11:44:04 GMT - liyusen:

you are right. when i use

xpra --xvbf="xpra_Xdummy -dpi 96 -noreset -nolisten tcp \
   +extension GLX +extension RANDR +extension RENDER \
   -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf" start :101

it does start Xorg successfully. The session log is attached. Then i run:

export DISPLAY=L:101
vglrun openarena

it still cannot display the picture of the game correctly. The glxinfo and xpdyinfo and the xpra.conf are all attached.

Thanks so much for your time and answers.


Sun, 21 Apr 2013 13:22:10 GMT - Antoine Martin:

That makes more sense, you should be able to get the same result by ensuring that the xvfb= command you used is in your /etc/xpra/xpra.conf (they are all commented out at the moment in the file you posted).

What do you mean by:

it still cannot display the picture of the game correctly.

Do you get a picture at all? If so, can we get a screenshot?

TBH, I think it is unlikely to work out-of-the-box without some changes to xpra (games expect to run fullscreen and I'm not sure how well we cope with that) I'm downloading it right now and I'll give it a go. (vglrun allowing... it doesn't play well with fglrx which I have installed)


Sun, 21 Apr 2013 13:44:17 GMT - liyusen:

What do you mean by: it still cannot display the picture of the game correctly. Do you get a picture at all? If so, can we get a screenshot?

Normally, when i use xpra server to run an application, the screen of this application should be displayed at client side (suppose the client has attached to the server). Here I mean when i use xpra only (no vritualgl) to run "openarena", i will get an error at xpra client side something like "the application cannot run because 3D acceleration is not supported in your machine". (This error normally happens for some other remote protocols such as VNC when running a 3D application). I think virtualgl is just designed for solving this kind of issue. When i use virtualgl with xpra and run "vglrun openarena" at server side, the above error disappeared at client side, but the game screen still cannot be displayed at the client side.

Have you run other 3D applications successfully by xpra + virtualgl?


Sun, 21 Apr 2013 13:50:46 GMT - Antoine Martin:

Yes, xpra + virtualgl runs fine, the problem with "openarena" is likely to be the fullscreen handling code (#264).


As I expected, fglrx prevents me from testing xpra + virtualgl + openarena at the moment, sorry.
Any suggestions for fixing that would be most welcome:

$ vglrun glxgears
ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  152 (GLX)
  Minor opcode of failed request:  19 (X_GLXQueryServerString)
  Serial number of failed request:  12
  Current serial number in output stream:  12

Pretty much exactly what is described in Using VirtualGL with setuid/setgid Executables, except I'm not using suid executables and I've disabled SELinux for testing, installed the 32-bit libraries, etc.


Sun, 21 Apr 2013 14:01:09 GMT - liyusen:

ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

for the above two errors, i just copy the above two libs from VirtualGL folder to /usr/lib/


Sun, 21 Apr 2013 14:06:22 GMT - liyusen:

glxgears and glxsphere both can run successfully with xpra + virtualgl in my case. Are these 3D applications with 3d accelerations? I am not familiar with these apps... but it is interesting that when i run glxshpere at server without xpra and virtualgl, the frame rate is very high. when i use "vglrun glxsphere", the frame rate is much low...


Sun, 21 Apr 2013 14:10:31 GMT - Antoine Martin:

glxgears and glxinfo are the most common GL test/diagnostics applications, glxspheres comes as part of VirtualGL and is also good for testing.

Something's not right, it *should* be giving you a higher framerate with vglrun. I will test later on an intel laptop (still downloading..)

In the meantime, maybe ahuillet can help/comment?


Sun, 21 Apr 2013 14:10:45 GMT - ahuillet:

Please read the documentation of VirtualGL. This:

ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

means that you're doing something wrong.


Sun, 21 Apr 2013 14:16:20 GMT - liyusen:

Replying to ahuillet:

Please read the documentation of VirtualGL. This:

ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored.

means that you're doing something wrong.

that's right. the errors can be removed by copying the libs to /usr/lib/. i think virtualgl is running correctly in computer. maybe i will check the log of virtual to make sure it runs correctly.


Mon, 22 Apr 2013 05:37:37 GMT - liyusen:

I also tried some other 2d/3d games like supertuxkart, megaglest, lacewing etc.. none of them works with xpra. But i can play all the games remotely with TigerVNC + virtualgl. It seems strange...


Mon, 22 Apr 2013 05:41:47 GMT - Antoine Martin:

Like I said, this is probably because of the fullscreen hint (#264)

And all the advice above regarding VirtualGL is misguided: it was working before and now that fglrx is installed it doesn't anymore - so the problem is not a setup issue and I certainly don't need to RTFM for the tenth time.

TigerVNC can handle it because it isn't seamless and therefore does not need to do anything to handle a fullscreen client app.


Mon, 22 Apr 2013 05:45:13 GMT - liyusen:

i also tried openarena with non-fullscreen mode, it also does not work. So, do you have any suggestion that if i want to use xpra to run 3d games remotely? thanks~


Mon, 22 Apr 2013 05:46:41 GMT - Antoine Martin:

Sorry no, without handling #264 and related hints, which is on the TODO list.

Can I close this ticket?


Mon, 22 Apr 2013 05:48:55 GMT - liyusen:

actually, the main reason i choose xpra is that x264 video encoding is used. The original method used in VNC is not good for games and video applications. In your opinion, x264 has really improved the video quality very much? thanks~


Mon, 22 Apr 2013 05:49:48 GMT - liyusen:

ok, i think you can close the ticket. really thanks for your help and advice~


Mon, 22 Apr 2013 05:54:26 GMT - Antoine Martin: status changed; resolution set

Vaguely answering your x264 question: x264 can only improve the quality compared to other lossy encodings (jpeg, webp, vpx), not compared to lossless ones (rgb24, png). Where x264 shines is in providing a very good framerate with good-enough quality (good enough for games, not always good enough for desktop applications). It is often an order of magnitude more efficient than lossless encodings.

If you want to run games, you will need #264 but also #137

Closing, as setting up VirtualGL is not an xpra issue and xpra is known to work fine with VirtualGL.


Thu, 25 Apr 2013 06:06:51 GMT - ahuillet:

Please make sure that "vglrun glxgears" works in a Xpra session. If you're trying to play a fullscreen video game, this is unlikely to work, but if you switch to windowed it will be fine. Known issue. :)


Mon, 01 Feb 2016 18:03:09 GMT - urzds: cc set


Sat, 23 Jan 2021 04:51:36 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/320