That isn't an error. That is just the normal message that vglclient displays. I always try a procedure myself before I recommend it to anyone else, so I can confirm that the recommended procedure works for me.
On 6/9/20 5:01 PM, shoe wrote: > I tried concatenating the lines before. Also with semicolon between > them. Always the same error: > > VirtualGL Client 64-bit v2.6.3 (Build 20191024) > vglclient is already running on this X display and accepting unencrypted > connections on port 4242. > > > > On Tuesday, June 9, 2020 at 7:23:03 PM UTC+2, DRC wrote: > > NOTE: My e-mail client split the two commands onto different > lines, but > by "concatenate", I meant enter the commands on the same line. > > On 6/9/20 12:21 PM, DRC wrote: > > On 6/9/20 8:54 AM, shoe wrote: > >> Hi, > >> > >> I successfully use VirtualGT. Great software. I already setup > >> passwordless login. Now I want it even more comfortable. > >> > >> I want to set this up for somebody who knows even less then me > (sorry, > >> I am a total noob) > >> So I want them to be able to click an icon and everything works. > >> > >> So far they have to do this on the console: > >> > >> 1. /opt/VirtualGL/bin/vglconnect [email protected] > <javascript:> > >> (no password required) > >> > >> 2. /opt/VirtualGL/bin/vglrun -samp 4 -c jpeg -q 50 > >> Downloads/blender/blender > >> > >> > >> Can I somehow combine this into a single command? > > Yes. Just concatenate the two commands. > > > > /opt/VirtualGL/bin/vglconnect [email protected] <javascript:> > > /opt/VirtualGL/bin/vglrun -samp 4 -c jpeg -q 50 > Downloads/blender/blender > > > > Basically vglconnect is a wrapper for SSH, so you can pass any SSH > > command-line options to it (including specifying a remote > command to run.) > > > > > >> P.S.: the server is quite powerful - certainly no bottleneck. The > >> client super old (although the CPU is only at ~20% when running > >> blender). Still, for example rotating objects in blender is > still a > >> little choppy. I already increased responsiveness massively by > >> reducing jpeg quality. Does this mean it is most likely a > bandwidth > >> issue and I cannot do anything about it? Or is it maybe the GPU > of the > >> little client and not the CPU which I can monitor? I doubt it > is less > >> difficult for the GPU to handle more compressed jpeg, right? Or > is the > >> bigger jpeg size more demanding for the client (and not > necessarily > >> the bandwidth?) > > Unless you are on a local-area network, you should not use the VGL > > Transport (vglconnect.) Use TurboVNC instead. The VGL > Transport is a > > legacy feature that relies on remote X to display any non-OpenGL > > elements of the application's GUI, so the choppy behavior is > likely due > > to the application updating those other elements of the GUI. > Remote X, > > since it is generally a fine-grained protocol, is very sensitive to > > network latency. > > > > > > -- > You received this message because you are subscribed to the Google > Groups "VirtualGL User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/c6c68e11-c8d2-442e-9760-aadef5b16c66o%40googlegroups.com > <https://groups.google.com/d/msgid/virtualgl-users/c6c68e11-c8d2-442e-9760-aadef5b16c66o%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/c561f67c-f709-5f0b-9dec-46512d5898d6%40virtualgl.org.
