rebuilding the code.
On 4/25/13 3:26 AM, Arthur Huillet wrote:
On Wed, 24 Apr 2013 16:08:45 -0500
DRC dcomman...@users.sourceforge.net wrote:
In my case, I built
xpra on RHEL 6 and got the following error when I tried to connect:
For what it's worth - there are RHEL 6 packages available
What option did you select in vglserver_config? What was the full
output of vglserver_config? Which version of the nVidia drivers do you
have installed?
vglserver_config installs a file under /etc/modprobe.d that is supposed
to set the permissions on /dev/nvidia*. If you haven't restarted
the clarification, I’ll definitely spend more time in
the manual. This is really helpful, I’ll take another stab at it.
Thanks again!
--
Desmond
On Wednesday, November 6, 2013 at 2:56 PM, DRC wrote:
Yes, you're missing quite a lot. Please read the manual. VirtualGL
needs two X
, 2014 at 11:53 AM, Kevin Van Workum wrote:
DRC was correct. You need a 3D X server, which is your Xorg X11
server. And you need a 2D server; either VNC or Xvfb, not both. If you
goal is to use Xvfb to capture images, then use Xvfb as the 2D server.
On Fri, Jan 10, 2014 at 1:53 PM, Stealthy
On 1/10/14 2:38 PM, Kevin Van Workum wrote:
Can you explain why you're using Xvfb? If you're just trying to make a
video of your 3D application with ffmpeg, can't you just get it from the
3D X server directly? For example:
ffmpeg -f x11grab -video_size cif -framerate 25 -i :0.0 /tmp/out.mpg
machine, this
will have to wait a while, until I have some other reason to change the card.
On Dec 23, 2013, at 10:15 AM, Tyson Whitehead twhiteh...@gmail.com wrote:
On December 21, 2013 03:03:25 DRC wrote:
By chance have you tried the latest code in subversion trunk? I think
this may
By chance have you tried the latest code in subversion trunk? I think
this may be another symptom of a bug I already fixed, but it was fixed
after the 2.3.3 release.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
We have a VNC + VirtualGL setup on machines with dual AMD FirePro V9800 ATI
I've never seen that before. Seems like it may be a driver bug.
On 12/20/13 2:40 PM, Tyson Whitehead wrote:
PS: One other big of strangeness I noticed was that under the single card
configuration all the tc visuals from DISPLAY=:0 glxinfo have id 0x0a3
81 GLX Visuals
...
0x0a3 32 tc 0
So I guess the limit is in vglclient. However 17 should be more than
enough.
On Thu, Dec 5, 2013 at 5:28 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
VirtualGL only opens one connection to :0 (or the specified 3D X server)
the first time
VirtualGL only opens one connection to :0 (or the specified 3D X server)
the first time XOpenDisplay() is called, and it reuses that same
connection for all subsequent 3D operations. Thus, VirtualGL is only 1
client from the 3D X server's point of view. I think Xorg can have a
max. of 256.
. Debian squeeze has gnome ver 2.30 wheezy gnome 3.4.
My workaround is that I don't use evolution now, but other email program
(kmail). I made this change a half year ago, but kmail still annoying me.
Mirek
On Friday, November 29, 2013 05:46:09 AM DRC wrote:
Never mind. I read the bug
/Documentation/Mesa
I substituted debian library with library compiled with x11 driver.
After this, evolution is doing similar like with VGL. It starts but crashes
after compose is selected.
Mirek
On Friday, November 29, 2013 05:50:19 PM DRC wrote:
TurboVNC works well with both 2D or 3D applications
Never mind. I read the bug report. Not sure why it's requiring GLX. As a
temporary workaround, you can enable Mesa in TightVNC using the instructions
here:
http://www.virtualgl.org/Documentation/Mesa
I will look into why Evolution isn't working in VGL, mainly because doing so
may reveal an
https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.2.1/
Significant changes since 1.2:
[1] Fixed two regressions introduced in TurboVNC 1.0, one of which
prevented older (RFB = 3.3) VNC clients from connecting successfully to
the TurboVNC Server and the other of which prevented
You can thank the sponsor of the technology. Yes, I anticipate it being
stable for 1.3, but since I don't personally use the feature, I am
relying on feedback from people who do, including the sponsor.
On 11/16/13 10:17 PM, Dyweni - VirtualGL-Users wrote:
-- The Java applet can now be
a newer version of X RANDR. That's a pretty major undertaking.
Such a feature seems like it is less useful now that you can dynamically
resize the server's desktop to any arbitrary geometry.
On 2/27/13 6:26 AM, DRC wrote:
Ah, yes, sorry for the confusion. The feature I'm describing is called
?
I did not manage to get the gnome fallback working, I will try a bit
more to understand what is wrong.
Thanks,
Julien
On Mon, Nov 11, 2013 at 5:55 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
Unfortunately, in Ubuntu 12.10, they removed Unity
) but none works. it
just bothers me i have no problems with other applications.
On 23/10/2013, DRC dcomman...@users.sourceforge.net wrote:
There is clearly something different about your system, then, because I
can run that application just fine with TigerVNC+VirtualGL (and with the
version
All of this becomes immensely more complicated when you start to factor
in Wayland, since all of the current remote display solutions are based
around X, and unfortunately, the Wayland developers seem to be taking
the position that remote display will take care of itself and that it
isn't
The application still only uses the CPU.
Am I missing something?
Thanks for the help btw.
--
Desmond
On Wednesday, November 6, 2013 at 12:47 PM, DRC wrote:
Trouble initializing VirtualGL with Xvfb tells me nothing. Please be
specific as to the error messages you are encountering or what
I suspect that it's some GPU-specific issue, as it does not occur with
an nVidia card. I have not had a chance to test it with my ATI adapter.
Be patient.
On 10/30/13 9:35 PM, GOliath Keet wrote:
I have a ATI 7850 with ati's current stable driver on ubuntu 13, same
problem existed for 12,
with fglrx driver. tried it with 2 different
graphics cards (one using fglrx other fglrx-legacy) but none works. it
just bothers me i have no problems with other applications.
On 23/10/2013, DRC dcomman...@users.sourceforge.net wrote:
There is clearly something different about your system
also been fixed by the same
patch.
On 9/26/13 2:59 PM, Rafael Guimaraes wrote:
Hi DRC,
I have just detected a strange behavior when using TurboVNC 1.2 client
as an applet. When I hold two mouse buttons simultaneously it doesn't
work as expected...
By using xev, I have checked that if I press
that if this was a bug in TurboVNC, someone else would have stumbled
upon it by now.
On 10/24/13 9:26 AM, Rafael Guimaraes wrote:
Hi DRC,
Just some last information... I have tried to telnet Xvnc (in ports 5813
and 5913, since I using display 13) in order to see if the Xvnc process
is completely
I guess I should have really learned by now to stop second guessing
myself. Upon further examination, the reason why the firstUpdate
mechanism is there is because there may be circumstances under which a
user leaves their 3D application running and then reconnects to the
TurboVNC Server
https://sourceforge.net/projects/virtualgl/files/VirtualGL/2.3.3/
Significant changes since 2.3.2:
[1]
VirtualGL will no longer throw an exception if a 3D application calls
certain X11 and GLX functions with a NULL argument. It will instead
allow the underlying X11 or GLX library to handle
This has been reproduced. It seems that LWJGL requires either the RANDR
extension or XFree86-VidModeExtension to be present in the 2D X server,
or it will barf. Since I'm in the process of adding X RANDR support to
TurboVNC, that will be the long-term solution for this, but in the near
term,
I know that VirtualGL has worked successfully with other Java 3D apps in
the past, but I haven't tested it in a long time. I'll see if I can
bring up a more simple 3D Java app and verify if there is a fundamental
issue in Java.
In the meantime, you might also want to try 'vglrun -ge', which
Try something more simple first, like WGLspheres
(http://www.virtualgl.org/wglspheres.zip). WGLspheres will print out
the OpenGL renderer, which should say Chromium if the 3D Guest
Additions are working properly.
Unfortunately, it is entirely possible that WGLspheres will work fine
but the
:55 PM, Nathan Kidd wrote:
On 10/07/2013 05:32 PM, DRC wrote:
On 10/7/13 3:56 PM, Karthikeyan Balu wrote:
I’m not sure whether their drivers support access from Virtual display
servers ? and I guess TurboVNC being able to simulate these inputs comes
next. Any experience.
3DConnexion
,
you'll have to build from source if you want to try it out.
On 10/4/13 4:24 PM, Kevin Van Workum wrote:
OK, that makes sense. But then why do I get that 1 initial refresh?
On Fri, Oct 4, 2013 at 5:08 PM, DRC dcomman...@users.sourceforge.net wrote:
The default is for ALR to affect only
The default is for ALR to affect only PutImage operations, which is what VGL
uses to draw images. Many 2D apps use other methods to draw images, like X
Render or CopyArea, that won't be subject to ALR unless you set TVNC_ALRALL.
The docs go into more detail. ALR is really targeted at 3D apps.
. But then why do I get that 1 initial refresh?
On Fri, Oct 4, 2013 at 5:08 PM, DRC dcomman...@users.sourceforge.net wrote:
The default is for ALR to affect only PutImage operations, which is what VGL
uses to draw images. Many 2D apps use other methods to draw images, like X
Render or CopyArea
:(1781,872),
mode NotifyUngrab, detail NotifyInferior, same_screen YES,
focus YES, state 0
2013/9/26 Rafael Guimaraes rgu...@gmail.com mailto:rgu...@gmail.com
Hi DRC,
I have just detected a strange behavior when using TurboVNC 1.2
client as an applet. When I hold two mouse
I have heard from at least one person that it is possible, but I have
not personally tried it. I'm not sure why you bothered with all the
help wanted ads. All you had to do was e-mail me. I'm the guy who
founded the VirtualGL Project, has been solely maintaining it for 10
years, and has
Yeah, but a single high-end GPU is going to render OpenGL faster than
all of the 200-some-odd cores in your cluster combined. Seems like a
good trade-off to me.
On 9/19/13 1:27 PM, Amanda Tumminello wrote:
I am currently working in a blade server environment. It consists of 13
blades with
.
On Wed, Sep 18, 2013 at 10:52 PM, DRC
dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
Neat trick. :)
I don't think that the issue you're seeing has anything to do
with VGL
per se. I think it's how your X server
I've just put out a new pre-release of TurboVNC
(http://virtualgl.sourceforge.net/vnc.nightly.13) that gives a sneak
preview of one of the biggest changes in TurboVNC 1.3:
Retiring the X11 viewer
---
It has been decided to get rid of the X11 viewer, although it will still
Neat trick. :)
I don't think that the issue you're seeing has anything to do with VGL
per se. I think it's how your X server is configured. $gpu in your
examples below refers to an X screen number. Typically, in a VirtualGL
multi-GPU environment, one would configure the X server such that
I'm not sure I totally understand. If the TurboVNC server is issuing
the calls in the correct order, then how would changing something within
the TurboVNC server work around the issue? Can you be more specific
about what xdotool is doing? An output from xev would help.
On 9/3/13 12:38 PM,
:
FYI
While waiting for confirmation, I tested another VNC client called
'bVNC Free - Secure VNC Viewer' and that works just fine! Looks like a
VNC Client issue to me.
---
Thanks,
Dyweni
On 2013-08-27 11:48, DRC wrote:
Yes.
On 8/27/13 11:08 AM, Dyweni - VirtualGL-Users wrote:
I have
No idea what's causing the beeps, but both the Java and Windows native
viewers have an option to disable transmission of them from server to
client. Look in the Options dialog.
On 8/27/13 3:07 PM, Dyweni - VirtualGL-Users wrote:
Hi,
Ever since I started running Eve Online/Wine inside of
.el6.x86_64 does not work ( vglrun /bin/ls
-l / hangs )
I have no other versions to try.
-hiroto
On Fri, Aug 16, 2013 at 11:28 PM, DRC dcomman...@users.sourceforge.net
wrote:
Disabling SELinux is definitely the first step, but in some cases, you
also have to do:
attr -S -g selinux /usr
On 8/22/13 10:04 AM, John Clyne wrote:
The Quadro 2000, and I think the 550, are based on the older Fermi
architecture. I wanted to get confirmation that ViritualGL was supporting the
newer Kepler based products. I would think Kepler-Quadro would be supported,
but the Tesla cards target
=0x01c2 ) 0.483990 ms
[VGL] ) 1.422030 ms
gnome-session-is-accelerated: No GLX_EXT_texture_from_pixmap support.
[VGL] XCloseDisplay (dpy=0x09072348(:20) ) 0.294950 ms
gnome-session-check-accelerated: Helper exited with code 256
Thanks so much for your time.
On 8/17/2013 12:03 AM, DRC
Install the proprietary Catalyst (fglrx) drivers from ATI/AMD. We don't
currently support Mesa. There generally isn't much impetus to do so,
because if you're using software rendering, you might as well use Mesa
directly-- either through the built-in version that TigerVNC supplies
via its
I can personally attest that TurboVNC does work on ARM Linux, both
client and server, but you have to build it (and libjpeg-turbo) from
source. I have tested TurboVNC on a Panda board with Ubuntu, but if you
run into any problems, please file a bug report. My philosophy behind
supplying
the response =]
Thanks,
John
On Sat, Jul 20, 2013 at 2:16 AM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
I suspect that it may be the same bug as is reported here:
https://sourceforge.net/tracker/?func=detailaid=3606409group_id=117509atid
I suspect that it may be the same bug as is reported here:
https://sourceforge.net/tracker/?func=detailaid=3606409group_id=117509atid=678327
Thanks to the sponsored project I've been working on in recent weeks to
make compiz run in VirtualGL, I now have a recent-ish Ubuntu environment
set up
package builder but with the nightly sources.
Cheers
On Sat, Jul 20, 2013 at 2:16 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman...@users.sourceforge.net wrote:
I don't think their nightly is pulling the latest code from SVN, so
it probably doesn't contain the fixes. I know
Should be fixed in trunk and branches/1.2.x. The viewer now disables
the keystroke buttons whenever view-only mode is selected on the viewer
side. If view-only mode is selected on the server side instead, then
the viewer won't know about it. In that case, the buttons will still be
visible,
The SecurityTypes option can only be used to control a VeNCrypt-compatible
server like TigerVNC. TurboVNC doesn't currently support session encryption, so
encryption=None will always be the case when connecting to TurboVNC servers.
You can use the auth config file to restrict the available auth
xwd also (more old school solution.) TurboVNC is an X server, so any tool that
can capture an X screenshot should work. You can also of course grab the image
on the client side using any number of different tools.
On Jun 28, 2013, at 2:40 PM, Kevin Van Workum v...@sabalcore.com wrote:
I was
Does enabling PBOs make any difference?
On 6/17/13 2:02 AM, Arthur HUILLET wrote:
On Mon, Jun 17, 2013 at 11:30:34AM +1000, Paul McIntosh wrote:
Ok - here is the data for a Tesla M2070 and M2070Q (Quadro)
There is a big difference between the Quadro and non-Quadro. Looks like the
read rate
On 6/15/13 11:13 AM, Paul Melis wrote:
I've done some similar tests, mostly at 3840x2160 over a 10G link. I
seemed to hit a bottleneck of about 10 fps, but so far assumed it was
the readback from the GPU that was the problem (GTX680 in a PCI Express
x16 slot), judging from the vglrun +pr
in full
res, but only a portion, is the out of view portion not sent?
The point James just made is also something I need to try, I forgot to look
if the ssh daemon was maxing out! And I should test with it without any
tunnel at all.
Cheers,
Paul
- Original Message -
From: DRC
representative of how it might
act on a real display. It appears the answer is yes - so I'll test with that
and see what I can come up with.
I'll post some results.
Cheers,
Paul
- Original Message -
From: DRC dcomman...@users.sourceforge.net
To: virtualgl-users@lists.sourceforge.net
, 2013 at 12:50:01PM -0500, DRC wrote:
I dunno about that. My modest Quadro 600 can read back about a
gigapixel/second. I don't think that's likely to ever be the bottleneck
on a reasonably modern system.
I have seen some slides that suggest that nVidia cripples the readback
performance
glreadtest in the VirtualGL source.
On Jun 15, 2013, at 7:22 PM, Vadim Peretokin vpereto...@gmail.com wrote:
I have a GTX 560 that I could run a test on, if there are any easily
available and anyone wants to look at the number.
Bigger pipes will definitely help, up to a point. The compression ratio
you can get will vary a lot depending on the types of images that the
app is generating. I use GLXspheres as a sort of middle-of-the-road
approximation, since it has a realistic proportion of solid color and
smooth
CC'ing the TigerVNC lists, since this may also interest some of those
users/developers.
I believe that the latest pre-release of VirtualGL
(http://virtualgl.sourceforge.net/vgl.nightly/) should (with emphasis on
should) allow you to run compiz or other 3D WM's with hardware
acceleration.
vnc server and that the -fps option
was already addressing the over-the-wire lag issue.
---
Thanks,
Dyweni
On 2013-06-04 17:27, DRC wrote:
On 6/4/13 3:16 PM, Dyweni - VirtualGL-Users wrote:
You are correct. Running vglrun with '-sp -fps 60' limits the 3D
rendering rate as you described
On 6/4/13 8:51 PM, Nathan Kidd wrote:
Is there a reason for -fps to not automatically enable -sp?
I'm not thinking of any use case for -fps apart from -sp; as you've
said, in the typical use case of wanting to rate-limit your
app/bandwidth you always need -sp.
Not true. VGL_FPS was
(60) of the Emulated
Monitor Refresh Rate setting.
---
Thanks,
Dyweni
On 2013-06-04 15:16, Dyweni - VirtualGL-Users wrote:
Hi DRC,
You are correct. Running vglrun with '-sp -fps 60' limits the 3D
rendering rate as you described. The 3D rendering rate follows the -fps
value. I didn't
Dyweni,
I await your response on this before I proceed any further. I need to
resolve the matter of whether you simply forgot to disable frame
spoiling (which is what I suspect, since your previous messages made no
mention of using the -sp switch to vglrun or setting VGL_SPOIL to 0) or
quite plainly multiple times that it would?
I have another patch coming soon that implements GLX_SGI_swap_control /
glXSwapIntervalSGI and perfects the delay within glXSwapBuffers.
---
Thanks,
Dyweni
On 2013-06-04 14:13, DRC wrote:
Dyweni,
I await your response on this before I proceed
patch for your review / feedback. Any feedback
would be great.
---
Thanks,
Dyweni
On 2013-06-02 23:36, DRC wrote:
But you didn't answer my question. Why can't you achieve the same
effect by setting VGL_FPS and disabling frame spoiling? The reason why
frame spoiling exists is to make 3D
solves a problem
that couldn't be solved by using VGL_FPS with frame spoiling disabled.
On Jun 2, 2013, at 3:58 PM, Dyweni - VirtualGL-Users t7nhgfds7...@dyweni.com
wrote:
Hi DRC/All,
I have mucked around with the VirtualGL 2.3.2 code and have come up with a
solution that seems to work well
On 5/30/13 2:49 PM, Jay Ashworth wrote:
When I upgraded them to SuSE 12.1, the replacement Xvnc from the new Tight
package wouldn't accept mouseclicks, so I again copied in the older one,
and *it*, in its turn, wouldn't allow drag and drop, though everything
else seemed to work ok. They lived
Thanks. I'll get this integrated into 1.2.
On 5/21/13 7:56 AM, Kevin Van Workum wrote:
Specifying a desktopName in a config file (turbovncserver.conf) has no
effect.
Simple fix:
*** vncserver.in http://vncserver.in2013-05-14
09:58:51.641671306 -0400
--- vncserver.in.b
On 5/13/13 8:41 AM, First Last wrote:
actualy it's what I did, make xserver-install ( when I wrote the mail
I was almost asleep...) so to be clear make xserver-install didn't
install vncpasswd.
'make install' installs vncpasswd and vncconnect. 'make
xserver-install' installs Xvnc. You have
On 5/13/13 12:57 PM, First Last wrote:
well, if you want, I can make a partition with archlinux and giving to
you an ssh access sometime. I could either do some tests for you and
send logs. I cannot be too much involved, I cannot code or debuging
because I try to be hired by a gsoc project.
There was an issue that was making the TurboVNC server crash on startup
when using recent systems, such as Fedora 18 or Ubuntu 13.04. You might
be running into that same issue. Can you try building the code from
https://virtualgl.svn.sourceforge.net/svnroot/virtualgl/vnc/branches/1.3.x
in
to
determine success of the connection on the server side. Maybe you could
keep the asynchronous behavior default and just add a -sync option to
request a synchronous connect instead? Either way.
On Fri, May 10, 2013 at 4:05 PM, DRC dcomman...@users.sourceforge.net
mailto:dcomman
On 5/12/13 11:31 PM, First Last wrote:
you mean 1.2.x right ? because I can't get 1.3.x
anyway, I compiled (after a change in FindTurboJPEG.cmake) the server
and the client I got (1.2.x).
Yes, sorry. I meant 1.2.x. Too many releases going on at once
(libjpeg-turbo is about to be released as
Please submit all bug reports to me no later than Wednesday 5/15 (or
remind me if I haven't fixed something yet.)
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to
On 5/7/13 2:32 PM, Kevin Van Workum wrote:
When running the java viewer in listen mode with loglevel=100, if the
vncserver is killed, an exception is thrown in the java viewer. The
viewer window also remains open. Not really a bug though but would be
nice if the viewer window would close on
On 5/7/13 5:57 PM, Damon Catling wrote:
I have no idea weather Nvidia and Valve already have their own remote 3D
solutions for Linux similar to VirtualGL, but if not, perhaps VirtualGL
would be attractive to companies of that ilk?
Valve, possibly. nVidia has their own solution called VGX,
On many platforms, the 32-bit compiler infrastructure is in a set of
extra packages that aren't installed by default. Make sure that you can
successfully compile a 32-bit app using -m32 (Hello, world or
whatever.) The VirtualGL build system enables either 32-bit or 64-bit
based on the value
it in a multi-card
environment, so others on the list may be able to provide a better answer.
DRC
On 4/26/13 2:28 PM, Kevin Van Workum wrote:
I know how to setup two graphics cards with a single x-server with two
screens (one screen for each card) and address them via VGL_DISPLAY. But
I'm
On 4/24/13 9:16 PM, Yusen Li wrote:
encoding is excellent for video games and the Turbor VNC or TigerVNC is
not good at games. I also suggested TigerVNC group to add the video
encoding techniques (such as x264) to TigerVNC. But they told me they
don't want to do that since the encoding is just
Well, I actually tried to get xpra up and running. No luck. It seems
to be a somewhat unpolished solution. The X proxy we support is
TurboVNC, so I would suggest that as an alternative.
On 4/20/13 9:32 PM, Yusen Li wrote:
I use Xpra to run applications remotely and it works fine for 2D
No, VirtualGL does everything through the X server. This sounds like more of a
driver thing. Not sure what it would speed up in our case. Pixel readback is
already hundreds or even 1000+ Megapixels/sec on modern hardware. That's not
even close to being a bottleneck when compared to compression
On 3/24/13 7:20 PM, First Last wrote:
I was busy last days... anyway I got turbovnc from AUR repo (archlinux)
now everything works fine. But I think there is a problem with make
install from the sources codes, because it's not normal that vncserver
wasn't where I expect, and I didn't mess with
is now available at:
https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.1.95%20%281.2rc%29/
There were enough issues discovered with the Java viewer that I felt it
prudent to give the community another pass at testing it before the
final release is issued. All remaining issues that
On 3/18/13 11:07 AM, First Last wrote:
I think I have to clarify some points...
1) I started by doing step by step what is in the user guide. But as
long as I using an headless computer, the user guide doesn't help me
straight forward. I took a look in the mailling list, and in google of
On 3/18/13 3:44 PM, First Last wrote:
it's working!
I don't understand why nomachine is working... because by default in
/etc/ssh/sshd_config
forwarding are disabled...
so I enabled these,
AllowAgentForwarding yes
AllowTcpForwarding yes
X11Forwarding yes
NX doesn't rely
OK, let me attempt to explain this, and I want to re-emphasize that most
of this is in the User's Guide.
1) how can I start a Xserver display by ssh ? I don't have a screen connected
to the PC I can only ssh it...
[root ~]# xdpyinfo -display :0
return,
xdpyinfo: unable to open display
I suspect that this has nothing to do with Mesa and is probably due to
your compression settings. If you are on a slow network, try using the
Tight + Medium Quality JPEG preset in TurboVNC. TigerVNC uses lower
quality JPEG by default, whereas TurboVNC uses high-quality JPEG by
default, so
So you adjusted the compression settings and it had no effect? What
about trying the TurboVNC 1.2 beta server/viewer and enabling interframe
comparison (see User's Guide)?
If you're using the official 1.2 builds of TigerVNC, which I put
together when I was still with the project, then those
On 3/7/13 5:36 PM, James Wettenhall wrote:
Why can't you use VirtualGL? The Chimera page clearly says that they
recommend vendor-supplied graphics drivers, which VirtualGL would
enable you to use.
Our impression was that VIrtualGL only works with GPUs. We are still waiting
for access to
the use of regular font paths.
DRC
On 3/2/13 7:38 PM, James Wettenhall wrote:
Hi,
I've noticed some font problems since switching from TigerVNC Server to
TurboVNC Server (with Mesa) - on certain applications, the fonts are
difficult to read.
I haven't been manually specifying a font path - just
It's a CMake variable. I am not in front of my computer, but I think
BUILDING.txt describes its usage.
On Mar 2, 2013, at 6:21 AM, James Wettenhall james.wettenh...@monash.edu
wrote:
Hi,
I'm trying to build TurboVNC 1.1.91 with libjpeg-turbo 1.2.90 on Linux using
non-standard
If it's still doing that in the latest code, then it's a bug. Can you
provide more details on how to repro it?
On 3/2/13 9:18 AM, Kevin Van Workum wrote:
I had a similar issue. cmake would pick up the correct path, but when it
did the test for usability, cmake did not use the path when
is available, primarily fixing a handful of issues with the Java viewer,
most of them related to key mapping. The Java viewer should now
properly handle AltGr on international keyboards, and it now
differentiates between left and right modifier keys (Alt, Ctrl, etc.)
and between the keypad
Viewer,
so I'm confident that if our Java viewer can hit that same baseline,
we're golden.
On 2/26/13 8:16 PM, DRC wrote:
For curiosity, I ported the benchmarking system from the TurboVNC Viewer
into the TigerVNC native (FLTK) Viewer. This was partly done to get a
better idea of how the new
My understanding is that since we're using multiple dialogs and frames
and doing other fanciness (scaling, full-screen mode, etc.), it would
minimally be very difficult to support an embedded applet solution.
Brian, correct me if I'm wrong. The goal was to make the new Java
viewer behave as
Uh, what do you mean a working example? If you're on Mac, it does so
automatically (the JNI library is embedded in the app.) For other
platforms, install 1.3 beta of the libjpeg-turbo SDK
(https://sourceforge.net/projects/libjpeg-turbo/files/1.2.90%20%281.3beta1%29/),
and the new Java
One other thing to note regarding the new viewer is that I don't think
it currently works without being a signed applet. It would be feasible
to make it run in an unsigned environment, but of course some of the
functionality wouldn't be there.
On 2/26/13 3:23 PM, DRC wrote:
My understanding
.
I'll be doing similar comparisons with the Windows Viewer over the next
couple of months and will keep everyone posted on that.
If anyone wants to peer review this work, I'm happy to provide the
TigerVNC patches that implement the benchmark functionality.
DRC
101 - 200 of 385 matches
Mail list logo
