I'm not totally sure I understand your architecture or why exactly you're doing things the way you're doing them, but I think you can get rid of the vglclient error by adding -c 0 to the vglrun command line. VirtualGL will try to automatically detect whether it should use the X11 or VGL transports, and it assumes that if the 2D X server isn't on the same machine, it should use the VGL Transport, which adds compression to the image stream (but requires that you connect using vglconnect in order to start the listener on the 2D X server.)
I'll re-read this when I am in a better position to process it, and perhaps I can offer some more intelligent suggestions. I would definitely like to add TOTP support to TurboVNC. Does that work using PAM? If so, then it can probably be made to work with existing TurboVNC releases. > On Jul 22, 2016, at 4:55 AM, Mathieu Pasquet <mathieu.pasq...@alterway.fr> > wrote: > > Hello, > > We are using VirtualGL in one of our projects, and it’s great, but we > have a specific scenario that creates issues (which are probably not > due to VGL itself, but I feel that here is still the most relevant place > to ask). We use VirtualGL inside docker while sharing both the X11 socket > and /dev/dri while making sure groups & uids match. The goal is to have a > virtual X display inside the docker (with the dummy driver and x11vnc). > We sadly cannot use TurboVNC because it doesn’t to my knowledge offer a > way to run an arbitrary command that would allow us to use TOTP[1]. We > run our software from another container, using: > > DISPLAY=xorg-container:0 vglrun -d :1 ./software. > (:1 being the "3D" X server on the host) > > [1] https://tools.ietf.org/html/rfc6238 > > We were previously using llvmpipe only without sharing anything from the > host, but obviously performance is much worse without hardware > acceleration. We still use mesa everywhere, and the same version in host > and containers. > > It often works, but sometimes fails to initialize and ends after > displaying the following error (and putting the vglrun call in a loop > bypasses that issue): > > X Error of failed request: BadValue (integer parameter out of range > for operation) > Major opcode of failed request: 130 (MIT-SHM) > Minor opcode of failed request: 3 (X_ShmPutImage) > Value in failed request: 0x320 > Serial number of failed request: 16 > Current serial number in output stream: 17 > > I have to point out that VirtualGL 2.4.1 has this (apparently random) > behavior, while VirtualGL 2.5 only has the next error (but which > occurs everytime, preventing us from using it). > > Another strange thing is that we can run glxinfo and it returns the > right information, or our software which works when there isn’t an > error, but any attempt at running glxgears or glxspheres results in > a vglclient error: > > Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) > Visual ID of window: 0x21 > Context is Direct > OpenGL Renderer: Gallium 0.4 on AMD TAHITI (DRM 2.43.0, LLVM 3.8.0) > [VGL] ERROR: Could not connect to VGL client. Make sure that vglclient is > [VGL] running and that either the DISPLAY or VGL_CLIENT environment > [VGL] variable points to the machine on which vglclient is running. > [VGL] ERROR: in connect-- > [VGL] 261: Connection refused > > Running them from the same container but using the :1 display for both > display and rendering does not exhibit this problem. > > When running several of the xorg-vglclient-software instances, we can > also sometimes observe buffers from one instance leaking into another, > or inverted output. > > I would like to inquire if any of these errors ring a bell, or if the > architecture is fundamentally flawed due to DRI, DRM, permissions, or > Xorg shenanigans. > > Best regards, > > -- > > Mathieu Pasquet > R&D Engineer > alter way > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
