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

[VirtualGL-Users] VirtualGL and TurboVNC mailing lists have moved to Google Groups

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

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw.  Given that there
is some cross-pollination between our projects and TigerVNC, and
TigerVNC is using Google Groups, I decided to do likewise with both
VirtualGL and TurboVNC.  You can join the new groups either using a
Google account (which gives you full access to the group from the web
interface) or a non-Google e-mail address (which gives you access to
post from e-mail only.)  Links for joining all of the groups can be
found here:

http://www.virtualgl.org/About/MailingLists
http://www.turbovnc.org/About/MailingLists

(Note that you have to be logged in with a Google account in order to
join with that account.)

To unsubscribe from the old lists, visit one or more of the following URLs:
https://sourceforge.net/projects/virtualgl/lists/virtualgl-announce/unsubscribe
https://sourceforge.net/projects/virtualgl/lists/virtualgl-users/unsubscribe
https://sourceforge.net/projects/virtualgl/lists/virtualgl-devel/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-announce/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-users/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-devel/unsubscribe

The direct addresses for e-mailing the new groups are:
vir...@go...
vir...@go...
tur...@go...
tur...@go...

Other notes:
-- If you join with a non-Google e-mail address, Google makes you go
through a really annoying Turing test.  I apologize in advance for that.
-- The old mailing lists will be retained on SourceForge for archival
purposes, but they are no longer linked from our SourceForge project
pages.  To view the archives, visit the links on VirtualGL.org and
TurboVNC.org (see above.)
-- The new mailing lists have already been added to mail-archive.com.
-- The new lists are public (anyone can join or view the messages), but
the subscriber lists are visible only to me.
-- As with the existing lists, only members can post (and only I can
post to the announcement lists.)
-- The new lists are configured such that your Google profile will not
be revealed if you post.  Only your chosen display name will be shown.

Reminders:
-- If a topic is specific to TurboVNC and does not necessarily involve
VirtualGL, then please use one of the TurboVNC lists to discuss that topic.
-- We also have a Facebook group (https://www.facebook.com/VirtualGL)
and a LinkedIn group (https://www.linkedin.com/groups/3182945) that
receive release announcements.  You can also use those groups to post
questions and concerns.

Please e-mail me directly (http://www.virtualgl.org/About/Contact) or
post a GitHub tracker issue
(https://github.com/VirtualGL/virtualgl/issues/new or
https://github.com/TurboVNC/turbovnc/issues/new) should you have any
questions, concerns, or problems subscribing to the new lists.

The old lists will be closed to new messages shortly, so please transfer
your subscriptions immediately.

DRC

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

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

Display :0 doesn't have a GLX extension for some reason.  Did you
install the nVidia proprietary drivers?  If so, then there is something
wrong with your X.org configuration.  Make sure you can properly run
OpenGL applications on Display :0 without VirtualGL, and then VirtualGL
should work now that you have fixed the DM problem.

On 8/2/17 1:26 PM, sta...@ms... wrote:
> Hi All,
> I have changed my display manager from MDM to lightDM. It was a little
> buggy to get it going but it is now finally operational and seems to be
> working appropriately.
> Doing the "sanity check" tests results in this:
> marshall@computer ~ $ xauth merge /etc/opt/VirtualGL/vgl_xauth_key
> marshall@computer ~ $ xdpyinfo -display :0
> name of display:    :0
> version number:    11.0
> vendor string:    The X.Org Foundation
> vendor release number:    11804000
> X.Org version: 1.18.4
> maximum request size:  16777212 bytes
> motion buffer size:  256
> bitmap unit, bit order, padding:    32, LSBFirst, 32
> image byte order:    LSBFirst
> number of supported pixmap formats:    7
> supported pixmap formats:
>     depth 1, bits_per_pixel 1, scanline_pad 32
>     depth 4, bits_per_pixel 8, scanline_pad 32
>     depth 8, bits_per_pixel 8, scanline_pad 32
>     depth 15, bits_per_pixel 16, scanline_pad 32
>     depth 16, bits_per_pixel 16, scanline_pad 32
>     depth 24, bits_per_pixel 32, scanline_pad 32
>     depth 32, bits_per_pixel 32, scanline_pad 32
> keycode range:    minimum 8, maximum 255
> focus:  PointerRoot
> number of extensions:    26
>     BIG-REQUESTS
>     Composite
>     DAMAGE
>     DOUBLE-BUFFER
>     DPMS
>     DRI2
>     Generic Event Extension
>     MIT-SCREEN-SAVER
>     MIT-SHM
>     Present
>     RANDR
>     RECORD
>     RENDER
>     SECURITY
>     SHAPE
>     SYNC
>     X-Resource
>     XC-MISC
>     XFIXES
>     XFree86-DGA
>     XFree86-VidModeExtension
>     XINERAMA
>     XInputExtension
>     XKEYBOARD
>     XTEST
>     XVideo
> default screen number:    0
> number of screens:    1
> 
> screen #0:
>   dimensions:    640x480 pixels (169x127 millimeters)
>   resolution:    96x96 dots per inch
>   depths (7):    24, 1, 4, 8, 15, 16, 32
>   root window id:    0x43
>   depth of root window:    24 planes
>   number of colormaps:    minimum 1, maximum 1
>   default colormap:    0x20
>   default number of colormap cells:    256
>   preallocated pixels:    black 0, white 16777215
>   options:    backing-store WHEN MAPPED, save-unders NO
>   largest cursor:    640x480
>   current input event mask:    0x420003
>     KeyPressMask             KeyReleaseMask           StructureNotifyMask
>     PropertyChangeMask
>   number of visuals:    2
>   default visual id:  0x21
>   visual:
>     visual id:    0x21
>     class:    TrueColor
>     depth:    24 planes
>     available colormap entries:    256 per subfield
>     red, green, blue masks:    0xff0000, 0xff00, 0xff
>     significant bits in color specification:    8 bits
>   visual:
>     visual id:    0x41
>     class:    TrueColor
>     depth:    32 planes
>     available colormap entries:    256 per subfield
>     red, green, blue masks:    0xff0000, 0xff00, 0xff
>     significant bits in color specification:    8 bits
> marshall@computer ~ $ /opt/VirtualGL/bin/glxinfo -display :0 -c
> name of display: :0
> Error: couldn't find RGB GLX visual or fbconfig
> Error: couldn't find RGB GLX visual or fbconfig
> 
> Thank you again for all the advice.
> 
> Marshall Stageberg
> Michigan State University
> 
> Quoting DRC via VirtualGL-Users <vir...@li...>:
> 
>> If LightDM is available under Linux Mint (I can't recall whether it is
>> or not), that would be the next thing to try.
>>
>> On 8/1/17 7:13 PM, DRC wrote:
>>> Ugh.  Unfortunately I think you're running into the aforementioned GDM
>>> bug, then.  Even more unfortunately, I just re-tested it with Fedora 26,
>>> and it's still there, so I'm sure it hasn't been fixed upstream yet.
>>> Does anyone fix bugs anymore?!  Maybe I'm expecting too much for GDM to
>>> load its own farking init script.
>>>
>>>
>>> On 8/1/17 1:07 PM, sta...@ms... wrote:
>>>> Thank you for your quick reply,
>>>> I can at least provide more information regarding some of the short
>>>> testing you had said to do.
>>>> When using the command: xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>>> It returns back nothing.
>>>> When using the command: xdpyinfo -display :0
>>>> It returns: xdpyinfo:  unable to open display ":0".
>>>> (also these commands are being done through ssh. If they need to be
>>>> done
>>>> directly I can)
>>>>
>>>> Further more When adding the line you requested into the
>>>> /etc/mdm/Init/Default script (which is in the correct location) did not
>>>> actually create file/folder that it should have. I wanted to verify
>>>> that
>>>> mdm is actually the display manager and it is (command used: cat
>>>> /etc/X11/default-display-manager).
>>>>
>>>> I made sure that I was part of the vglusers group.
>>>>
>>>> I tried to redirect the output of the vglgenkey but it seems to not be
>>>> touching the /etc/mdm/Init/Default script.
>>>>
>>>> I hope this sheds a little more light onto what is going on and if
>>>> there
>>>> is anything further I can provide i'd be happy to do as such. I
>>>> appreciate your time suggestions.
>>>> Thank you,
>>>>
>>>> Marshall Stageberg
>>>> Michigan State University
>>>>
>>>> Quoting DRC via VirtualGL-Users
>>>> <vir...@li...>:
>>>>
>>>>> The first thing to try, as indicated in the "Sanity Check" section of
>>>>> the docs
>>>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.rawgit.com_VirtualGL_virtualgl_master_doc_index.html-23hd006002&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=nlo4lHrLMFYP_Xf98qQ9cYZp7a4TF08aoFc0x7h2EEY&e=
>>>>>
>>>>> ),
>>>>> is:
>>>>>
>>>>>   xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>>>>   xdpyinfo -display :0
>>>>>
>>>>> That may reveal the underlying cause of the problem.  If the xauth
>>>>> command fails, then check the following:
>>>>>
>>>>> - Make sure that your installation of MDM keeps its initialization
>>>>> script in the standard place (/etc/mdm/Init/Default).  I've tested
>>>>> Linux
>>>>> Mint before, so it should work, but maybe they moved something in a
>>>>> more
>>>>> recent release.
>>>>>
>>>>> - Make sure that /etc/mdm/Init/Default is being modified properly by
>>>>> vglserver_config.  It should have a 'vglgenkey' line at the top if all
>>>>> is well.
>>>>>
>>>>> - Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
>>>>> restart the display manager and verify that /tmp/here is created.  If
>>>>> not, then the display manager isn't executing the initialization
>>>>> script
>>>>> as it should.  This is known to be an issue with some versions of GDM:
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D851769&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Rn4PmhNvGhcUbs7hyAtSVAqsn3QY5YkZOj6UmgSE7nI&e=
>>>>>
>>>>> .  Maybe the issue
>>>>> creeped into MATE as well?  (I hope not.)
>>>>>
>>>>> - Make sure you added yourself to the vglusers group and logged
>>>>> out/logged back in to activate the new group permissions.
>>>>>
>>>>> - Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
>>>>> file.  Restart the DM and look at the file to see if there are any
>>>>> error
>>>>> messages reported by vglgenkey.
>>>>>
>>>>> This is generally the process I use when diagnosing failures to access
>>>>> display :0.  Thus far, I have yet to encounter such a failure that
>>>>> wasn't due to one of the issues above.
>>>>>
>>>>> On 8/1/17 9:54 AM, sta...@ms... wrote:
>>>>>> Hi All,
>>>>>> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
>>>>>> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59
>>>>>> drivers.
>>>>>> Output from nvidia-xconfig --query-gpu-info:
>>>>>> Number of GPUs: 2
>>>>>>
>>>>>> GPU #0:
>>>>>>   Name      : GeForce GTX 1080 Ti
>>>>>>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>>>>>>   PCI BusID : PCI:4:0:0
>>>>>>
>>>>>>   Number of Display Devices: 0
>>>>>>
>>>>>>
>>>>>> GPU #1:
>>>>>>   Name      : GeForce GTX 1080 Ti
>>>>>>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>>>>>>   PCI BusID : PCI:65:0:0
>>>>>>
>>>>>>   Number of Display Devices: 0
>>>>>>
>>>>>> Pertinent output from lspci:
>>>>>> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>>>> (rev a1)
>>>>>> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>>>> (rev a1)
>>>>>>
>>>>>> I am using the default mdm display manager (comes stock with linux
>>>>>> mint)
>>>>>> When I plug a monitor into the computer directly all video functions
>>>>>> work correctly (glxgears, glxinfo, etc..)
>>>>>>
>>>>>> I setup the vncserver and then use the vncviewer to connect to the
>>>>>> headless server. When I try to execute vglrun glxgears I get the
>>>>>> error:
>>>>>> [VGL] ERROR: Could not open display :0.
>>>>>> I have ran the vglserver_config script with stopping the following
>>>>>> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
>>>>>> stopped the killed the nvidia persistence process prior to the setup
>>>>>> along with mdm. The config seemed to complete perfectly and I have
>>>>>> restarted the computer.
>>>>>>
>>>>>> I appreciate any further advice with this issue.
>>>>>> Thank you,
>>>>>>
>>>>>> Marshall Stageberg
>>>>>> Michigan State University
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org!
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=SyCf0kY2YDi4Tez8dF29jMd-L8WEuwnKYvK6RuTVVmM&s=F1Wc8JBKjtnqHWJ9foKn3gT2yA-TwIFZi846kVxUDNc&e=
>>
>> _______________________________________________
>> VirtualGL-Users mailing list
>> Vir...@li...
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_virtualgl-2Dusers&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=SyCf0kY2YDi4Tez8dF29jMd-L8WEuwnKYvK6RuTVVmM&s=Kj7Lo51y2q3tBSMGseAG7ih90I8febAcl6uxh9XpviY&e=
>>
>>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

[<sta...@ms...>]

Hi All,
I have changed my display manager from MDM to lightDM. It was a little  
buggy to get it going but it is now finally operational and seems to  
be working appropriately.
Doing the "sanity check" tests results in this:
marshall@computer ~ $ xauth merge /etc/opt/VirtualGL/vgl_xauth_key
marshall@computer ~ $ xdpyinfo -display :0
name of display:    :0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    11804000
X.Org version: 1.18.4
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
     depth 1, bits_per_pixel 1, scanline_pad 32
     depth 4, bits_per_pixel 8, scanline_pad 32
     depth 8, bits_per_pixel 8, scanline_pad 32
     depth 15, bits_per_pixel 16, scanline_pad 32
     depth 16, bits_per_pixel 16, scanline_pad 32
     depth 24, bits_per_pixel 32, scanline_pad 32
     depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  PointerRoot
number of extensions:    26
     BIG-REQUESTS
     Composite
     DAMAGE
     DOUBLE-BUFFER
     DPMS
     DRI2
     Generic Event Extension
     MIT-SCREEN-SAVER
     MIT-SHM
     Present
     RANDR
     RECORD
     RENDER
     SECURITY
     SHAPE
     SYNC
     X-Resource
     XC-MISC
     XFIXES
     XFree86-DGA
     XFree86-VidModeExtension
     XINERAMA
     XInputExtension
     XKEYBOARD
     XTEST
     XVideo
default screen number:    0
number of screens:    1

screen #0:
   dimensions:    640x480 pixels (169x127 millimeters)
   resolution:    96x96 dots per inch
   depths (7):    24, 1, 4, 8, 15, 16, 32
   root window id:    0x43
   depth of root window:    24 planes
   number of colormaps:    minimum 1, maximum 1
   default colormap:    0x20
   default number of colormap cells:    256
   preallocated pixels:    black 0, white 16777215
   options:    backing-store WHEN MAPPED, save-unders NO
   largest cursor:    640x480
   current input event mask:    0x420003
     KeyPressMask             KeyReleaseMask           StructureNotifyMask
     PropertyChangeMask
   number of visuals:    2
   default visual id:  0x21
   visual:
     visual id:    0x21
     class:    TrueColor
     depth:    24 planes
     available colormap entries:    256 per subfield
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits
   visual:
     visual id:    0x41
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    256 per subfield
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits
marshall@computer ~ $ /opt/VirtualGL/bin/glxinfo -display :0 -c
name of display: :0
Error: couldn't find RGB GLX visual or fbconfig
Error: couldn't find RGB GLX visual or fbconfig

Thank you again for all the advice.

Marshall Stageberg
Michigan State University

Quoting DRC via VirtualGL-Users <vir...@li...>:

> If LightDM is available under Linux Mint (I can't recall whether it is
> or not), that would be the next thing to try.
>
> On 8/1/17 7:13 PM, DRC wrote:
>> Ugh.  Unfortunately I think you're running into the aforementioned GDM
>> bug, then.  Even more unfortunately, I just re-tested it with Fedora 26,
>> and it's still there, so I'm sure it hasn't been fixed upstream yet.
>> Does anyone fix bugs anymore?!  Maybe I'm expecting too much for GDM to
>> load its own farking init script.
>>
>>
>> On 8/1/17 1:07 PM, sta...@ms... wrote:
>>> Thank you for your quick reply,
>>> I can at least provide more information regarding some of the short
>>> testing you had said to do.
>>> When using the command: xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>> It returns back nothing.
>>> When using the command: xdpyinfo -display :0
>>> It returns: xdpyinfo:  unable to open display ":0".
>>> (also these commands are being done through ssh. If they need to be done
>>> directly I can)
>>>
>>> Further more When adding the line you requested into the
>>> /etc/mdm/Init/Default script (which is in the correct location) did not
>>> actually create file/folder that it should have. I wanted to verify that
>>> mdm is actually the display manager and it is (command used: cat
>>> /etc/X11/default-display-manager).
>>>
>>> I made sure that I was part of the vglusers group.
>>>
>>> I tried to redirect the output of the vglgenkey but it seems to not be
>>> touching the /etc/mdm/Init/Default script.
>>>
>>> I hope this sheds a little more light onto what is going on and if there
>>> is anything further I can provide i'd be happy to do as such. I
>>> appreciate your time suggestions.
>>> Thank you,
>>>
>>> Marshall Stageberg
>>> Michigan State University
>>>
>>> Quoting DRC via VirtualGL-Users <vir...@li...>:
>>>
>>>> The first thing to try, as indicated in the "Sanity Check" section of
>>>> the docs
>>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.rawgit.com_VirtualGL_virtualgl_master_doc_index.html-23hd006002&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=nlo4lHrLMFYP_Xf98qQ9cYZp7a4TF08aoFc0x7h2EEY&e=
>>>> ),
>>>> is:
>>>>
>>>>   xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>>>   xdpyinfo -display :0
>>>>
>>>> That may reveal the underlying cause of the problem.  If the xauth
>>>> command fails, then check the following:
>>>>
>>>> - Make sure that your installation of MDM keeps its initialization
>>>> script in the standard place (/etc/mdm/Init/Default).  I've tested Linux
>>>> Mint before, so it should work, but maybe they moved something in a more
>>>> recent release.
>>>>
>>>> - Make sure that /etc/mdm/Init/Default is being modified properly by
>>>> vglserver_config.  It should have a 'vglgenkey' line at the top if all
>>>> is well.
>>>>
>>>> - Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
>>>> restart the display manager and verify that /tmp/here is created.  If
>>>> not, then the display manager isn't executing the initialization script
>>>> as it should.  This is known to be an issue with some versions of GDM:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D851769&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Rn4PmhNvGhcUbs7hyAtSVAqsn3QY5YkZOj6UmgSE7nI&e=
>>>> .  Maybe the issue
>>>> creeped into MATE as well?  (I hope not.)
>>>>
>>>> - Make sure you added yourself to the vglusers group and logged
>>>> out/logged back in to activate the new group permissions.
>>>>
>>>> - Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
>>>> file.  Restart the DM and look at the file to see if there are any error
>>>> messages reported by vglgenkey.
>>>>
>>>> This is generally the process I use when diagnosing failures to access
>>>> display :0.  Thus far, I have yet to encounter such a failure that
>>>> wasn't due to one of the issues above.
>>>>
>>>> On 8/1/17 9:54 AM, sta...@ms... wrote:
>>>>> Hi All,
>>>>> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
>>>>> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
>>>>> Output from nvidia-xconfig --query-gpu-info:
>>>>> Number of GPUs: 2
>>>>>
>>>>> GPU #0:
>>>>>   Name      : GeForce GTX 1080 Ti
>>>>>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>>>>>   PCI BusID : PCI:4:0:0
>>>>>
>>>>>   Number of Display Devices: 0
>>>>>
>>>>>
>>>>> GPU #1:
>>>>>   Name      : GeForce GTX 1080 Ti
>>>>>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>>>>>   PCI BusID : PCI:65:0:0
>>>>>
>>>>>   Number of Display Devices: 0
>>>>>
>>>>> Pertinent output from lspci:
>>>>> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>>> (rev a1)
>>>>> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>>> (rev a1)
>>>>>
>>>>> I am using the default mdm display manager (comes stock with linux mint)
>>>>> When I plug a monitor into the computer directly all video functions
>>>>> work correctly (glxgears, glxinfo, etc..)
>>>>>
>>>>> I setup the vncserver and then use the vncviewer to connect to the
>>>>> headless server. When I try to execute vglrun glxgears I get the error:
>>>>> [VGL] ERROR: Could not open display :0.
>>>>> I have ran the vglserver_config script with stopping the following
>>>>> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
>>>>> stopped the killed the nvidia persistence process prior to the setup
>>>>> along with mdm. The config seemed to complete perfectly and I have
>>>>> restarted the computer.
>>>>>
>>>>> I appreciate any further advice with this issue.
>>>>> Thank you,
>>>>>
>>>>> Marshall Stageberg
>>>>> Michigan State University
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=SyCf0kY2YDi4Tez8dF29jMd-L8WEuwnKYvK6RuTVVmM&s=F1Wc8JBKjtnqHWJ9foKn3gT2yA-TwIFZi846kVxUDNc&e=
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_virtualgl-2Dusers&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=SyCf0kY2YDi4Tez8dF29jMd-L8WEuwnKYvK6RuTVVmM&s=Kj7Lo51y2q3tBSMGseAG7ih90I8febAcl6uxh9XpviY&e=
>

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

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

If LightDM is available under Linux Mint (I can't recall whether it is
or not), that would be the next thing to try.

On 8/1/17 7:13 PM, DRC wrote:
> Ugh.  Unfortunately I think you're running into the aforementioned GDM
> bug, then.  Even more unfortunately, I just re-tested it with Fedora 26,
> and it's still there, so I'm sure it hasn't been fixed upstream yet.
> Does anyone fix bugs anymore?!  Maybe I'm expecting too much for GDM to
> load its own farking init script.
> 
> 
> On 8/1/17 1:07 PM, sta...@ms... wrote:
>> Thank you for your quick reply,
>> I can at least provide more information regarding some of the short
>> testing you had said to do.
>> When using the command: xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>> It returns back nothing.
>> When using the command: xdpyinfo -display :0
>> It returns: xdpyinfo:  unable to open display ":0".
>> (also these commands are being done through ssh. If they need to be done
>> directly I can)
>>
>> Further more When adding the line you requested into the
>> /etc/mdm/Init/Default script (which is in the correct location) did not
>> actually create file/folder that it should have. I wanted to verify that
>> mdm is actually the display manager and it is (command used: cat
>> /etc/X11/default-display-manager).
>>
>> I made sure that I was part of the vglusers group.
>>
>> I tried to redirect the output of the vglgenkey but it seems to not be
>> touching the /etc/mdm/Init/Default script.
>>
>> I hope this sheds a little more light onto what is going on and if there
>> is anything further I can provide i'd be happy to do as such. I
>> appreciate your time suggestions.
>> Thank you,
>>
>> Marshall Stageberg
>> Michigan State University
>>
>> Quoting DRC via VirtualGL-Users <vir...@li...>:
>>
>>> The first thing to try, as indicated in the "Sanity Check" section of
>>> the docs
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.rawgit.com_VirtualGL_virtualgl_master_doc_index.html-23hd006002&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=nlo4lHrLMFYP_Xf98qQ9cYZp7a4TF08aoFc0x7h2EEY&e=
>>> ),
>>> is:
>>>
>>>   xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>>   xdpyinfo -display :0
>>>
>>> That may reveal the underlying cause of the problem.  If the xauth
>>> command fails, then check the following:
>>>
>>> - Make sure that your installation of MDM keeps its initialization
>>> script in the standard place (/etc/mdm/Init/Default).  I've tested Linux
>>> Mint before, so it should work, but maybe they moved something in a more
>>> recent release.
>>>
>>> - Make sure that /etc/mdm/Init/Default is being modified properly by
>>> vglserver_config.  It should have a 'vglgenkey' line at the top if all
>>> is well.
>>>
>>> - Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
>>> restart the display manager and verify that /tmp/here is created.  If
>>> not, then the display manager isn't executing the initialization script
>>> as it should.  This is known to be an issue with some versions of GDM:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D851769&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Rn4PmhNvGhcUbs7hyAtSVAqsn3QY5YkZOj6UmgSE7nI&e=
>>> .  Maybe the issue
>>> creeped into MATE as well?  (I hope not.)
>>>
>>> - Make sure you added yourself to the vglusers group and logged
>>> out/logged back in to activate the new group permissions.
>>>
>>> - Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
>>> file.  Restart the DM and look at the file to see if there are any error
>>> messages reported by vglgenkey.
>>>
>>> This is generally the process I use when diagnosing failures to access
>>> display :0.  Thus far, I have yet to encounter such a failure that
>>> wasn't due to one of the issues above.
>>>
>>> On 8/1/17 9:54 AM, sta...@ms... wrote:
>>>> Hi All,
>>>> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
>>>> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
>>>> Output from nvidia-xconfig --query-gpu-info:
>>>> Number of GPUs: 2
>>>>
>>>> GPU #0:
>>>>   Name      : GeForce GTX 1080 Ti
>>>>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>>>>   PCI BusID : PCI:4:0:0
>>>>
>>>>   Number of Display Devices: 0
>>>>
>>>>
>>>> GPU #1:
>>>>   Name      : GeForce GTX 1080 Ti
>>>>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>>>>   PCI BusID : PCI:65:0:0
>>>>
>>>>   Number of Display Devices: 0
>>>>
>>>> Pertinent output from lspci:
>>>> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>> (rev a1)
>>>> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>>> (rev a1)
>>>>
>>>> I am using the default mdm display manager (comes stock with linux mint)
>>>> When I plug a monitor into the computer directly all video functions
>>>> work correctly (glxgears, glxinfo, etc..)
>>>>
>>>> I setup the vncserver and then use the vncviewer to connect to the
>>>> headless server. When I try to execute vglrun glxgears I get the error:
>>>> [VGL] ERROR: Could not open display :0.
>>>> I have ran the vglserver_config script with stopping the following
>>>> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
>>>> stopped the killed the nvidia persistence process prior to the setup
>>>> along with mdm. The config seemed to complete perfectly and I have
>>>> restarted the computer.
>>>>
>>>> I appreciate any further advice with this issue.
>>>> Thank you,
>>>>
>>>> Marshall Stageberg
>>>> Michigan State University

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

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

Ugh.  Unfortunately I think you're running into the aforementioned GDM
bug, then.  Even more unfortunately, I just re-tested it with Fedora 26,
and it's still there, so I'm sure it hasn't been fixed upstream yet.
Does anyone fix bugs anymore?!  Maybe I'm expecting too much for GDM to
load its own farking init script.


On 8/1/17 1:07 PM, sta...@ms... wrote:
> Thank you for your quick reply,
> I can at least provide more information regarding some of the short
> testing you had said to do.
> When using the command: xauth merge /etc/opt/VirtualGL/vgl_xauth_key
> It returns back nothing.
> When using the command: xdpyinfo -display :0
> It returns: xdpyinfo:  unable to open display ":0".
> (also these commands are being done through ssh. If they need to be done
> directly I can)
> 
> Further more When adding the line you requested into the
> /etc/mdm/Init/Default script (which is in the correct location) did not
> actually create file/folder that it should have. I wanted to verify that
> mdm is actually the display manager and it is (command used: cat
> /etc/X11/default-display-manager).
> 
> I made sure that I was part of the vglusers group.
> 
> I tried to redirect the output of the vglgenkey but it seems to not be
> touching the /etc/mdm/Init/Default script.
> 
> I hope this sheds a little more light onto what is going on and if there
> is anything further I can provide i'd be happy to do as such. I
> appreciate your time suggestions.
> Thank you,
> 
> Marshall Stageberg
> Michigan State University
> 
> Quoting DRC via VirtualGL-Users <vir...@li...>:
> 
>> The first thing to try, as indicated in the "Sanity Check" section of
>> the docs
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.rawgit.com_VirtualGL_virtualgl_master_doc_index.html-23hd006002&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=nlo4lHrLMFYP_Xf98qQ9cYZp7a4TF08aoFc0x7h2EEY&e=
>> ),
>> is:
>>
>>   xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>>   xdpyinfo -display :0
>>
>> That may reveal the underlying cause of the problem.  If the xauth
>> command fails, then check the following:
>>
>> - Make sure that your installation of MDM keeps its initialization
>> script in the standard place (/etc/mdm/Init/Default).  I've tested Linux
>> Mint before, so it should work, but maybe they moved something in a more
>> recent release.
>>
>> - Make sure that /etc/mdm/Init/Default is being modified properly by
>> vglserver_config.  It should have a 'vglgenkey' line at the top if all
>> is well.
>>
>> - Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
>> restart the display manager and verify that /tmp/here is created.  If
>> not, then the display manager isn't executing the initialization script
>> as it should.  This is known to be an issue with some versions of GDM:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D851769&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Rn4PmhNvGhcUbs7hyAtSVAqsn3QY5YkZOj6UmgSE7nI&e=
>> .  Maybe the issue
>> creeped into MATE as well?  (I hope not.)
>>
>> - Make sure you added yourself to the vglusers group and logged
>> out/logged back in to activate the new group permissions.
>>
>> - Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
>> file.  Restart the DM and look at the file to see if there are any error
>> messages reported by vglgenkey.
>>
>> This is generally the process I use when diagnosing failures to access
>> display :0.  Thus far, I have yet to encounter such a failure that
>> wasn't due to one of the issues above.
>>
>> On 8/1/17 9:54 AM, sta...@ms... wrote:
>>> Hi All,
>>> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
>>> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
>>> Output from nvidia-xconfig --query-gpu-info:
>>> Number of GPUs: 2
>>>
>>> GPU #0:
>>>   Name      : GeForce GTX 1080 Ti
>>>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>>>   PCI BusID : PCI:4:0:0
>>>
>>>   Number of Display Devices: 0
>>>
>>>
>>> GPU #1:
>>>   Name      : GeForce GTX 1080 Ti
>>>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>>>   PCI BusID : PCI:65:0:0
>>>
>>>   Number of Display Devices: 0
>>>
>>> Pertinent output from lspci:
>>> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>> (rev a1)
>>> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06
>>> (rev a1)
>>>
>>> I am using the default mdm display manager (comes stock with linux mint)
>>> When I plug a monitor into the computer directly all video functions
>>> work correctly (glxgears, glxinfo, etc..)
>>>
>>> I setup the vncserver and then use the vncviewer to connect to the
>>> headless server. When I try to execute vglrun glxgears I get the error:
>>> [VGL] ERROR: Could not open display :0.
>>> I have ran the vglserver_config script with stopping the following
>>> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
>>> stopped the killed the nvidia persistence process prior to the setup
>>> along with mdm. The config seemed to complete perfectly and I have
>>> restarted the computer.
>>>
>>> I appreciate any further advice with this issue.
>>> Thank you,
>>>
>>> Marshall Stageberg
>>> Michigan State University

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

[<sta...@ms...>]

Thank you for your quick reply,
I can at least provide more information regarding some of the short  
testing you had said to do.
When using the command: xauth merge /etc/opt/VirtualGL/vgl_xauth_key
It returns back nothing.
When using the command: xdpyinfo -display :0
It returns: xdpyinfo:  unable to open display ":0".
(also these commands are being done through ssh. If they need to be  
done directly I can)

Further more When adding the line you requested into the  
/etc/mdm/Init/Default script (which is in the correct location) did  
not actually create file/folder that it should have. I wanted to  
verify that mdm is actually the display manager and it is (command  
used: cat /etc/X11/default-display-manager).

I made sure that I was part of the vglusers group.

I tried to redirect the output of the vglgenkey but it seems to not be  
touching the /etc/mdm/Init/Default script.

I hope this sheds a little more light onto what is going on and if  
there is anything further I can provide i'd be happy to do as such. I  
appreciate your time suggestions.
Thank you,

Marshall Stageberg
Michigan State University

Quoting DRC via VirtualGL-Users <vir...@li...>:

> The first thing to try, as indicated in the "Sanity Check" section of
> the docs
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.rawgit.com_VirtualGL_virtualgl_master_doc_index.html-23hd006002&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=nlo4lHrLMFYP_Xf98qQ9cYZp7a4TF08aoFc0x7h2EEY&e=  
> ),
> is:
>
>   xauth merge /etc/opt/VirtualGL/vgl_xauth_key
>   xdpyinfo -display :0
>
> That may reveal the underlying cause of the problem.  If the xauth
> command fails, then check the following:
>
> - Make sure that your installation of MDM keeps its initialization
> script in the standard place (/etc/mdm/Init/Default).  I've tested Linux
> Mint before, so it should work, but maybe they moved something in a more
> recent release.
>
> - Make sure that /etc/mdm/Init/Default is being modified properly by
> vglserver_config.  It should have a 'vglgenkey' line at the top if all
> is well.
>
> - Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
> restart the display manager and verify that /tmp/here is created.  If
> not, then the display manager isn't executing the initialization script
> as it should.  This is known to be an issue with some versions of GDM:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D851769&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Rn4PmhNvGhcUbs7hyAtSVAqsn3QY5YkZOj6UmgSE7nI&e= .  Maybe the  
> issue
> creeped into MATE as well?  (I hope not.)
>
> - Make sure you added yourself to the vglusers group and logged
> out/logged back in to activate the new group permissions.
>
> - Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
> file.  Restart the DM and look at the file to see if there are any error
> messages reported by vglgenkey.
>
> This is generally the process I use when diagnosing failures to access
> display :0.  Thus far, I have yet to encounter such a failure that
> wasn't due to one of the issues above.
>
> On 8/1/17 9:54 AM, sta...@ms... wrote:
>> Hi All,
>> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
>> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
>> Output from nvidia-xconfig --query-gpu-info:
>> Number of GPUs: 2
>>
>> GPU #0:
>>   Name      : GeForce GTX 1080 Ti
>>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>>   PCI BusID : PCI:4:0:0
>>
>>   Number of Display Devices: 0
>>
>>
>> GPU #1:
>>   Name      : GeForce GTX 1080 Ti
>>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>>   PCI BusID : PCI:65:0:0
>>
>>   Number of Display Devices: 0
>>
>> Pertinent output from lspci:
>> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
>> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
>>
>> I am using the default mdm display manager (comes stock with linux mint)
>> When I plug a monitor into the computer directly all video functions
>> work correctly (glxgears, glxinfo, etc..)
>>
>> I setup the vncserver and then use the vncviewer to connect to the
>> headless server. When I try to execute vglrun glxgears I get the error:
>> [VGL] ERROR: Could not open display :0.
>> I have ran the vglserver_config script with stopping the following
>> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
>> stopped the killed the nvidia persistence process prior to the setup
>> along with mdm. The config seemed to complete perfectly and I have
>> restarted the computer.
>>
>> I appreciate any further advice with this issue.
>> Thank you,
>>
>> Marshall Stageberg
>> Michigan State University
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=2DnymlF_P6OfmuqWSvKktwOclnXtDFWKeWpmltkquPI&e=
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_virtualgl-2Dusers&d=DwICAg&c=nE__W8dFE-shTxStwXtp0A&r=is60q22IcyABEXnsSrzYNQ&m=o2rLPFelD8-NEVKAzy69YMV_WeYzc4l-R3NRWKaDzLg&s=Le6gHqAsmAIFTznxf6jo1Dy89Dd-A1p1e0D5DTLrrtc&e=
>

Re: [VirtualGL-Users] Dual GTX 1080i headless server issues

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

The first thing to try, as indicated in the "Sanity Check" section of
the docs
(https://cdn.rawgit.com/VirtualGL/virtualgl/master/doc/index.html#hd006002),
is:

  xauth merge /etc/opt/VirtualGL/vgl_xauth_key
  xdpyinfo -display :0

That may reveal the underlying cause of the problem.  If the xauth
command fails, then check the following:

- Make sure that your installation of MDM keeps its initialization
script in the standard place (/etc/mdm/Init/Default).  I've tested Linux
Mint before, so it should work, but maybe they moved something in a more
recent release.

- Make sure that /etc/mdm/Init/Default is being modified properly by
vglserver_config.  It should have a 'vglgenkey' line at the top if all
is well.

- Edit /etc/mdm/Init/Default and add 'echo here >/tmp/here', then
restart the display manager and verify that /tmp/here is created.  If
not, then the display manager isn't executing the initialization script
as it should.  This is known to be an issue with some versions of GDM:
https://bugzilla.redhat.com/show_bug.cgi?id=851769.  Maybe the issue
creeped into MATE as well?  (I hope not.)

- Make sure you added yourself to the vglusers group and logged
out/logged back in to activate the new group permissions.

- Edit /etc/mdm/Init/Default and redirect the output of vglgenkey to a
file.  Restart the DM and look at the file to see if there are any error
messages reported by vglgenkey.

This is generally the process I use when diagnosing failures to access
display :0.  Thus far, I have yet to encounter such a failure that
wasn't due to one of the issues above.

On 8/1/17 9:54 AM, sta...@ms... wrote:
> Hi All,
> I have setup a headless server with 2 - Nvidia GTX 1080i video cards
> using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
> Output from nvidia-xconfig --query-gpu-info:
> Number of GPUs: 2
> 
> GPU #0:
>   Name      : GeForce GTX 1080 Ti
>   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
>   PCI BusID : PCI:4:0:0
> 
>   Number of Display Devices: 0
> 
> 
> GPU #1:
>   Name      : GeForce GTX 1080 Ti
>   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
>   PCI BusID : PCI:65:0:0
> 
>   Number of Display Devices: 0
> 
> Pertinent output from lspci:
> 04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
> 41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
> 
> I am using the default mdm display manager (comes stock with linux mint)
> When I plug a monitor into the computer directly all video functions
> work correctly (glxgears, glxinfo, etc..)
> 
> I setup the vncserver and then use the vncviewer to connect to the
> headless server. When I try to execute vglrun glxgears I get the error:
> [VGL] ERROR: Could not open display :0.
> I have ran the vglserver_config script with stopping the following
> modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also
> stopped the killed the nvidia persistence process prior to the setup
> along with mdm. The config seemed to complete perfectly and I have
> restarted the computer.
> 
> I appreciate any further advice with this issue.
> Thank you,
> 
> Marshall Stageberg
> Michigan State University

[VirtualGL-Users] Dual GTX 1080i headless server issues

[<sta...@ms...>]

Hi All,
I have setup a headless server with 2 - Nvidia GTX 1080i video cards  
using Linux Mint 18.1 as the OS. I am using the Nvidia 384.59 drivers.
Output from nvidia-xconfig --query-gpu-info:
Number of GPUs: 2

GPU #0:
   Name      : GeForce GTX 1080 Ti
   UUID      : GPU-cc7afa9d-a61d-950a-0f45-511bd6f1f340
   PCI BusID : PCI:4:0:0

   Number of Display Devices: 0


GPU #1:
   Name      : GeForce GTX 1080 Ti
   UUID      : GPU-def710e8-b54f-d87d-be43-538d7395c0d8
   PCI BusID : PCI:65:0:0

   Number of Display Devices: 0

Pertinent output from lspci:
04:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)
41:00.0 VGA compatible controller: NVIDIA Corporation Device 1b06 (rev a1)

I am using the default mdm display manager (comes stock with linux mint)
When I plug a monitor into the computer directly all video functions  
work correctly (glxgears, glxinfo, etc..)

I setup the vncserver and then use the vncviewer to connect to the  
headless server. When I try to execute vglrun glxgears I get the error:
[VGL] ERROR: Could not open display :0.
I have ran the vglserver_config script with stopping the following  
modules: nvidia_drm, nvidia_uvm, nvidia_modeset, and nvidia. I also  
stopped the killed the nvidia persistence process prior to the setup  
along with mdm. The config seemed to complete perfectly and I have  
restarted the computer.

I appreciate any further advice with this issue.
Thank you,

Marshall Stageberg
Michigan State University

[VirtualGL-Users] Execution error with pvpython (GLXBadContext)

[Laurent P. <lau...@ec...>]

Dear VirtualGL-users,

I am using Paraview 5.4 with VirtualGL 2.5.2 on Centos 7.3 and I 
encounter an execution problem while using pvpython.

Step to reproduce :

|vglrun ~/bin/ParaView-5.4.0-Qt5-OpenGL2-MPI-Linux-64bit/bin/pvpython ||Python 2.7.11 (default, Jun 6 2017, 03:39:18) [GCC 5.3.1 20160406 (Red 
Hat 5.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" 
for more information. >>> from paraview.simple import * >>> renderView1 
= CreateView('RenderView')|

|X Error of failed request: GLXBadContext Major opcode of failed request: 
153 (GLX) Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) 
Serial number of failed request: 60 Current serial number in output 
stream: 60|

I can see in the Xorg.0.log the multiple connection attempt from 
pvpython which are closed instantaneously.

[2675346.781] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 9 
connected from local host ( uid=1520 gid=500 pid=26275 )
[2675346.782] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 9 disconnected
[2675346.782] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 9 
connected from local host ( uid=1520 gid=500 pid=26275 )
[2675346.783] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 10 
connected from local host ( uid=1520 gid=500 pid=26275 )
[2675347.317] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 11 
connected from local host ( uid=1520 gid=500 pid=26275 )
[2675347.329] AUDIT: Mon Jul  3 15:30:11 2017: 188066: client 12 
connected from local host ( uid=1520 gid=500 pid=26275 )
[2675347.417] AUDIT: Mon Jul  3 15:30:12 2017: 188066: client 9 disconnected
[2675347.417] AUDIT: Mon Jul  3 15:30:12 2017: 188066: client 12 
disconnected
[2675347.417] AUDIT: Mon Jul  3 15:30:12 2017: 188066: client 11 
disconnected
[2675347.418] AUDIT: Mon Jul  3 15:30:12 2017: 188066: client 10 
disconnected


The error does not occur when using Paraview GUI.

Does anyone have encounter this problem ? Is there any workaround ?
I have tried to set up some env variables, like DISPLAY or LD_PRELOAD, 
but it does not work.

Thank you for any advices.

Best regards,

Laurent Pouilloux

-- 
Ingénieur en Calcul Scientifique
Laboratoire de Mécanique des Fluides et d'Acoustique
École Centrale de Lyon
36 Avenue Guy de Collongue, 69130 Écully
Batiment I11 - Bureau 11097W
Tél : 	04.72.18.61.57

Re: [VirtualGL-Users] New year same question time for DRC

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

On 6/25/17 12:15 PM, jo...@ve... wrote:
> A graphics program can still accept commands via stdio, or some other
> rpc channel.
> 
> But, I think maybe I'm misunderstanding what the original problem was.
> 
> I'm just trying to describe that it's possible to decouple a graphics
> component from a controlling gui.
> 
> On X11 you can embed a graphics widget in another application, using for
> instance the xembed protocol, and maybe you could do something similar
> on android.
> 
> But if its complicated to port the vnc graphics widget there is no
> benefit to the approach,

Yeah, you can't use Swing widgets natively on Android.  They'd have to
be converted, and you'd want to do that anyhow, because the current GUI
is mouse-based, not touch-based.  The basic GUI paradigm is different
for a touchscreen device.  The good news is that Android does allow
copy-left open source software (whereas Apple doesn't), so there's a
possibility of borrowing from other Android VNC viewers.  I'm not very
good at GUI programming, so most of TurboVNC has evolved by me taking
other people's GUIs and making the back end much faster, then tweaking
the GUI to meet my needs.  Thus, the Android viewer would probably be
best approached by either taking the same approach I took initially to
build this project (accelerating an existing viewer code base) or by
encouraging someone else to build the GUI for me.  In either case,
without direct funding it's going to remain pretty far down on the
priority list.

Re: [VirtualGL-Users] New year same question time for DRC

[<jo...@ve...>]

DRC via VirtualGL-Users
<vir...@li...>
writes:

> On 6/10/17 11:09 AM, jo...@ve... wrote:
>> I think a command line client on Android for TurboVNC would be a useful
>> start.
>> 
>> I made a similar thing some years ago, where I ported a CLI sound generator
>> C program to Android. Then we made a gui frontend that controlled the
>> CLI program through stdio.
>> 
>> While a bit primitive, it worked well enough for us.
>
> How would a command-line client work?  VNC requires graphics.

A graphics program can still accept commands via stdio, or some other
rpc channel.

But, I think maybe I'm misunderstanding what the original problem was.

I'm just trying to describe that it's possible to decouple a graphics
component from a controlling gui.

On X11 you can embed a graphics widget in another application, using for
instance the xembed protocol, and maybe you could do something similar
on android.

But if its complicated to port the vnc graphics widget there is no
benefit to the approach,

>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
-- 
Joakim Verona
jo...@ve...

Re: [VirtualGL-Users] Java Buttons and Pull Down Menus with VirtualGL

[Michael A. S. <mic...@nr...>]

OK, then we are almost full circle from where I began this a week ago.  
TurboVNC along with VirtualGL works great over the remote VPN network.  
Performance is almost as if I were on site with Gigabit LAN.

Thanks,

Mike...

On 06/21/2017 10:05 PM, DRC via VirtualGL-Users wrote:
> If you're using the VGL Transport (vglconnect), then remote X11 is
> what's happening.  The VGL Transport is not recommended over slow
> connections for that reason (because the non-3D elements of the GUI have
> to be sent using remote X11, which is extremely fine-grained and thus
> very slow on high-latency connections-- particularly when you're talking
> about a toolkit like Swing that is not particularly well optimized for
> remote X11 usage.)  This is literally the reason why TurboVNC was
> created.  Strongly advise using it or another X proxy when connecting
> over a slow link.
>
> DRC
>
> On 6/21/17 8:58 PM, Michael A. Saverino wrote:
>> I am running a NASA WorldWind based Java application using VirtualGL.
>> The 3D GL rendering of the globe and terrain over local gigabit and
>> remote VPN is excellent.  However, clicking on a Java Pull down or
>> Button causes the application as well as all windows on the client to
>> freeze for a period of about 10-15 seconds.  I never get the pulldown
>> menu displayed.  This only manifests itself on the slower remote VPN
>> connection, not the Gigabit Lan connection.  Any ideas to what may be
>> happening?  The VirtualGL server is Ubuntu 14.04 with OpenJDK 8 and
>> 2.5.3 of VirtualGL.
>>
>> Thanks,
>>
>> Mike...
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Re: [VirtualGL-Users] Java Buttons and Pull Down Menus with VirtualGL

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

If you're using the VGL Transport (vglconnect), then remote X11 is
what's happening.  The VGL Transport is not recommended over slow
connections for that reason (because the non-3D elements of the GUI have
to be sent using remote X11, which is extremely fine-grained and thus
very slow on high-latency connections-- particularly when you're talking
about a toolkit like Swing that is not particularly well optimized for
remote X11 usage.)  This is literally the reason why TurboVNC was
created.  Strongly advise using it or another X proxy when connecting
over a slow link.

DRC

On 6/21/17 8:58 PM, Michael A. Saverino wrote:
> 
> I am running a NASA WorldWind based Java application using VirtualGL. 
> The 3D GL rendering of the globe and terrain over local gigabit and
> remote VPN is excellent.  However, clicking on a Java Pull down or
> Button causes the application as well as all windows on the client to
> freeze for a period of about 10-15 seconds.  I never get the pulldown
> menu displayed.  This only manifests itself on the slower remote VPN
> connection, not the Gigabit Lan connection.  Any ideas to what may be
> happening?  The VirtualGL server is Ubuntu 14.04 with OpenJDK 8 and
> 2.5.3 of VirtualGL.
> 
> Thanks,
> 
> Mike...

[VirtualGL-Users] Java Buttons and Pull Down Menus with VirtualGL

[Michael A. S. <mic...@nr...>]

I am running a NASA WorldWind based Java application using VirtualGL.  
The 3D GL rendering of the globe and terrain over local gigabit and 
remote VPN is excellent.  However, clicking on a Java Pull down or 
Button causes the application as well as all windows on the client to 
freeze for a period of about 10-15 seconds.  I never get the pulldown 
menu displayed.  This only manifests itself on the slower remote VPN 
connection, not the Gigabit Lan connection.  Any ideas to what may be 
happening?  The VirtualGL server is Ubuntu 14.04 with OpenJDK 8 and 
2.5.3 of VirtualGL.

Thanks,

Mike...

Re: [VirtualGL-Users] New year same question time for DRC

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

On 6/10/17 11:09 AM, jo...@ve... wrote:
> I think a command line client on Android for TurboVNC would be a useful
> start.
> 
> I made a similar thing some years ago, where I ported a CLI sound generator
> C program to Android. Then we made a gui frontend that controlled the
> CLI program through stdio.
> 
> While a bit primitive, it worked well enough for us.

How would a command-line client work?  VNC requires graphics.

Re: [VirtualGL-Users] New year same question time for DRC

[<jo...@ve...>]

DRC <dco...@us...>
writes:

> Good question.  Our current Java viewer (which, in combination with
> native glueware, is used as the TurboVNC Viewer on non-Windows
> platforms) was originally a by-product of an effort to produce an
> Android TurboVNC Viewer back in 2012, but the project was never fully
> completed.  Because I'm an independent developer, research projects like
> that often have to be implemented piecemeal as funding comes in for the
> various pieces, and it's often the case that, once a certain "critical
> mass" of pieces is implemented, it will be much easier to secure the
> funding for the remaining pieces.
>
> By the time 2012 rolled around, the JNI interface for libjpeg-turbo
> already existed as a result of an unrelated project.  Santos ponied up
> research funding for the next steps, because they were interested in
> using dockable multi-core Android phones as TurboVNC clients.  I was
> able to use that funding to clean up, integrate, and test the initial
> NEON optimizations for libjpeg-turbo (from Nokia and Linaro), as well as
> to work with Brian (TigerVNC developer) to bring over his Java TigerVNC
> Viewer code and enhance it so that it behaved more like the Windows
> TurboVNC Viewer and so that it could use libjpeg-turbo via JNI.  The
> reasoning was: get the Java TurboVNC Viewer infrastructure working
> first, then look at porting the GUI to Android from there.
>
> Unfortunately, the dockable Android phones never really materialized
> with the performance and features necessary for Santos to achieve what
> they needed (they drive 4-megapixel displays), and as time went on,
> Microsoft started producing tablet products that will run the native x86
> Windows TurboVNC Viewer, so there hasn't been a big push for an Android
> TurboVNC Viewer in industry.  I'm still interested in producing one,
> however.
>
> Since the latest release of Android now includes libjpeg-turbo, that
> might make things a bit easier now than it was in 2012, since it should
> hypothetically be possible to release a full-performance TurboVNC Viewer
> for Android that doesn't require a bundled NDK library.  The real trick
> is going to be porting the GUI.  I am adept at Swing programming, but
> Android GUI programming-- although it has a few of the same constructs--
> is quite a bit different than Swing, and it would basically be necessary
> to design a whole new GUI from scratch that is mobile-friendly and that
> implements the same features as the PC TurboVNC viewers.  All of the
> various dialogs and menus would have to be turned into
> touch-screen-friendly configuration screens, and I'd have to implement
> some mobile-friendly way to handle zooming, panning, scaling, resizing,
> etc.  If I had to do this from scratch, I could easily see it taking
> more than 100 hours to get a proof of concept working, and more than
> that to fully test it, document it, produce builds in a somewhat
> automated manner, etc.  There could be some reuse of the existing Java
> classes, but I'm guessing that maybe only half of that code could be
> reused (if that.)  Unclear whether I could reuse any of the existing
> encryption classes or what other low-level features would have to be
> re-written to accommodate the Android O/S.
>
> GUI-wise, it might be quicker to build upon an existing GPL-licensed
> Android VNC viewer GUI and simply enhance it for our needs.  That would
> certainly reduce the cost of the initial PoC.  Regardless, though, this
> is either going to require someone donating a lot of labor or donating a
> lot of money.

I think a command line client on Android for TurboVNC would be a useful
start.

I made a similar thing some years ago, where I ported a CLI sound generator
C program to Android. Then we made a gui frontend that controlled the
CLI program through stdio.

While a bit primitive, it worked well enough for us.

>
>
> On 2/16/17 5:27 PM, Jason Kurtz wrote:
>> DRC,
>> 
>> I know this is a question that comes up every year or more. I am
>> wondering how much do you estimate it would take to make a turbovnc
>> Android client. I have already complied and used virtualgl and turbovnc
>> on ARM Hard Float, and ARM 64. Even though there are other vnc clients.
>> When I tested them on the arm arch. Turbovnc blew all the other options
>> away. 
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
-- 
Joakim Verona
jo...@ve...
+46705459454

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

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

If the vendor can provide more information about how they are querying
the driver, then perhaps I can work around the issue in either VirtualGL
or TurboVNC.  If, for instance, they are using the NV-CONTROL X11
extension, then TurboVNC has support for that, but it has to be
explicitly enabled when you start a TurboVNC Server session:

https://cdn.rawgit.com/TurboVNC/turbovnc/2.1.1/doc/index.html#hd009003

Normally this would be done by passing "-nvcontrol :0.0" to
/opt/TurboVNC/bin/vncserver.  If they are using some nVidia-specific GLX
extension, then perhaps VirtualGL simply needs to interpose the function
calls related to that extension and advertise the extension when the
application queries the available GLX extensions.


On 6/2/17 8:02 AM, Peter Tyson wrote:
> Thanks for your suggestions.  The app is Avizo and the issue is that
> on startup it interrogates the driver in some way to determine the
> amount of vmem in the system which fails under VNC.  When such a zero
> value is returned the app then defaults to 4GB present.  The vendor
> supplied me with an environment variable which can override this
> value.
> 
> Peter

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

[Peter T. <pet...@gm...>]

Thanks for your suggestions.  The app is Avizo and the issue is that
on startup it interrogates the driver in some way to determine the
amount of vmem in the system which fails under VNC.  When such a zero
value is returned the app then defaults to 4GB present.  The vendor
supplied me with an environment variable which can override this
value.

Peter

On 1 June 2017 at 04:45, Nathan Kidd <nat...@sp...> wrote:
> On 31/05/17 05:02 AM, Peter Tyson wrote:
>> On 31 May 2017 at 12:06, DRC <dco...@us...> wrote:
>>>
>>>
>>> VGL mainly just modifies the GLX calls such that OpenGL rendering is
>>> redirected from a window on the 2D X server to a Pbuffer on the 3D X
>>> server.  I can't imagine why that would incur a VRAM limit, unless the
>>> same limit would be incurred when running the application locally
>>> without VGL.
>>>
>>
>> Thanks DRC, it seems that the issue is occurring due to the
>> application being run in VNC rather than VirtualGL.
>
> Perhaps your VNC server implements indirect GLX Mesa software rendering,
> and this gives the memory cap?  I suggest comparing OpenGL renderer
> strings when you see the memory limit and when you don't.
>
> -Nathan
>

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

[Nathan K. <nat...@sp...>]

On 31/05/17 05:02 AM, Peter Tyson wrote:
> On 31 May 2017 at 12:06, DRC <dco...@us...> wrote:
>>
>>
>> VGL mainly just modifies the GLX calls such that OpenGL rendering is
>> redirected from a window on the 2D X server to a Pbuffer on the 3D X
>> server.  I can't imagine why that would incur a VRAM limit, unless the
>> same limit would be incurred when running the application locally
>> without VGL.
>>
> 
> Thanks DRC, it seems that the issue is occurring due to the
> application being run in VNC rather than VirtualGL.

Perhaps your VNC server implements indirect GLX Mesa software rendering,
and this gives the memory cap?  I suggest comparing OpenGL renderer
strings when you see the memory limit and when you don't.

-Nathan

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

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

On 5/31/17 4:02 AM, Peter Tyson wrote:
>> VGL mainly just modifies the GLX calls such that OpenGL rendering is
>> redirected from a window on the 2D X server to a Pbuffer on the 3D X
>> server.  I can't imagine why that would incur a VRAM limit, unless the
>> same limit would be incurred when running the application locally
>> without VGL.
>>
> 
> Thanks DRC, it seems that the issue is occurring due to the
> application being run in VNC rather than VirtualGL.

That makes no sense, unless the application is imposing this limit
itself.  For the most part, modern VNC implementations present
themselves to applications as a standard X.org server, and VNC isn't
involved at all in 3D rendering if VirtualGL is being used.

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

[Peter T. <pet...@gm...>]

On 31 May 2017 at 12:06, DRC <dco...@us...> wrote:
>
>
> VGL mainly just modifies the GLX calls such that OpenGL rendering is
> redirected from a window on the 2D X server to a Pbuffer on the 3D X
> server.  I can't imagine why that would incur a VRAM limit, unless the
> same limit would be incurred when running the application locally
> without VGL.
>

Thanks DRC, it seems that the issue is occurring due to the
application being run in VNC rather than VirtualGL.

Re: [VirtualGL-Users] Max 4GB video memory available to apps?

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

On 5/30/17 8:05 AM, Peter Tyson wrote:
> I find that applications run under VirtualGL seem to see a maximum of
> 4096MB of video memory.  Is this a known limit? 
> I know 4GB is a large amount of memory but I'm encountering situations
> where it would be useful being able to allocate more than this.

VGL mainly just modifies the GLX calls such that OpenGL rendering is
redirected from a window on the 2D X server to a Pbuffer on the 3D X
server.  I can't imagine why that would incur a VRAM limit, unless the
same limit would be incurred when running the application locally
without VGL.

[VirtualGL-Users] Max 4GB video memory available to apps?

[Peter T. <pet...@gm...>]

I find that applications run under VirtualGL seem to see a maximum of
4096MB of video memory.  Is this a known limit?
I know 4GB is a large amount of memory but I'm encountering situations
where it would be useful being able to allocate more than this.

Thanks,
Peter

Re: [VirtualGL-Users] combine virtualgl and turbovnc

[Steve V. <vol...@gm...>]

I tried to keep my install as basic as I could, but my problem is I've
taken on 4 other projects since I've started with turbovnc tinkering.  I
had originally been following the user guides for both to try and get
things done in the most direct way possible, but I might need to start
again doing just to keep the steps fresh.

I should be able to do a full install from scratch this week.

On Sun, Apr 16, 2017 at 5:13 PM, DRC <dco...@us...>
wrote:

> You are so far away from the supported configuration and instructions that
> my only advice is to start over and follow the Users' Guides. vncserver
> should never be started from .xinitrc. TurboVNC is itself an X server, so
> it does not depend on the root X server. You indicated previously that you
> couldn't start TurboVNC any other way, and that is the real problem here.
> Your inability to start TurboVNC outside of .xinitrc indicates a problem
> with your system. You didn't provide specifics of how TurboVNC was failing,
> so I'm not sure what the problem is exactly, but I think you need to back
> up and figure out how to launch TurboVNC properly first (I can assist if
> you provide more specific information on how it's failing), then work on
> configuring VirtualGL.
>
> There are many thousands of VirtualGL and TurboVNC users worldwide who
> have successfully configured the solutions using the instructions in the
> users' guides. If there are problems with those instructions, then I'm
> happy to correct them, but you need to at least try the supported
> instructions first, and we can work from there.
>
> > On Apr 16, 2017, at 2:01 PM, Steve Volumetric <vol...@gm...>
> wrote:
> >
> > Hello,
> >
> > Based on previous advice I've been given from DRC,  I've attempted to
> start a full X server on display 0, and then launched turbovnc, which
> starts on display 1
> >
> > I did this by launching vncserver from within .xinitrc for a given user
> that launches X at boot.  This appeared to work, technically it did, but it
> would recursively launch 100 vnc server sessions, I assume 'vncserver'
> pulled in .xinitrc and launched it's self.
> >
> > now I have one script run at boot:
> >
> > su - someuseraccount -c "startx"
> >
> > followed immediately by a second script:
> >
> > su - someuseraccount -c "vncserver"
> >
> > I'm expecting this to start x, which it appears to, I assume it's coming
> up on display :0, but I'm not sure how to tell for sure remotely
> >
> > the second line should simply bring up the vncserver, which appears to
> be working fine, I can still connect to my system at port 5901 - exactly as
> before.
> >
> > this setup has resolved my issue of the recursive booting with 100
> sessions, but now virtual GL doesn't work.
> >
> > my GL testing program is Quake3, here is the relevant output:
> >
> > ----------------------
> > 4487 files in pk3 files
> > execing default.cfg
> > execing q3config.cfg
> > com_zoneMegs will be changed upon restarting.
> > couldn't exec autoexec.cfg
> > Hunk_Clear: reset the hunk ok
> > ----- Client Initialization -----
> > Couldn't read q3history.
> > ----- Initializing Renderer ----
> > Trying to load "renderer_opengl2_x86_64.so" from "."...
> > -------------------------------
> > QKEY found.
> > ----- Client Initialization Complete -----
> > ----- R_Init -----
> > Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No
> available video device)
> > Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No
> available video device)
> > Setting r_mode -1 failed, falling back on r_mode 3
> > Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No
> available video device)
> > ----- Client Shutdown (Client fatal crashed: GLimp_Init() - could not
> load OpenGL subsystem) -----
> > RE_Shutdown( 1 )
> > Hunk_Clear: reset the hunk ok
> > -----------------------
> > GLimp_Init() - could not load OpenGL subsystem
> >
> >
> >
> > glxinfo shows:
> > Invalid MIT-MAGIC-COOKIE-1 keyError: unable to open display :1
> >
> >
> >
> >
> > any advice would be openly welcome.  Thanks in advance.
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > VirtualGL-Users mailing list
> > Vir...@li...
> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>

Re: [VirtualGL-Users] combine virtualgl and turbovnc

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

You are so far away from the supported configuration and instructions that my only advice is to start over and follow the Users' Guides. vncserver should never be started from .xinitrc. TurboVNC is itself an X server, so it does not depend on the root X server. You indicated previously that you couldn't start TurboVNC any other way, and that is the real problem here. Your inability to start TurboVNC outside of .xinitrc indicates a problem with your system. You didn't provide specifics of how TurboVNC was failing, so I'm not sure what the problem is exactly, but I think you need to back up and figure out how to launch TurboVNC properly first (I can assist if you provide more specific information on how it's failing), then work on configuring VirtualGL.

There are many thousands of VirtualGL and TurboVNC users worldwide who have successfully configured the solutions using the instructions in the users' guides. If there are problems with those instructions, then I'm happy to correct them, but you need to at least try the supported instructions first, and we can work from there.

> On Apr 16, 2017, at 2:01 PM, Steve Volumetric <vol...@gm...> wrote:
> 
> Hello,
> 
> Based on previous advice I've been given from DRC,  I've attempted to start a full X server on display 0, and then launched turbovnc, which starts on display 1
> 
> I did this by launching vncserver from within .xinitrc for a given user that launches X at boot.  This appeared to work, technically it did, but it would recursively launch 100 vnc server sessions, I assume 'vncserver' pulled in .xinitrc and launched it's self.
> 
> now I have one script run at boot:
> 
> su - someuseraccount -c "startx"
> 
> followed immediately by a second script:
> 
> su - someuseraccount -c "vncserver"
> 
> I'm expecting this to start x, which it appears to, I assume it's coming up on display :0, but I'm not sure how to tell for sure remotely
> 
> the second line should simply bring up the vncserver, which appears to be working fine, I can still connect to my system at port 5901 - exactly as before.
> 
> this setup has resolved my issue of the recursive booting with 100 sessions, but now virtual GL doesn't work.
> 
> my GL testing program is Quake3, here is the relevant output:
> 
> ----------------------
> 4487 files in pk3 files
> execing default.cfg
> execing q3config.cfg
> com_zoneMegs will be changed upon restarting.
> couldn't exec autoexec.cfg
> Hunk_Clear: reset the hunk ok
> ----- Client Initialization -----
> Couldn't read q3history.
> ----- Initializing Renderer ----
> Trying to load "renderer_opengl2_x86_64.so" from "."...
> -------------------------------
> QKEY found.
> ----- Client Initialization Complete -----
> ----- R_Init -----
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> Setting r_mode -1 failed, falling back on r_mode 3
> Invalid MIT-MAGIC-COOKIE-1 keySDL_Init( SDL_INIT_VIDEO ) FAILED (No available video device)
> ----- Client Shutdown (Client fatal crashed: GLimp_Init() - could not load OpenGL subsystem) -----
> RE_Shutdown( 1 )
> Hunk_Clear: reset the hunk ok
> -----------------------
> GLimp_Init() - could not load OpenGL subsystem
> 
> 
> 
> glxinfo shows:
> Invalid MIT-MAGIC-COOKIE-1 keyError: unable to open display :1
> 
> 
> 
> 
> any advice would be openly welcome.  Thanks in advance.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users