I can definitely appreciate the pre-install aspect of it, but
unfortunately unless you're using a bleeding-edge distro, the
pre-installed versions of TigerVNC tend to be quite old. RHEL 6, for
instance, is still using TigerVNC 1.1.0, and RHEL 7 is using an alpha
pre-release version of TigerVNC 1.3 (WTF?!)
There is basically no community support for those distribution-supplied
versions, unless (as in this case) the issue also exists in the latest &
greatest version of TigerVNC. Otherwise, you have to go through Red Hat
for support, and there is just quite a lot in those old TigerVNC
releases that's broken. Also, Red Hat no longer has an active developer
in the TigerVNC Project, so it's unclear to me how they are feeding
fixes back into the project.
You can install TurboVNC as non-root as follows:
mkdir ~/turbovnc
rpm2cpio {TurboVNC RPM} | cpio -idv
Now you can start the server by running
~/turbovnc/opt/TurboVNC/bin/vncserver
I am rabidly committed to making TurboVNC as stable and performant as I
can, so please do continue to let me know of any issues you encounter,
and I'll do my best to resolve them. However, unless a Turbo/Tiger
interaction issue proves to be something I can fix in my code, there may
not be much I can do about it.
On 10/19/15 10:59 AM, Brett Williams wrote:
> DRC,
>
> My main reason for using TigerVNC server is that is what is installed,
> and the deployment I'm going to be testing for shortly does not have the
> TurboVNC server installed. I won't have root access at that point, so
> in order to get TurboVNC server installed I'll have to make a case for
> them doing it for me.
>
> I'll work the next couple of days with the TurboVNC server and report
> back (I've still got a machine I can do it on).
>
> On Sat, Oct 17, 2015 at 12:09 PM, DRC <[email protected]
> <mailto:[email protected]>> wrote:
>
> FYI-- you can read more here:
>
> https://github.com/libjpeg-turbo/libjpeg-turbo/pull/27
>
> but I'm convinced that this is something that needs to be addressed
> within TigerVNC, not within libjpeg-turbo. TigerVNC is using its own
> custom destination manager for the libjpeg API, which is why this only
> affects their server and not the TurboVNC Server or other VNC
> implementations that use libjpeg-turbo. The issue is definitely
> server-side-- i.e. the server is generating a bad JPEG image. Unknown
> why the TigerVNC Viewer is unaffected, but probably it's because that
> viewer can't select JPEG quality 95. The issue seems to relate to the
> size of the generated JPEG image, which is a function of both the source
> image and the JPEG quality.
>
> Pierre proposed a patch to libjpeg-turbo that does work around the
> issue, but it changes the behavior of the libjpeg API in a way that it
> is incompatible with libjpeg, so I am disinclined to accept that patch.
> I have verified that this issue also exists when TigerVNC is built
> with libjpeg. I don't doubt that this issue stems from a "quirk" in
> libjpeg, but the fact of the matter is that the quirks in the libjpeg
> API are now somewhat canonical, since that API has been virtually
> unchanged since 1998. libjpeg v8 introduced in-memory
> source/destination managers as a way of making it easier for
> applications such as TigerVNC to do compression to/decompression from
> memory buffers without having to deal with these canonical quirks.
>
> On a side note, I'm curious as to why you can't use the TurboVNC Server.
> We are fastly approaching feature parity with the TigerVNC Server.
> Our latest builds have TLS encryption support, so really the only major
> feature we're now missing is Xinerama support (which is forthcoming--
> probably will be in TurboVNC 2.1.)
>
>
> On 10/13/15 6:00 PM, Brett Williams wrote:
> > Bug filed:
> >
> >https://github.com/TigerVNC/tigervnc/issues/218
> >
> > I am not sure how much context to include.
> >
> > On Tue, Oct 13, 2015 at 4:32 PM, Brian Hinz
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Would you mind filing a bug report on the TigerVNC github tracker so
> > that we can follow up on it there? And since that image looks like
> > an ASIC layout, can you tell me what application triggers it so I
> > can try to reproduce (you can email me off list if you want).
> >
> > Thanks,
> > -brian
> >
> > On Tue, Oct 13, 2015 at 6:20 PM, Brett Williams wrote:
> >
> > I've been unable to reproduce the problem using the TurboVNC
> server.
> >
> > On Tue, Oct 13, 2015 at 3:05 PM, DRC wrote:
> >
> > OK, well the image is definitely corrupt, meaning that this
> > is a server-side issue. Is there any way you can try to
> > reproduce the issue using the TurboVNC 2.0 server? Building
> > the TigerVNC Server isn't exactly straightforward, so in
> > order for me to send you an instrumented binary with the
> > afore-mentioned codec checks, I'm going to have to do that
> > using our server code.
> >
> > It may also be that there is simply a rare bug in the
> > TigerVNC encoder that doesn't affect the TurboVNC Server.
------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
