Thanks, vglrun -c 0 does fix the vglclient error message, and I assume I have nothing to gain with compression on a virtual internal network. Regarding TOTP, I think there is an experimental third-party PAM module for it, but it’s easier to run an external lightweight command like oathtool (e.g. using x11vnc I only have to specify -passwdfile "cmd:oathtool --totp $SECRET").
2016-07-22 23:14 GMT+02:00 DRC <dcomman...@users.sourceforge.net>: > > 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 -- 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
