virtualgl-users — VirtualGL User Discussion and Support (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)

[VirtualGL-Users] Siemens NX

[DRC <dco...@us...>]

Wondering if anyone reading this has had any experience (positive or
negative) with running Siemens NX in VirtualGL.  A user is reporting
that the application seems to want to use software OpenGL, and we can't
figure out how to force it not to.

DRC

Re: [VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[DRC <dco...@us...>]

Referring to the VirtualGL User's Guide, Display :0 is what we refer to
as the "3D X server", because it has a GPU attached.  Display :10 in
your case is what we refer to as the "2D X server."  The 2D X server is
also, in your case, an "X proxy":  an X server that renders X11
primitives into images using a virtual framebuffer located in the
system's main memory (Xvfb, for example, is another type of X proxy,
although in that case, there is no remote display server attached to
it.)  You can't see the output of glxgears when it is routed to Display
:0, because that output is going to the monitor attached to the graphics
card (assuming it even has a monitor-- some nVidia GPUs are headless,
and the 3D X server acts solely as a way of accessing the GPU for
off-screen rendering.)

Because X proxies aren't "real" X servers, they can't ever render OpenGL
with hardware acceleration (because doing so requires that the
framebuffer reside in GPU memory, not in main memory.)  Some X proxies
don't support OpenGL at all.  XRDP apparently doesn't.  Upon further
examination, XRDP does work in concert with TigerVNC to support VNC
clients, but it is its own separate solution, and apparently the X proxy
in XRDP doesn't support GLX and OpenGL.  Even if it did, its
implementation of OpenGL still wouldn't be hardware-accelerated.  In
short, don't become overly focused on the fact that you have to use
vglrun to launch glxgears.  That's going to be the case more often than
not when dealing with X proxies, and it's the reason VirtualGL exists.
VirtualGL splits the 3D rendering and sends it to Display :0.
Meanwhile, the 2D rendering goes to Display :10, and whenever the 3D
application swaps its buffer, VirtualGL reads those pixels back from the
GPU and composites them into Display :10.

As Robert indicated, we also do recommend that you use TurboVNC, because
it is designed to provide the performance necessary to run 3D
applications interactively, and it has additional features that are
designed specifically around the needs of such applications.  RDP will
be somewhat slower.  TurboVNC is also a lot easier to install and configure.


On 9/18/16 6:37 PM, Joshua Moore wrote:
> I'm able to get glxgears  to run without vlgrun to run on DISPLAY 0 over
> the Remote connection, but then it doesn't show any graphics on my
> remote display (which is :10), but I get the text output.  I can also
> get it to run using ANSYS's Mesa libraries oddly
> enough /ansys_inc/v172/Framework/bin/Linux64/Mesa.  
>
> I played around with trying to get the right libraries to load in /lib64
> /lib /usr/lib and /usr/lib64, but I still wasn't able to get it to run
> without vlgrun.  
> 
> I am basically following the setup here for XRDP + TigerVNC for Remote
> Desktop (with the addition that I also had to add ssl certificates to
> get it to work)
> 
> http://www.padtinc.com/blog/the-focus/how-to-install-and-configure-xrdp-and-same-session-xrdp-on-centos-6-7-rhel-6-7
> 
> That page suggests to add to xorg.conf  
> 
>   * Section “Module”
>   * Load “extmod”
>   * Load “due”
>   * Load “type1”
>   * Load “freetype”
>   * Load “clx”
>   * EndSection
> 
> However, after doing this and rebooting, then vlgrun doesn't work anymore.  
> 
> Anyway, it is working now it seems.  I can use 
> 
> VGL_LOGO=1 vglrun glxgears (or glxspheres64 or runwb2) and then I get
> the VGL_LOGO to appear, which I think means I am getting hardware
> acceleration.
> 
> Thanks.
> 
> Josh
> 
> 
> 
> 
> On Sun, Sep 18, 2016 at 6:13 PM, Robert Goley <ra...@rd...
> <mailto:ra...@rd...>> wrote:
> 
>     My understanding of xrdp is that it is a stand alone x server just
>     like turbo NC or TigerVNC are. I question how you are running both x
>     servers with a single X client. I would recommend using just
>     turbovnc on the server and the turbo vnc client with security
>     extensions turned on to replace the use of rdp entirely.
> 
> 
>     On Sep 18, 2016 12:39 AM, "Joshua Moore" <jd...@nc...
>     <mailto:jd...@nc...>> wrote:
> 
>         I think I figured it out finally.
> 
>         I only can get it to work using 
> 
>         vglrun runwb2
> 
>         Previously I had LD_LIBRARY_PATH to include
>         /ansys_inc/v172/Framework/bin/Linux64/Mesa.  I think that was
>         overriding some of the NVIDIA drivers or something.  
> 
>         Now it runs and doesn't crash and no errors.
> 
>         Why can't I get glxgears to run without  (vglrun glxgears).  Is
>         it not compatible with NVIDIA's OpenGL libraries?
> 
>         Thanks.
> 
>         Josh
> 
> 
> 
> 
>         On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jd...@nc...
>         <mailto:jd...@nc...>> wrote:
> 
>             Hello,
> 
>             I am using Windows Remote Desktop to connect to a CentOS7.2
>             box with a NVIDIA GeForce GT 720 graphics card.  I also have
>             a NVIDIA Tesla K40c on it as well.
> 
>             I am using TigerVNC and XRDP and then launching workbench with 
> 
>             vglrun runwb2
> 
>             Everything seems to work ok, except when I try to open
>             "System Coupling".
> 
>             Then I get
> 
>             [VGL] ERROR: in init--
>             [VGL] 218: Invalid argument
>             Exception caught in virtual
>             Ans::Graphics::Scene::EventProcessor::~EventProcessor() @line176
> 
>             Then Workbench closes immediately with no other error message
> 
>             I am very new to using VNC, and Remote Desktop to access
>             Linux, as well as even newer to OpenGL and VirtualGL.  
> 
>             Does anyone know what is going on?  Or if someone else is
>             using ANSYS and can duplicate this error?
> 
>             I have ANSYS on another machine running CentOS7.2.  It does
>             not have a NVIDIA graphics card.  Actually I'm not even sure
>             what kind of graphics card it is running, but it definitely
>             isn't a good one.  It runs just fine.  I can open ANSYS
>             without VirtualGL just with runwb2 and can open System
>             Coupling and it seems to run just fine.  I do get error in
>             the WorkbenchLog files which state that I don't have
>             hardware acceleration.
> 
>             Thanks.
> 
>             Josh

Re: [VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[Joshua M. <jd...@nc...>]

Thanks Robert and DRC,

I'm able to get glxgears  to run without vlgrun to run on DISPLAY 0 over
the Remote connection, but then it doesn't show any graphics on my remote
display (which is :10), but I get the text output.  I can also get it to
run using ANSYS's Mesa libraries oddly enough
/ansys_inc/v172/Framework/bin/Linux64/Mesa.


I played around with trying to get the right libraries to load in /lib64
/lib /usr/lib and /usr/lib64, but I still wasn't able to get it to run
without vlgrun.

I am basically following the setup here for XRDP + TigerVNC for Remote
Desktop (with the addition that I also had to add ssl certificates to get
it to work)

http://www.padtinc.com/blog/the-focus/how-to-install-and-configure-xrdp-and-same-session-xrdp-on-centos-6-7-rhel-6-7

That page suggests to add to xorg.conf


   - Section “Module”
   - Load “extmod”
   - Load “due”
   - Load “type1”
   - Load “freetype”
   - Load “clx”
   - EndSection

However, after doing this and rebooting, then vlgrun doesn't work anymore.

Anyway, it is working now it seems.  I can use

VGL_LOGO=1 vglrun glxgears (or glxspheres64 or runwb2) and then I get the
VGL_LOGO to appear, which I think means I am getting hardware acceleration.

Thanks.

Josh




On Sun, Sep 18, 2016 at 6:13 PM, Robert Goley <ra...@rd...> wrote:

> My understanding of xrdp is that it is a stand alone x server just like
> turbo NC or TigerVNC are. I question how you are running both x servers
> with a single X client. I would recommend using just turbovnc on the server
> and the turbo vnc client with security extensions turned on to replace the
> use of rdp entirely.
>
> On Sep 18, 2016 12:39 AM, "Joshua Moore" <jd...@nc...> wrote:
>
>> I think I figured it out finally.
>>
>> I only can get it to work using
>>
>> vglrun runwb2
>>
>> Previously I had LD_LIBRARY_PATH to include /ansys_inc/v172/Framework/bin/Linux64/Mesa.
>> I think that was overriding some of the NVIDIA drivers or something.
>>
>> Now it runs and doesn't crash and no errors.
>>
>> Why can't I get glxgears to run without  (vglrun glxgears).  Is it not
>> compatible with NVIDIA's OpenGL libraries?
>>
>> Thanks.
>>
>> Josh
>>
>>
>>
>>
>> On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jd...@nc...> wrote:
>>
>>> Hello,
>>>
>>> I am using Windows Remote Desktop to connect to a CentOS7.2 box with a
>>> NVIDIA GeForce GT 720 graphics card.  I also have a NVIDIA Tesla K40c on it
>>> as well.
>>>
>>> I am using TigerVNC and XRDP and then launching workbench with
>>>
>>> vglrun runwb2
>>>
>>> Everything seems to work ok, except when I try to open "System Coupling".
>>>
>>> Then I get
>>>
>>> [VGL] ERROR: in init--
>>> [VGL] 218: Invalid argument
>>> Exception caught in virtual Ans::Graphics::Scene::EventProcessor::~EventProcessor()
>>> @line176
>>>
>>> Then Workbench closes immediately with no other error message
>>>
>>> I am very new to using VNC, and Remote Desktop to access Linux, as well
>>> as even newer to OpenGL and VirtualGL.
>>>
>>> Does anyone know what is going on?  Or if someone else is using ANSYS
>>> and can duplicate this error?
>>>
>>> I have ANSYS on another machine running CentOS7.2.  It does not have a
>>> NVIDIA graphics card.  Actually I'm not even sure what kind of graphics
>>> card it is running, but it definitely isn't a good one.  It runs just
>>> fine.  I can open ANSYS without VirtualGL just with runwb2 and can open
>>> System Coupling and it seems to run just fine.  I do get error in the
>>> WorkbenchLog files which state that I don't have hardware acceleration.
>>>
>>> Thanks.
>>>
>>> Josh
>>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>>
>> _______________________________________________
>> VirtualGL-Users mailing list
>> Vir...@li...
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>
>>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>

Re: [VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[Robert G. <ra...@rd...>]

My understanding of xrdp is that it is a stand alone x server just like
turbo NC or TigerVNC are. I question how you are running both x servers
with a single X client. I would recommend using just turbovnc on the server
and the turbo vnc client with security extensions turned on to replace the
use of rdp entirely.

On Sep 18, 2016 12:39 AM, "Joshua Moore" <jd...@nc...> wrote:

> I think I figured it out finally.
>
> I only can get it to work using
>
> vglrun runwb2
>
> Previously I had LD_LIBRARY_PATH to include /ansys_inc/v172/Framework/bin/Linux64/Mesa.
> I think that was overriding some of the NVIDIA drivers or something.
>
> Now it runs and doesn't crash and no errors.
>
> Why can't I get glxgears to run without  (vglrun glxgears).  Is it not
> compatible with NVIDIA's OpenGL libraries?
>
> Thanks.
>
> Josh
>
>
>
>
> On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jd...@nc...> wrote:
>
>> Hello,
>>
>> I am using Windows Remote Desktop to connect to a CentOS7.2 box with a
>> NVIDIA GeForce GT 720 graphics card.  I also have a NVIDIA Tesla K40c on it
>> as well.
>>
>> I am using TigerVNC and XRDP and then launching workbench with
>>
>> vglrun runwb2
>>
>> Everything seems to work ok, except when I try to open "System Coupling".
>>
>> Then I get
>>
>> [VGL] ERROR: in init--
>> [VGL] 218: Invalid argument
>> Exception caught in virtual Ans::Graphics::Scene::EventProcessor::~EventProcessor()
>> @line176
>>
>> Then Workbench closes immediately with no other error message
>>
>> I am very new to using VNC, and Remote Desktop to access Linux, as well
>> as even newer to OpenGL and VirtualGL.
>>
>> Does anyone know what is going on?  Or if someone else is using ANSYS and
>> can duplicate this error?
>>
>> I have ANSYS on another machine running CentOS7.2.  It does not have a
>> NVIDIA graphics card.  Actually I'm not even sure what kind of graphics
>> card it is running, but it definitely isn't a good one.  It runs just
>> fine.  I can open ANSYS without VirtualGL just with runwb2 and can open
>> System Coupling and it seems to run just fine.  I do get error in the
>> WorkbenchLog files which state that I don't have hardware acceleration.
>>
>> Thanks.
>>
>> Josh
>>
>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>

Re: [VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[DRC <dco...@us...>]

vglrun loads VirtualGL into a particular application.  This is necessary
to make OpenGL applications run properly and with hardware acceleration
in a Un*x remote display environment.  I don't have any familiarity with
xrdp, but I do know that TigerVNC has a built-in software OpenGL
implementation.  Thus, running glxgears within TigerVNC should work
without VirtualGL, although it will not be hardware-accelerated.  If you
aren't able to run glxgears in TigerVNC without VGL, then that is a
TigerVNC bug.  If you can run glxgears within TigerVNC but not TigerVNC
+ XRDP, then that is an XRDP bug.


On 9/17/16 11:39 PM, Joshua Moore wrote:
> I think I figured it out finally.
> 
> I only can get it to work using 
> 
> vglrun runwb2
> 
> Previously I had LD_LIBRARY_PATH to include
> /ansys_inc/v172/Framework/bin/Linux64/Mesa.  I think that was overriding
> some of the NVIDIA drivers or something.  
> 
> Now it runs and doesn't crash and no errors.
> 
> Why can't I get glxgears to run without  (vglrun glxgears).  Is it not
> compatible with NVIDIA's OpenGL libraries?
> 
> Thanks.
> 
> Josh
> 
> 
> 
> 
> On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jd...@nc...
> <mailto:jd...@nc...>> wrote:
> 
>     Hello,
> 
>     I am using Windows Remote Desktop to connect to a CentOS7.2 box with
>     a NVIDIA GeForce GT 720 graphics card.  I also have a NVIDIA Tesla
>     K40c on it as well.
> 
>     I am using TigerVNC and XRDP and then launching workbench with 
> 
>     vglrun runwb2
> 
>     Everything seems to work ok, except when I try to open "System
>     Coupling".
> 
>     Then I get
> 
>     [VGL] ERROR: in init--
>     [VGL] 218: Invalid argument
>     Exception caught in virtual
>     Ans::Graphics::Scene::EventProcessor::~EventProcessor() @line176
> 
>     Then Workbench closes immediately with no other error message
> 
>     I am very new to using VNC, and Remote Desktop to access Linux, as
>     well as even newer to OpenGL and VirtualGL.  
> 
>     Does anyone know what is going on?  Or if someone else is using
>     ANSYS and can duplicate this error?
> 
>     I have ANSYS on another machine running CentOS7.2.  It does not have
>     a NVIDIA graphics card.  Actually I'm not even sure what kind of
>     graphics card it is running, but it definitely isn't a good one.  It
>     runs just fine.  I can open ANSYS without VirtualGL just with runwb2
>     and can open System Coupling and it seems to run just fine.  I do
>     get error in the WorkbenchLog files which state that I don't have
>     hardware acceleration.
> 
>     Thanks.
> 
>     Josh
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
> 

Re: [VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[Joshua M. <jd...@nc...>]

I think I figured it out finally.

I only can get it to work using

vglrun runwb2

Previously I had LD_LIBRARY_PATH to include
/ansys_inc/v172/Framework/bin/Linux64/Mesa.  I think that was overriding
some of the NVIDIA drivers or something.

Now it runs and doesn't crash and no errors.

Why can't I get glxgears to run without  (vglrun glxgears).  Is it not
compatible with NVIDIA's OpenGL libraries?

Thanks.

Josh




On Sat, Sep 17, 2016 at 11:56 PM, Joshua Moore <jd...@nc...> wrote:

> Hello,
>
> I am using Windows Remote Desktop to connect to a CentOS7.2 box with a
> NVIDIA GeForce GT 720 graphics card.  I also have a NVIDIA Tesla K40c on it
> as well.
>
> I am using TigerVNC and XRDP and then launching workbench with
>
> vglrun runwb2
>
> Everything seems to work ok, except when I try to open "System Coupling".
>
> Then I get
>
> [VGL] ERROR: in init--
> [VGL] 218: Invalid argument
> Exception caught in virtual Ans::Graphics::Scene::EventProcessor::~EventProcessor()
> @line176
>
> Then Workbench closes immediately with no other error message
>
> I am very new to using VNC, and Remote Desktop to access Linux, as well as
> even newer to OpenGL and VirtualGL.
>
> Does anyone know what is going on?  Or if someone else is using ANSYS and
> can duplicate this error?
>
> I have ANSYS on another machine running CentOS7.2.  It does not have a
> NVIDIA graphics card.  Actually I'm not even sure what kind of graphics
> card it is running, but it definitely isn't a good one.  It runs just
> fine.  I can open ANSYS without VirtualGL just with runwb2 and can open
> System Coupling and it seems to run just fine.  I do get error in the
> WorkbenchLog files which state that I don't have hardware acceleration.
>
> Thanks.
>
> Josh
>

[VirtualGL-Users] TigerVNC + XRDP + VirtualGL with ANSYS

[Joshua M. <jd...@nc...>]

Hello,

I am using Windows Remote Desktop to connect to a CentOS7.2 box with a
NVIDIA GeForce GT 720 graphics card.  I also have a NVIDIA Tesla K40c on it
as well.

I am using TigerVNC and XRDP and then launching workbench with

vglrun runwb2

Everything seems to work ok, except when I try to open "System Coupling".

Then I get

[VGL] ERROR: in init--
[VGL] 218: Invalid argument
Exception caught in virtual
Ans::Graphics::Scene::EventProcessor::~EventProcessor() @line176

Then Workbench closes immediately with no other error message

I am very new to using VNC, and Remote Desktop to access Linux, as well as
even newer to OpenGL and VirtualGL.

Does anyone know what is going on?  Or if someone else is using ANSYS and
can duplicate this error?

I have ANSYS on another machine running CentOS7.2.  It does not have a
NVIDIA graphics card.  Actually I'm not even sure what kind of graphics
card it is running, but it definitely isn't a good one.  It runs just
fine.  I can open ANSYS without VirtualGL just with runwb2 and can open
System Coupling and it seems to run just fine.  I do get error in the
WorkbenchLog files which state that I don't have hardware acceleration.

Thanks.

Josh

[VirtualGL-Users] Sometimes garbled output

[Carsten R. <car...@ma...>]

Dear all

I'm new to virtualGL and try to use it in a Cendio/Thinlinc environment. 
The first tests (VirtualGL 2.5) have been _quite_ impressive by using 
Gnome3 or Compiz/Unity (Ubuntu 16.04, thinlinc 4.6). Thanks a lot for 
this superb software - in fact, I couldn't believe that there exist a 
free solution for sharing GPU(s) among several desktop sessions. Fantastic.

For our test, we use a NVIDIA Corporation GT218 [GeForce 210]. We 
installed two of them, but are using only one at the moment.

After a few days some desktop sessions starts to show garbled desktops, 
typically for less than a second. 'garbled' means a lot of pixel (not 
all) are wrong.
Moving the mouse or a window fixes the broken display - but only until 
it happens again (sometimes after 10 seconds, sometimes after hours). 
This appears neither regular nor in every desktop session (one of three 
daily users never saw this effect). Killing the session and re-login 
doesn't change anything.
We see no error messages indicating a problem.
The nvidia monitoring shows:

$ nvidia-smi
Thu Sep 15 20:39:59 2016
+------------------------------------------------------+ 

| NVIDIA-SMI 340.96     Driver Version: 340.96         | 

|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile 
Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util 
Compute M. |
|===============================+======================+======================|
|   0  GeForce 210         Off  | 0000:81:00.0     N/A | 
  N/A |
| N/A   36C    P8    N/A /  N/A |    935MiB /  1023MiB |     N/A 
Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce 210         Off  | 0000:82:00.0     N/A | 
  N/A |
| N/A   35C    P8    N/A /  N/A |      2MiB /  1023MiB |     N/A 
Default |
+-------------------------------+----------------------+----------------------+
 

+-----------------------------------------------------------------------------+
| Compute processes:                                               GPU 
Memory |
|  GPU       PID  Process name                                     Usage 
      |
|=============================================================================|
|    0            Not Supported 
      |
|    1            Not Supported 
      |
+-----------------------------------------------------------------------------+


Any ideas or hints about the reason or how to do more investigation?

Thanks a lot for your time.

CU
Carsten

-- 
Carsten Rose
IT Koordinator / Institut für Mathematik

*****
Universität Zürich
Carsten Rose
Institut für Mathematik, Y27-J40
Winterthurerstrasse 190
CH-8057 Zürich

+41 44 635 58 47 Telefon
+41 44 635 57 05 Telefax

www.math.uzh.ch
car...@ma...

"Wenn ein unordentlicher Schreibtisch einen unordentlichen Geist 
repräsentiert, was sagt dann ein leerer Schreibtisch über den Menschen, 
der ihn benutzt aus?" - Albert Einstein

Re: [VirtualGL-Users] Fwd: Included CMake File Does Not Build on Debian 8.6

[DRC <dco...@us...>]

Sorry for the curt response. I'm away from my computer at the moment and am typing on my phone. To clarify, if you just want to build the TurboVNC server without the Java viewer, then you would do:

cmake -G"Unix Makefiles" -DTVNC_BUILDJAVA=0 -DTVNC_BUILDNATIVE=0 ..

Or if you have OpenJDK installed and want to build the viewer as well, just leave off the -D options. VirtualGL is built similarly. Be mindful of the fact that VirtualGL is an interposer library, so it won't resolve all symbols at link time (by design.) Distributors will occasionally send me questions about that.

> On Sep 9, 2016, at 10:41 PM, Brian Chrzanowski <chr...@ke...> wrote:
> 
> Hello VirtualGL mailing list,
> 
> I'm attempting to build the virtualGL server & also TurboVNC from source, and
> create Debian packages to distribute to many machines. I've not only compiled
> and installed libjpeg-turbo from source and installed it, but just to make
> sure that I'm using the most recently built version of the source, I cloned
> from the git repo suggested on the website.
> 
> While running the suggested cmake line:
> 
>     cmake -G "Unix Makefiles" ../unix # in the 'build' dir I created
> 
> I recieve the following output:
> 
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:48 (string):
>       string no output variable specified
> 
> 
>     -- Compiler flags =  
>     -- Linker flags =   
>     CMake Warning (dev) in CMakeLists.txt:
>       No cmake_minimum_required command is present.  A line of code such as
> 
>         cmake_minimum_required(VERSION 3.0)
> 
>       should be added at the top of the file.  The version specified may be lower
>       if you wish to support older CMake versions for this project.  For more
>       information run "cmake --help-policy CMP0000".
>     This warning is for project developers.  Use -Wno-dev to suppress it.
> 
>     -- Configuring incomplete, errors occurred!
>     See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> 
> 
> Even though I can go and add the line it suggests at the top of the 
> 'CMakeLists.txt', cmake still doesn't complete, as I then recieve this output:
> 
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:49 (string):
>       string no output variable specified
> 
> 
>     -- Compiler flags =  
>     -- Linker flags =   
>     -- Configuring incomplete, errors occurred!
>     See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> 
> I've tried to look at the logs, but I can't figure it out for the life of me.
> If anyone's got a second to figure it out, let me know what I can do to help
> fix it if necessary.
> 
> Thanks,
> Brian Chrzanowski
> 
> <CMakeOutput.log>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] Fwd: Included CMake File Does Not Build on Debian 8.6

[DRC <dco...@us...>]

Please read the build instructions. You should not use unix/ as the CMake target directory.

> On Sep 9, 2016, at 10:41 PM, Brian Chrzanowski <chr...@ke...> wrote:
> 
> Hello VirtualGL mailing list,
> 
> I'm attempting to build the virtualGL server & also TurboVNC from source, and
> create Debian packages to distribute to many machines. I've not only compiled
> and installed libjpeg-turbo from source and installed it, but just to make
> sure that I'm using the most recently built version of the source, I cloned
> from the git repo suggested on the website.
> 
> While running the suggested cmake line:
> 
>     cmake -G "Unix Makefiles" ../unix # in the 'build' dir I created
> 
> I recieve the following output:
> 
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:48 (string):
>       string no output variable specified
> 
> 
>     -- Compiler flags =  
>     -- Linker flags =   
>     CMake Warning (dev) in CMakeLists.txt:
>       No cmake_minimum_required command is present.  A line of code such as
> 
>         cmake_minimum_required(VERSION 3.0)
> 
>       should be added at the top of the file.  The version specified may be lower
>       if you wish to support older CMake versions for this project.  For more
>       information run "cmake --help-policy CMP0000".
>     This warning is for project developers.  Use -Wno-dev to suppress it.
> 
>     -- Configuring incomplete, errors occurred!
>     See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> 
> 
> Even though I can go and add the line it suggests at the top of the 
> 'CMakeLists.txt', cmake still doesn't complete, as I then recieve this output:
> 
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:49 (string):
>       string no output variable specified
> 
> 
>     -- Compiler flags =  
>     -- Linker flags =   
>     -- Configuring incomplete, errors occurred!
>     See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> 
> I've tried to look at the logs, but I can't figure it out for the life of me.
> If anyone's got a second to figure it out, let me know what I can do to help
> fix it if necessary.
> 
> Thanks,
> Brian Chrzanowski
> 
> <CMakeOutput.log>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] Fwd: Included CMake File Does Not Build on Debian 8.6

[Michael M. <mi...@ma...>]

Hi Brian,

If I look at

https://github.com/TurboVNC/turbovnc/blob/master/unix/CMakeLists.txt

then I can see in line 48 (your line 49 after you added the 
cmake_minimum_required(VERSION 3.0) thing)

string(TOUPPER${CMAKE_BUILD_TYPE}CMAKE_BUILD_TYPE_UC)

So my suspicion is that either CMAKE_BUILD_TYPE or CMAKE_BUILD_TYPE_UC 
is not defined, i.e. an empty string

I would add two lines before line 49 like

message(DEBUG "CMAKE_BUILD_TYPE = ${CMAKE_BUILD_TYPE}") message(DEBUG 
"CMAKE_BUILD_TYPE_UC = ${CMAKE_BUILD_TYPE_UC}") and see what they tell 
you when you rerun the build process. Depending on which is empty you 
then can search where this variable should be set etc... and eventually 
it should work. Hope this helps, Michael. On 10/09/16 05:41, Brian 
Chrzanowski wrote:
> Hello VirtualGL mailing list,
> I'm attempting to build the virtualGL server & also TurboVNC from 
> source, and
> create Debian packages to distribute to many machines. I've not only 
> compiled
> and installed libjpeg-turbo from source and installed it, but just to make
> sure that I'm using the most recently built version of the source, I 
> cloned
> from the git repo suggested on the website.
> While running the suggested cmake line:
>     cmake -G "Unix Makefiles" ../unix # in the 'build' dir I created
> I recieve the following output:
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:48 (string):
>       string no output variable specified
>     -- Compiler flags =
>     -- Linker flags =
>     CMake Warning (dev) in CMakeLists.txt:
>       No cmake_minimum_required command is present.  A line of code 
> such as
>         cmake_minimum_required(VERSION 3.0)
>       should be added at the top of the file.  The version specified 
> may be lower
>       if you wish to support older CMake versions for this project.  
> For more
>       information run "cmake --help-policy CMP0000".
>     This warning is for project developers.  Use -Wno-dev to suppress it.
>     -- Configuring incomplete, errors occurred!
>     See also 
> "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> Even though I can go and add the line it suggests at the top of the
> 'CMakeLists.txt', cmake still doesn't complete, as I then recieve this 
> output:
>     -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
>     -- TVNC_MANDIR = /usr/local/man
>     CMake Error at CMakeLists.txt:49 (string):
>       string no output variable specified
>     -- Compiler flags =
>     -- Linker flags =
>     -- Configuring incomplete, errors occurred!
>     See also 
> "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".
> I've tried to look at the logs, but I can't figure it out for the life 
> of me.
> If anyone's got a second to figure it out, let me know what I can do 
> to help
> fix it if necessary.
> Thanks,
> Brian Chrzanowski
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

[VirtualGL-Users] Fwd: Included CMake File Does Not Build on Debian 8.6

[Brian C. <chr...@ke...>]

Hello VirtualGL mailing list,

I'm attempting to build the virtualGL server & also TurboVNC from source,
and
create Debian packages to distribute to many machines. I've not only
compiled
and installed libjpeg-turbo from source and installed it, but just to make
sure that I'm using the most recently built version of the source, I cloned
from the git repo suggested on the website.

While running the suggested cmake line:

    cmake -G "Unix Makefiles" ../unix # in the 'build' dir I created

I recieve the following output:

    -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
    -- TVNC_MANDIR = /usr/local/man
    CMake Error at CMakeLists.txt:48 (string):
      string no output variable specified


    -- Compiler flags =
    -- Linker flags =
    CMake Warning (dev) in CMakeLists.txt:
      No cmake_minimum_required command is present.  A line of code such as

        cmake_minimum_required(VERSION 3.0)

      should be added at the top of the file.  The version specified may be
lower
      if you wish to support older CMake versions for this project.  For
more
      information run "cmake --help-policy CMP0000".
    This warning is for project developers.  Use -Wno-dev to suppress it.

    -- Configuring incomplete, errors occurred!
    See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".


Even though I can go and add the line it suggests at the top of the
'CMakeLists.txt', cmake still doesn't complete, as I then recieve this
output:

    -- X11_X11_LIB = /usr/lib/x86_64-linux-gnu/libX11.so
    -- TVNC_MANDIR = /usr/local/man
    CMake Error at CMakeLists.txt:49 (string):
      string no output variable specified


    -- Compiler flags =
    -- Linker flags =
    -- Configuring incomplete, errors occurred!
    See also "/home/brian/tools/turbovnc/build/CMakeFiles/CMakeOutput.log".

I've tried to look at the logs, but I can't figure it out for the life of
me.
If anyone's got a second to figure it out, let me know what I can do to help
fix it if necessary.

Thanks,
Brian Chrzanowski

Re: [VirtualGL-Users] TOTP in TurboVNC

[DRC <dco...@us...>]

I was able to get TOTP working successfully in TurboVNC using pam_oath
on CentOS 6 & 7, Fedora, and Ubuntu, using Google Authenticator on my
phone.  The strawman procedure is here:

http://www.turbovnc.org/Documentation/TOTP

Please try it out and let me know what breaks, or if anything is unclear
in the procedure, or if it doesn't meet your needs for some reason.

AFAICT, there isn't really a cleaner or more secure way of doing this
from within TurboVNC.  x11vnc is fundamentally a single-user
application, whereas TurboVNC is multi-user, so in order to do what
x11vnc is doing, I would have to implement the following in Xvnc:

-- A mechanism for specifying a server-side authentication command to
use with Unix Login/Plain authentication.  For security reasons, this
command would have to be specified in the TurboVNC security
configuration file.

-- Some method of passing the user's secret key to this command.  One
possible method would be to have Xvnc read an environment variable with
the key, or to store it under ~/.vnc, and insert this key into the
aforementioned authentication command spec.  Another possible method
would be to use a global file that contains all of the users' secret
keys, which is very similar to how the OATH PAM module does it.

-- A new server-side authentication method that uses the aforementioned
authentication command instead of PAM to authenticate user/password pairs.

All of this would require significant effort and would significantly
increase the complexity of TurboVNC, and AFAICT, it would provide no
advantages relative to the OATH PAM module.


On 7/25/16 9:02 AM, Mathieu Pasquet wrote:
> 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 <dco...@us...>:
>>
>> 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 <mat...@al...> 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

Re: [VirtualGL-Users] VirtualGL, docker and different X server issues

[DRC <dco...@us...>]

OK, it sounds like I need to tinker with TOTP. Seems like it should be straightforward to add support for that.

As far as compression, if you're transmitting the pixels within the same physical machine, then no, there is nothing to gain from it. Leave it uncompressed.

> On Jul 25, 2016, at 8:02 AM, Mathieu Pasquet <mat...@al...> wrote:
> 
> 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 <dco...@us...>:
>> 
>> 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 <mat...@al...> 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
>>> Vir...@li...
>>> 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
>> Vir...@li...
>> 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
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] VirtualGL, docker and different X server issues

[Mathieu P. <mat...@al...>]

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 <dco...@us...>:
>
> 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 <mat...@al...> 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
> > Vir...@li...
> > 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
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users




-- 

Mathieu Pasquet
R&D engineer
alter way

Re: [VirtualGL-Users] VirtualGL, docker and different X server issues

[DRC <dco...@us...>]

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 <mat...@al...> 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
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

[VirtualGL-Users] VirtualGL, docker and different X server issues

[Mathieu P. <mat...@al...>]

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

[VirtualGL-Users] Support for OpenCL on Linux?

[Jeff M. <jjm...@al...>]

Can one use OpenCL when running under VirtualGL?

I noticed that clinfo segfaults if I invoke it with:

"vglrun clinfo"

I'm using the latest VirtualGL 2.5, CentOS 6.7 64-bit, AMD FirePro W8000 graphics.

Core was generated by `clinfo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6e9fd77fcd in ?? () from /opt/intel/opencl-1.2-4.4.0.117/lib64/libintelocl.so
Missing separate debuginfos, use: debuginfo-install VirtualGL-2.5-20160215.x86_64 glibc-2.12-1.166.el6_7.7.x86_64 libX11-1.6.0-6.el6.x86_64 libXau-1.0.6-4.el6.x86_64 libXext-1.3.2-2.1.el6.x86_64 libXv-1.0.9-2.1.el6.x86_64 libgcc-4.4.7-16.el6.x86_64 libstdc++-4.4.7-16.el6.x86_64 libxcb-1.9.1-3.el6.x86_64 mesa-libGL-10.4.3-1.el6.x86_64 numactl-2.0.9-2.el6.x86_64 opencl-1.2-intel-cpu-4.4.0.117-1.x86_64
(gdb) bt
#0  0x00007f6e9fd77fcd in ?? () from /opt/intel/opencl-1.2-4.4.0.117/lib64/libintelocl.so
#1  0x00007f6e9fcf1e81 in clGetPlatformInfo () from /opt/intel/opencl-1.2-4.4.0.117/lib64/libintelocl.so
#2  0x000000000040e8be in int cl::detail::getInfoHelper<cl::detail::GetInfoFunctor0<int (*)(_cl_platform_id*, unsigned int, unsigned long, void*, unsigned long*), _cl_platform_id*> >(cl::detail::GetInfoFunctor0<int (*)(_cl_platform_id*, unsigned int, unsigned long, void*, unsigned long*), _cl_platform_id*>, unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, long) [clone .isra.35] [clone .constprop.213] ()
#3  0x000000000040fd57 in cl::detail::param_traits<cl::detail::cl_platform_info, 2308>::param_type cl::Platform::getInfo<2308>(int*) const ()
#4  0x0000000000407fc3 in main ()


If I rename /etc/OpenCL/vendors/intel64.icd I can then run "vglrun clinfo", and it does not crash.  I get a list indicating AMD APP is the provider, with one CPU device.   The GPU device is not listed.  If I run clinfo without using vglrun, the AMD APP provider lists both a CPU device and a GPU device.



Thanks,

Jeff McWilliams
Software Development Manager - Altair HyperView

Re: [VirtualGL-Users] VirtualGL with VirtualBox

[Vladimir S. <vsa...@gm...>]

Forwarding port 4242 from the host to the VM resolved the issue.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: DRC
Sent: Monday, June 6, 2016 1:05 PM
To: vir...@li...
Reply To: VirtualGL Users
Subject: Re: [VirtualGL-Users] VirtualGL with VirtualBox

VGLclient uses port 4242 primarily, unless you've built it with SSL
support (in which case it also uses 4243 for encrypted connections.) It
will use other ports only if there are multiple instances of it running
on the same client machine, which is not normally the case.

On 6/6/16 11:50 AM, Vladimir Santalov wrote:
> Mode: vgl transport
> Client: Ubuntu 14.04 on virtualbox on Windows 7 host
> Server: CentOs 7 on a remote network.
> ‎VirtualGL client on Ubuntu only works if VirtualBox is configured in a bridged adapter mode and is on the same network as the server. When on a remote network Windows 7 host relies on VPN. VirtualBox cannot see the VPN in a bridged adapter mode. In NAT mode the connection is first established with the host IP and the VM connection doesn't happen. It appears I need to forward some ports from host to VM but I don't know which ones.
> 
> Sent from my BlackBerry 10 smartphone.
> Original Message 
> From: DRC
> Sent: Monday, June 6, 2016 11:12 AM
> To: vir...@li...
> Reply To: VirtualGL Users
> Subject: Re: [VirtualGL-Users] VirtualGL with VirtualBox
> 
> On 6/6/16 10:17 AM, Vladimir Santalov wrote:
>> I'm looking for a way to set up port forwarding for VirtualBox NAT to
>> work with VirtualGL. Bridged connection is not an option since I need to
>> retain connection to the host's VPN. Which ports do I need to forward
>> from the host to the vm to make VirtualGL work on the vm?
> 
> Impossible to answer without further details of what you're trying to
> achieve. I'd need to know which mode of VirtualGL you are attempting to
> use (VGL Transport? X Proxy? If you're using an X proxy, which one?)
> I'd need to know which machine (virtual or otherwise) is acting as the
> client and which is acting as the server. I am failing to understand
> why you would need to forward ports at all.

------------------------------------------------------------------------------
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
VirtualGL-Users mailing list
Vir...@li...
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] VirtualGL with VirtualBox

[DRC <dco...@us...>]

VGLclient uses port 4242 primarily, unless you've built it with SSL
support (in which case it also uses 4243 for encrypted connections.)  It
will use other ports only if there are multiple instances of it running
on the same client machine, which is not normally the case.

On 6/6/16 11:50 AM, Vladimir Santalov wrote:
> Mode: vgl transport
> Client: Ubuntu 14.04 on virtualbox on Windows 7 host
> Server: CentOs 7 on a remote network.
> ‎VirtualGL client on Ubuntu only works if VirtualBox is configured in a bridged adapter mode and is on the same network as the server. When on a remote network Windows 7 host relies on VPN. VirtualBox cannot see the VPN in a bridged adapter mode. In NAT mode the connection is first established with the host IP and the VM connection doesn't happen. It appears I need to forward some ports from host to VM but I don't know which ones.
> 
> Sent from my BlackBerry 10 smartphone.
>   Original Message  
> From: DRC
> Sent: Monday, June 6, 2016 11:12 AM
> To: vir...@li...
> Reply To: VirtualGL Users
> Subject: Re: [VirtualGL-Users] VirtualGL with VirtualBox
> 
> On 6/6/16 10:17 AM, Vladimir Santalov wrote:
>> I'm looking for a way to set up port forwarding for VirtualBox NAT to
>> work with VirtualGL. Bridged connection is not an option since I need to
>> retain connection to the host's VPN. Which ports do I need to forward
>> from the host to the vm to make VirtualGL work on the vm?
> 
> Impossible to answer without further details of what you're trying to
> achieve. I'd need to know which mode of VirtualGL you are attempting to
> use (VGL Transport? X Proxy? If you're using an X proxy, which one?)
> I'd need to know which machine (virtual or otherwise) is acting as the
> client and which is acting as the server. I am failing to understand
> why you would need to forward ports at all.

Re: [VirtualGL-Users] VirtualGL with VirtualBox

[Vladimir S. <vsa...@gm...>]

Mode: vgl transport
Client: Ubuntu 14.04 on virtualbox on Windows 7 host
Server: CentOs 7 on a remote network.
‎VirtualGL client on Ubuntu only works if VirtualBox is configured in a bridged adapter mode and is on the same network as the server. When on a remote network Windows 7 host relies on VPN. VirtualBox cannot see the VPN in a bridged adapter mode. In NAT mode the connection is first established with the host IP and the VM connection doesn't happen. It appears I need to forward some ports from host to VM but I don't know which ones.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: DRC
Sent: Monday, June 6, 2016 11:12 AM
To: vir...@li...
Reply To: VirtualGL Users
Subject: Re: [VirtualGL-Users] VirtualGL with VirtualBox

On 6/6/16 10:17 AM, Vladimir Santalov wrote:
> I'm looking for a way to set up port forwarding for VirtualBox NAT to
> work with VirtualGL. Bridged connection is not an option since I need to
> retain connection to the host's VPN. Which ports do I need to forward
> from the host to the vm to make VirtualGL work on the vm?

Impossible to answer without further details of what you're trying to
achieve. I'd need to know which mode of VirtualGL you are attempting to
use (VGL Transport? X Proxy? If you're using an X proxy, which one?)
I'd need to know which machine (virtual or otherwise) is acting as the
client and which is acting as the server. I am failing to understand
why you would need to forward ports at all.

------------------------------------------------------------------------------
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
VirtualGL-Users mailing list
Vir...@li...
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] VirtualGL with VirtualBox

[DRC <dco...@us...>]

On 6/6/16 10:17 AM, Vladimir Santalov wrote:
> I'm looking for a way to set up port forwarding for VirtualBox NAT to
> work with VirtualGL. Bridged connection is not an option since I need to
> retain connection to the host's VPN. Which ports do I need to forward
> from the host to the vm to make VirtualGL work on the vm?

Impossible to answer without further details of what you're trying to
achieve.  I'd need to know which mode of VirtualGL you are attempting to
use (VGL Transport?  X Proxy?  If you're using an X proxy, which one?)
I'd need to know which machine (virtual or otherwise) is acting as the
client and which is acting as the server.  I am failing to understand
why you would need to forward ports at all.

[VirtualGL-Users] VirtualGL with VirtualBox

[Vladimir S. <vsa...@gm...>]

I'm looking for a way to set up port forwarding for VirtualBox NAT to work
with VirtualGL. Bridged connection is not an option since I need to retain
connection to the host's VPN. Which ports do I need to forward from the
host to the vm to make VirtualGL work on the vm?

Re: [VirtualGL-Users] Errors in FreeBSD.

[DRC <dco...@us...>]

On 4/11/16 2:38 PM, Thomas Gebert wrote:
> Hello All!  
> When I try running glxgears with `vglrun` (installed by ports in
> FreeBSD), I get this error: 
> 
> ```
> [tom@treter /]$ DISPLAY=:11.0 vglrun glxgears
> [VGL] ERROR: in fconfig_instance--
> [VGL]    97: Function not implemented
> ```
> 
> Any idea why this might be happening? 

That error is caused by the shmget() call failing with ENOSYS ("Function
not implemented" is the POSIX error string for ENOSYS.)  I would suggest
googling for reasons why shmget() might fail with that error code on
FreeBSD systems, as I've never seen this before on my system (but I'm
also running FreeBSD 8.4, not the latest version.)  The exact call we're
making in the VGL source is:

	fconfig_shmid=shmget(IPC_PRIVATE, sizeof(FakerConfig),
IPC_CREAT|0600))==-1)

so the error should be easy to reproduce in an isolated program.

[VirtualGL-Users] Errors in FreeBSD.

[Thomas G. <th...@ge...>]

Hello All!  
When I try running glxgears with `vglrun` (installed by ports in
FreeBSD), I get this error: 

```
[tom@treter /]$ DISPLAY=:11.0 vglrun glxgears
[VGL] ERROR: in fconfig_instance--
[VGL]    97: Function not implemented
```

Any idea why this might be happening?