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

to new messages shortly, so please transfer your subscriptions immediately. DRC -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

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

; depth:32 planes > available colormap entries:256 per subfield > red, green, blue masks:0xff, 0xff00, 0xff > significant bits in color specification:8 bits > marshall@computer ~ $ /opt/VirtualGL/bin/glxinfo -display :0 -c > name of display: :0 > Er

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

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 Fed

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

uch. I > appreciate your time suggestions. > Thank you, > > Marshall Stageberg > Michigan State University > > Quoting DRC via VirtualGL-Users <virtualgl-users@lists.sourceforge.net>: > >> The first thing to

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

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

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

On 6/25/17 12:15 PM, joa...@verona.se 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

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

On 6/10/17 11:09 AM, joa...@verona.se 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

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

t 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

Re: [VirtualGL-Users] combine virtualgl and turbovnc

> 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

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

seems like TurboVNC session does not like my > realVNC viewer. > > My compute environment cannot easily build from source...I'm working on > that and if I"m lucky I can reproduce it with more debugging information. > > Thanks! > > On Thu, Mar 9, 2017 at 8:25 PM, DR

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

I tried but was unable to reproduce any failure with the RealVNC Viewer. Please provide the information I requested in my previous message. On 2/21/17 4:34 PM, Wei Liu wrote: > Thanks DRC for the information. With all the constraints in our compute > environment, I do want to debug that

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

chment/CADO%2BGxwCAOx9JSSURsAMKQt%2B_k-RaEJ%2BTLXj_AxfaCHmAFMmwA%40mail.gmail.com/1/> > > The OP is having a problem with TurboVNC, not VirtualGL. The nVidia > driver is not relevant to the problem. Please let me handle this. > Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrot

Re: [VirtualGL-Users] Android Donations for DRC

On 2/23/17 8:41 AM, Jason Kurtz wrote: > Actually alot of projects use and depend on VirtualGL. I think the > intersection of GPL apps that could connect to it on Android. You would > get alot more funding then you think. The user supported pro version of > bvnc is a good example with 1-5k

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

l informed and are not helping the situation. On 2/23/17 8:28 AM, Jason Kurtz wrote: > I agree DRC. Its looks suspiciously like this bug > https://bugs.freedesktop.org/show_bug.cgi?id=71338 . Which causes XIO: fatal > IO error 11 (Resource temporarily unavailable) on X server ":0" .

Re: [VirtualGL-Users] Android Donations for DRC

On 2/22/17 3:54 PM, Jason Kurtz wrote: > I understand, Have you considered a kickstarter. I know there is a large > base using turbovnc and even a larger base using virtualgl. There's not > really a great alternative. I would be happy to donate to something like > that. bvnc pro which is the

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

can not > negotiate from the client a compression method so it dumps the connection. > You need to switch from realvnc to turbovnc on the windows client > machines like DRC says. Just grab turbovnc client for the wind

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

The OP is having a problem with TurboVNC, not VirtualGL. The nVidia driver is not relevant to the problem. Please let me handle this. Thanks. On 2/22/17 1:48 PM, Jason Kurtz wrote: > Could you also run the following commands on the ubuntu server. > List all packages installed on the system. >

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

e: > Jason, DRC, > > The vnc session I created with TurboVNC crashes a few times. Can it be > caused by my realVNC viewer? (seems hard to believe an incompatible > viewer crashes the session) I haven't got a chance to use TurboVNC > viewer due to other constraints. > > Ho

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

nly 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. 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 ho

Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

You can use headless GPUs with VirtualGL. Install the nVidia proprietary drivers (I believe Ubuntu provides a package for these), then run: nvidia-xconfig -a --use-display-device=None --virtual=1920x1200 (I don't think the resolution specified for --virtual matters, since it's headless.)

Re: [VirtualGL-Users] VirtualGL without display manager

Without a display manager? Yes-- simply use startx to start a local (server-side) X server on the GPU, then use `xhost +LOCAL:` to grant access for that X server to the local machine (or share the XAuth token with other users who need to access it.) vglserver_config essentially automates the

Re: [VirtualGL-Users] VGL image transport port..

Not sure what you mean by "statically", but you can control the vglclient port using environment variables: https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.1/doc/index.html#hd0019002 On 12/9/16 12:30 PM, Anthony Moon wrote: > Hi all, > > > > Quick question, is it possible to statically set

Re: [VirtualGL-Users] virtualgl vs. steam inhome streaming

I'm not very familiar with Steam in-home streaming, but my guess, based on the advertising materials for it, is that it's an application-specific screen scraping solution. In other words, a copy of Steam runs on one PC and sends a copy of the graphics it's rendering on that PC's physical display

Re: [VirtualGL-Users] Sometimes garbled output

It's impossible to say without knowing more. It could be a bug in TigerVNC, or the window manager, or VirtualGL, or the nVidia drivers. Unfortunately, there's no way to know unless you can somehow narrow down the possibilities for me: -- Are you running the window manager using VirtualGL, or are

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

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

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

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.

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

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 wrote: > > Hello VirtualGL mailing list, > > I'm attempting to build the virtualGL server & also TurboVNC from source, and >

Re: [VirtualGL-Users] TOTP in TurboVNC

al 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"). > > 2

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

third-party PAM > module for it, but it’s easier to run an external lightweight command > like oathtool (e.g. using x11vnc I only have to specify -passwdfile > "cmd:oathtool --totp $SECRET"). > > 2016-07-22 23:14 GMT+02:00 DRC <dcomman...@users.sourceforge.net>: >> >>

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

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

Re: [VirtualGL-Users] VirtualGL with VirtualBox

know which ones. > > Sent from my BlackBerry 10 smartphone. > Original Message > From: DRC > Sent: Monday, June 6, 2016 11:12 AM > To: virtualgl-users@lists.sourceforge.net > Reply To: VirtualGL Users > Subject: Re: [VirtualGL-Users] VirtualGL with VirtualBox >

Re: [VirtualGL-Users] [TurboVNC-Users] GPU needs for headless server and multiple VirtualGL sessions

CCing virtualgl-users, since some people on that list may have some additional input. VirtualGL allows multiple users to share the same GPU, and most modern nVidia or AMD GPUs should be able to easily support 5-10 simultaneous sessions, particularly if they're not doing a lot of heavy

Re: [VirtualGL-Users] What is the danger in permanently preloading the libraries?

On 12/1/15 8:38 PM, Logan McNaughton wrote: > What is the danger in adding: > > /usr/lib64/libdlfaker.so /usr/lib64/librrfaker.so > > to /etc/ld.so.preload? > > In my testing it seems to work fine (so you don't need to use "vglrun" > to activate OpenGL graphics). > I read somewhere it's a bad

[VirtualGL-Users] VirtualGL 2.5 beta1 has been released

Official binaries are available here: https://sourceforge.net/projects/virtualgl/files/2.4.90%20%282.5beta1%29/ Changelog is available here: https://github.com/VirtualGL/virtualgl/releases/tag/2.5beta1 --

Re: [VirtualGL-Users] Qt: 5 key map messed up on VNC connection

I have a build of Qt5 on CentOS 6. Can this be reproduced using any of the sample applications? On 10/22/15 10:19 PM, jupiter wrote: > Hi, > > I built QT 5 from the source and I am running it on CentOS 6 VM. When I > connected the VM via Turbovnc, the keys are messed up in QT 5 > applications

Re: [VirtualGL-Users] Qt: 5 key map messed up on VNC connection

Sounds good. Yes, 2.0 should fix it. I recommend installing the 2.0.1 pre-release: http://turbovnc.sourceforge.net/vnc.nightly.2.0.x/ as it fixes numerous bugs. 2.0.1 should go live in the next few days. On 10/22/15 11:54 PM, jupiter wrote: > Hi DRC, > >> I have a build of Qt5

Re: [VirtualGL-Users] Qt: 5 key map messed up on VNC connection

Two other items: -- Which version of the TurboVNC server? XKEYBOARD isn't going to be supported except in TurboVNC 2.0 and later. -- Please note that we have separate mailing lists for TurboVNC now. In the future, please post TurboVNC-specific issues to turbovnc-users (you can also file

[VirtualGL-Users] SC15

sponsors. DRC -- ___ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users

[VirtualGL-Users] Putting out feelers for new funded development work

I have a couple of funded projects in the works for TurboVNC 2.1, but there is no funded work on the horizon for VirtualGL and TurboVNC after the end of 2015. As you know, I rely on funded development opportunities in order to stay afloat as an independent developer, which allows me to

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

> > Once again, sorry for my inaccuracy & false alarm. > > -Original Message- > From: DRC [mailto:dcomman...@users.sourceforge.net] > Sent: Thursday, September 03, 2015 3:58 PM > To: virtualgl-users@lists.sourceforge.net > Subject: Re: [VirtualGL-

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

Which version of VirtualGL? That is literally the most important detail to include in any bug report. Also, if you're observing that '-c proxy' performs better than the default '-c jpeg', then something is terribly wrong. "Proxy mode" is intended for X proxies, e.g. TurboVNC. It sends the

Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded

compression types -- they all seem very fluid. > > Perhaps, I've setup something incorrectly with Cygwin\X. I will > re-investigate that, and re-read the documentation. > > Once again, sorry for my inaccuracy & false alarm. > > -Original Message- > From: DRC [mailto:dcomm

[VirtualGL-Users] Signed binaries

All of the VirtualGL binaries back to 2.3 have been digitally signed. See http://www.virtualgl.org/Downloads/DigitalSignatures for instructions on how to verify the signatures. --

Re: [VirtualGL-Users] Starting non-interactive remote program

suggestion, that allows you to specify a program to run on the server: e.g. vglconnect -s -C -e 'vglrun /opt/VirtualGL/bin/glxspheres64' myserver New script is attached. Let me know if it works, and if so, I'll check it in. On 8/5/15 6:43 AM, DRC wrote: I don't think it would be very difficult

Re: [VirtualGL-Users] Starting non-interactive remote program

I don't think it would be very difficult to add that functionality, given that vglconnect is basically just a wrapper for SSH. Let me look at it further and get back to you. On Aug 5, 2015, at 3:15 AM, Heiko Klein heiko.kl...@met.no wrote: Hi, we're currently successfully using vgl to

Re: [VirtualGL-Users] Fwd: virtualgl with a client running application

It is very unclear what you are trying to do, so please clarify. I don't understand what a virtual machine or Android has to do with anything. On 6/16/15 5:17 AM, Igor Itkin wrote: Hi all Do I understand correctly, that application should run on the server, and there is no way to run it on

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

Yes, I would say that figuring out the API is a bit of a squirrel catcher-- meaning that if you can't get past that part, you are unlikely to get very far with the rest of the project. As Nathan said, the API is easy. Figuring out how to make the plugin encode and stream H.264, communicate

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

documentation for virtualgl developers? I need to understand the code, if i have to write a plugin. And the code is not trivial. I have no experience, and i never read virtualgl code before. However, thanks again for you answers. MM 2015-06-12 22:42 GMT+02:00 DRC dcomman...@users.sourceforge.net

Re: [VirtualGL-Users] VirtualGL - reduce bandwidth with compression

, MM 2015-05-27 9:42 GMT+02:00 DRC dcomman...@users.sourceforge.net mailto:dcomman...@users.sourceforge.net: Depending on what you really need to do, it may not be necessary to get that fancy. Most users of VirtualGL use it with an X11 proxy. TurboVNC is the X proxy that our

Re: [VirtualGL-Users] VirtualGL 2.4.1 has been released

to github from sourceforge, in light of their recent behavior? Sorry if this has already been addressed. On Fri, Jun 12, 2015 at 8:19 AM, DRC dcomman...@users.sourceforge.net mailto:dcomman...@users.sourceforge.net wrote: http://sourceforge.net/projects/virtualgl/files/2.4.1/ Packaging

Re: [VirtualGL-Users] VirtualGL and Qt5

On 3/24/15 9:49 AM, Dr. Roman Grothausmann wrote: One problem that I've observed with VirtualGL-2.4 (+XCB) is that the app crashes with [VGL] ERROR: in getGLXDrawable-- [VGL]186: Window has been deleted by window manager That isn't a crash. It's VirtualGL being nice and preventing a

Re: [VirtualGL-Users] Remote VirtualGL Server

Not really. There would be issues with such a solution: -- Compatibility: Indirect OpenGL will not have access to a lot of OpenGL extensions that applications might need, and you could run into even more serious compatibility problems if the X proxy server and the 3D server are not running

Re: [VirtualGL-Users] [VGL] ERROR: glXCreateContextAttribsARB symbol not loaded

On 3/13/15 10:25 AM, Alex Xu wrote: I get the aforementioned error when running almost anything through VirtualGL through various methods (SSH X11 forwarding and local VNC). Specifically, running vglconnect -s host 'vglrun glxinfo' results in this error. However, running ssh host

Re: [VirtualGL-Users] Stereoscopic Rendering (quad-buffered) and VirtualGL with a headless server

I personally use a Quadro FX 5000, so my experience with headless configurations is limited. What I will say, however, is that there shouldn't be any reason why nVidia couldn't provide stereo Pbuffer support in a headless configuration, since VirtualGL doesn't actually need stereo display on

[VirtualGL-Users] VirtualGL 2.4 has been released

http://sourceforge.net/projects/virtualgl/files/2.4/ Significant changes since 2.4 beta1: [1] Fixed an issue that prevented recent versions of Google Chrome/Chromium from running properly in VirtualGL. [2] VGL_SYNC now affects glFlush(). Although this does not strictly conform to the OpenGL

Re: [VirtualGL-Users] OpenGL Resize Issue with Qt 5

! On 17 Jan 2015, at 16:41, DRC dcomman...@users.sourceforge.net wrote: Ah, sorry, this was my fault. I totally forgot that you now have to do 'vglrun +xcb' in order to enable the XCB faker. This was so existing VirtualGL shops could rebuild their installation to support Qt5 without having

Re: [VirtualGL-Users] OpenGL Resize Issue with Qt 5

a vglconnect localhost and vglrun ./example. Using the above code, the window is resized to 800x600, but the green frame is only very small in the top left corner. Best, Tim On 01/16/2015 11:31 PM, DRC wrote: Can you send me the source code for your widget? On 1/16/15 4:02 PM, Tim

Re: [VirtualGL-Users] OpenGL Resize Issue with Qt 5

Can you send me the source code for your widget? On 1/16/15 4:02 PM, Tim Biedert wrote: Dear VirtualGL team, I’m trying to vglrun a simple Qt 5.4 application which only contains an OpenGL widget as the central widget. There is still a resize issue: - When the window is resized, the

Re: [VirtualGL-Users] Xinerama inside TurboVNC

Even though this is really a TurboVNC issue, I'm continuing the thread here, because the same would apply to other X proxies. I have verified that: -- As Nathan pointed out, the XINERAMA warning is innocuous. The actual fatal error is because of the RANDR extension. -- As I suspected, the

[VirtualGL-Users] Good news, everyone! (regarding 3D window managers)

of a way around it at the moment, though, so please do your own testing and file a bug report or post a message to VirtualGL-Users if you encounter any issues. DRC

Re: [VirtualGL-Users] Issues with Qt 5

On 10/27/14 3:16 AM, Peter Astrand wrote: I totally agree with you on this one. I guess people thinks it's more fun to work with new projects and new code, than to maintain old stuff. But this idea of new = always better is present in the entire industry; not just in the open source community.

Re: [VirtualGL-Users] Issues with Qt 5

, and it should work on systems of similar vintage and newer. Let me know if you run into any issues. On 7/29/14 2:32 AM, DRC wrote: Ugh. The more I look into this, the nastier it gets. A lot of the other Qt5 OpenGL demos don't work because VirtualGL isn't intercepting xcb_glx_query_version

Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers

be that the polygon count is clamped to a 16-bit value or something. On 10/2/14 5:13 PM, Nathan Kidd wrote: On 02/10/14 04:26 PM, DRC wrote: On the K5000 that nVidia was kind enough to send me for testing, I can literally max out the geometry size on GLXspheres-- over a billion polys

Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers

, some of them will be reading e-mail, some of them won't even be in the office, some will be staring at the model and making small changes rather than manipulating the entire scene. On 10/2/14 5:13 PM, Nathan Kidd wrote: On 02/10/14 04:26 PM, DRC wrote: On the K5000 that nVidia was kind enough

Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers

We crossed the streams. I discovered exactly the same thing (refer to previous message.) On 10/2/14 10:38 PM, Nathan Kidd wrote: On 02/10/14 09:16 PM, DRC wrote: Note that there are actually 61 spheres in the default configuration (20 per ring + the 1 in the center), so apparently

Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers

. From: DRC [dcomman...@users.sourceforge.net] Sent: Thursday, October 02, 2014 10:26 PM To: virtualgl-users@lists.sourceforge.net Subject: Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers For starters, GLXgears is not a GPU benchmark. It is a CPU benchmark

Re: [VirtualGL-Users] dead keys

Please move this discussion to TurboVNC-Users as I asked you to do. There are people on this list who have no interest in TurboVNC. DRC On 9/23/14 2:57 PM, Dieter Blaas wrote: Hi, sorry for still posting here but I did not want to interrupt my thread: Before installing on the server

Re: [VirtualGL-Users] dead keys

Vienna, Austria, Tel: 0043 1 4277 61630, Fax: 0043 1 4277 9616, e-mail: dieter.bl...@meduniwien.ac.at Am 17.09.2014 15:52, schrieb DRC: TurboVNC now has it's own set of mailing lists, so please subscribe

Re: [VirtualGL-Users] Damaged Framebuffer with multiple users

I have never seen issues like this with nVidia drivers, and in fact VGL is deployed commercially on machines where dozens of users (sometimes more) are sharing a GPU. I have, however, seen multi-instance problems like this with Intel's drivers. You didn't specify which GPU and driver revision

Re: [VirtualGL-Users] Damaged Framebuffer with multiple users

Has the driver been upgraded recently? Does setting VGL_READBACK=sync work around the problem? Does using a different version of VGL work around it? Suffice it to say that no one else is experiencing this, so I strongly suspect that you'll have better luck filing it as a support request with

Re: [VirtualGL-Users] client display not working unless connected to already running server display

) glReadPixels() accounted for 99.99% of total readback time On Thu, Sep 4, 2014 at 4:11 PM, DRC dcomman...@users.sourceforge.net mailto:dcomman...@users.sourceforge.net wrote: These are the assumptions I'm making from the above behavior. There is an X Server running on machine 1

Re: [VirtualGL-Users] client display not working unless connected to already running server display

Your question doesn't make sense, which means that either you aren't choosing your words correctly or you still don't understand how the system is supposed to work. What do you mean by running? The 3D X server is completely independent of TurboVNC. They are different X servers. VirtualGL

Re: [VirtualGL-Users] Issues with Qt 5

: An in-house app fails to display any 3D content with VirtualGL since it was migrated to Qt5 from Qt4. According to the developer no code was changed other than what was required to migrate the app to the Qt5 namespace. -Original Message- From: DRC [mailto:dcomman

Re: [VirtualGL-Users] Issues with Qt 5

Have you been experiencing other issues besides just the resize issue? On 7/25/14 5:17 AM, peter.ty...@csiro.au wrote: Hi All, We have been having trouble running OpenGL Qt5 apps with VirtualGL including 2.4 beta1. One easily reproducible issue is the OpenGL examples supplied with Qt5

Re: [VirtualGL-Users] Issues with Qt 5

Confirmed. To give some background, the way that VirtualGL normally detects window resizes is to monitor the application's X event loop for ConfigureNotify events, which are sent by the X server to the application whenever the window is resized. However, this assumes that the application is

[VirtualGL-Users] Overhauled TurboVNC 2.0 X server (based on X.org 7.7) available for testing

It can be downloaded from here: http://www.turbovnc.org/DeveloperInfo/PreReleases Xvnc has been completely refactored using the stock X.org 7.7 code base (but with full integration into the TurboVNC CMake build system.) The keyboard handler has also been overhauled using a port of the

Re: [VirtualGL-Users] Kepler card support

On 8/23/13 2:53 AM, Paul Melis wrote: Slightly OT, but just noticed this in the 319.49 release notes: Added the NVIDIA OpenGL-based Inband Frame Readback (NvIFROpenGL) libraryto the Linux driver package. This library provides a high performance, low latency interface to capture and optionally

Re: [VirtualGL-Users] voreen canvas always black when using virtualGL

Sorry for the delay on this-- things have been hectic the past few months. This issue has been fixed in the VirtualGL SVN repository and will be rolled into a new release within the next week. In a nutshell, VGL was not properly handling cases in which glXSwapBuffers() was called with a

Re: [VirtualGL-Users] Visuals only appear with vglconnect -s

Hmmm... Well, the nuts and bolts of it are that the faker will connect to whatever hostname or IP address is specified in the VGL_CLIENT environment variable. When you connect with vglconnect -s, an SSH tunnel is established for the VGL Transport, and a script (vgllogin) is run on the server.

Re: [VirtualGL-Users] OpenGL window disappearing

that I removed, btw. Paul On 05/21/2014 01:23 AM, DRC wrote: I've learned never to say that anything is impossible, because I usually end up being proven wrong, but let's just say that if VirtualGL is causing this, it is by way of an as-yet-undiscovered mechanism that I can't

Re: [VirtualGL-Users] OpenGL window disappearing

of any functions except GLX functions. Can you send me a VGL trace of the application along with a list of the window handles (obtainable with xwininfo) from the window that is on display :1 and the window that is on display :0? On 5/20/14 4:37 PM, Paul Melis wrote: Hi DRC, I'm afraid sharing

Re: [VirtualGL-Users] Turbo VNC server pakage for Ubuntu

clearly indicates. It is placed there intentionally so as to avoid conflicting with any VNC installation that might be installed in /usr/bin. dpkg --contents turbovnc_1.2.1_amd64.deb drwx-- drc/drc 0 2013-11-22 13:55:53 ./ drwxr-xr-x root/root 0 2013-11-22 13:55:53 ./opt

[VirtualGL-Users] Moving TurboVNC into a separate project

In order to increase the visibility of TurboVNC in the open source community, I think it may be time to consider spinning it off from The VirtualGL Project. When VirtualGL was first open sourced 10 years ago, it made sense to include TurboVNC in the same project, because there were no other

Re: [VirtualGL-Users] Does VirtualGL support OpenGL ES ?

with that ? Thank you again for all your support, George On Sun, Apr 6, 2014 at 5:38 PM, DRC dcomman...@users.sourceforge.net mailto:dcomman...@users.sourceforge.net wrote: On 4/6/14 5:06 AM, George Profenza wrote: Thank you very much for the detailed explanations and your patience

Re: [VirtualGL-Users] Does VirtualGL support OpenGL ES ?

So, let me break this down: We don't support RPi as a server platform for VirtualGL. You are asking for support on something that is not supported and may not even be supportable in the context of this project. You are attempting to do something that no one else has attempted, so you're

Re: [VirtualGL-Users] Altair Hypermesh

Sorry for the delay on this. Both issues have been reproduced, and I'm investigating. On 3/3/14 1:25 AM, Patrik Pira wrote: Yes, flickering does occur with VGL 2.3. It does go away when I switch to software opengl. 2014-02-28 18:39, DRC skrev: OK, fair enough. I'm working with Altair

Re: [VirtualGL-Users] Exceed support

On 3/24/14 11:01 AM, Nathan Kidd wrote: As an OpenText developer dealing with 3D, I never hear of anybody using VirtualGL + Exceed 14 on Windows. In the same way that you focus on VirtualGL + TurobVNC we focus on VirtualGL + Exceed VA TurboX (formerly Exceed onDemand) because users will get

Re: [VirtualGL-Users] Exceed support

On 3/24/14 9:00 AM, Kevin Van Workum wrote: Confused about the lion's share of VirtualGL users are no longer using vglclient. Does that apply to Cygwin/X only or all platforms? I hope you're not thinking of getting rid of vglclient. It was a clear statement. Few people are using vglclient.

[VirtualGL-Users] Exceed support

still using remote stereo with it, please let me know. I welcome any feedback on this proposal. DRC -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases

Re: [VirtualGL-Users] 32bit glxspheres on 2nd GPU very slow

It's also perfectly fair to file a support request with nVidia for this. I've encountered user reports that 32-bit apps are slow in VGL but 64-bit apps aren't, but in all cases it turned out to be because the user hadn't installed the 32-bit libraries for the nVidia drivers. However, in this

Re: [VirtualGL-Users] XDMCP does not work

I will investigate On 3/11/14 6:34 AM, Isamu Yamashita wrote: Hi folks, When I used newer turbovnc with the option -query to enable XDMCP, I got the following errors and Xvnc did not work normally. This issue happened in both 1.2.1 and 1.2.80. I have used 1.1 with XDMCP so far and have

Re: [VirtualGL-Users] Altair Hypermesh

flickering when painting the Hyperbeam window. Hypermesh 11.0 has no visual anomalies as far as I can see. 2014-02-27 19:59, DRC skrev: Altair is looking into it. Are the visual anomalies specific to a particular viewer? Do you, for instance, see them with both the Java and the native viewer

Re: [VirtualGL-Users] Altair Hypermesh

turbovnc viewer. I read hypermesh viewer... We are not using turbovnc. We use Cendio's thinlinc (version 4.0). Their tigervnc Xvnc support softare glx so if I run hypermesh without vglrun it works okay albeit slower. 2014-02-28 09:41, DRC skrev: You mean the native Windows viewer? Which

Re: [VirtualGL-Users] Altair Hypermesh

on RHEL6 x86_64. I am not at work right now so I can't check the exact version. As it works (mostly) okay with VirtualGL 2.3 but not with VirtualGL 2.3.3 (nor with 2.3.2) it looks to me like a regression in recent versions of VirtualGL. 2014-02-26 20:10, DRC skrev: What version of HyperMesh

Re: [VirtualGL-Users] Altair Hypermesh

What version of HyperMesh? Altair actively sells VirtualGL and TurboVNC as part of their grid service offering, so I know that it has been tested. The only possibility is that a new version came out that broke something, or perhaps there is something different about your environment. What

Re: [VirtualGL-Users] How to use libjpeg-turbo with Java Viewer

All of the packages I'm building for TurboVNC 1.3 (pre-release build) include the libjpeg-turbo libraries along with the Java viewer, so they are used automatically. Otherwise, with the 1.2 Java viewer, you have to just install the appropriate libjpeg-turbo binary package for your platform, and

Re: [VirtualGL-Users] voreen canvas always black when using virtualGL

the graphics of other 3D apps started with vglrun (e.g. itk-snap, even the instances started by other users) are effected (e.g. artefacts in the rendering, bg-color taken from the voreen canvas). Is that as expected or a bug in specific for voreen over virtualGL? On 31/01/14 22:02, DRC wrote: Moved

Re: [VirtualGL-Users] voreen canvas always black when using virtualGL

Moved the discussion temporarily to the voreen forum. Will update this list once a conclusion has been reached. On 1/31/14 6:50 AM, Dr. Roman Grothausmann wrote: On 31/01/14 04:02, DRC wrote: On 1/30/14 5:36 AM, Dr. Roman Grothausmann wrote: On 29/01/14 10:30, DRC wrote: The bug is easily

Re: [VirtualGL-Users] voreen canvas always black when using virtualGL

On 1/30/14 5:36 AM, Dr. Roman Grothausmann wrote: On 29/01/14 10:30, DRC wrote: The bug is easily reproducible. I am suspicious that it might have something to do with the application's use of FBO's, but I'm not entirely sure what the problem could be, as other apps that render to FBO's

Re: [VirtualGL-Users] voreen canvas always black when using virtualGL

I'll give it a try and see if I can reproduce it. Although compatibility problems are becoming more and more rare as VirtualGL matures, they still exist. Usually it's because the application is doing something that I haven't anticipated. On 1/27/14 6:49 AM, Dr. Roman Grothausmann wrote:

  1   2   3   4   >