On 10/20/15 1:41 AM, Brett Williams wrote: > First, cut and paste does not consistently work (at least on the mac). > Much of the time it works as expected, and then sometimes it doesn't > work at all. I use various workarounds (formatted text doesn't seem to > work at all when copied on the mac and trying to paste into the VNC > session). Sometimes I'm left with no alternative but to use an OSX > terminal, ssh in, and cut and paste there. I work with long file paths > and long filenames so typing them is inconvenient. I may not have this > set up correctly as I am running a separate vncconfig. There are a lot > of possible ways to attempt this and I haven't tried anything different > when using the TurboVNC server. This is definitely the most noticeable > impact to my productivity.
I don't think the formatting of text in word processors, etc., is ever going to transfer via RFB. However, the text itself should still transfer. Brian, do you think this could be related to https://github.com/TigerVNC/tigervnc/issues/20 ?? My guess is that this may be because we're still using the old code that encodes the clipboard as UTF-8, and because this is not kosher in the RFB world, it's causing problems. Or maybe some applications you're using need the clipboard to be transferred as something other than UTF-8 or ISO8859-1. Our version of vncconfig should work identically to the one in TigerVNC. The only real difference is that ours doesn't have a GUI. But there could be a bug in our implementation as well. If you can nail down specific applications that are causing problems moreso than others, or if you can ascertain whether this issue is specific to one particular flavor of vncconfig, that would be helpful in diagnosing. I've seen clipboard-related issues recently as well, but as you observed, they seem to be intermittent. I've been swamped with work lately, so I was trying to project an SEP field (https://en.wikipedia.org/wiki/Somebody_else%27s_problem) and convince myself that I was imagining things and that there wasn't really a bug. Any information you can provide to help reproduce this consistently would be very helpful. > Second, the way scrollbars are implemented is not ideal, with an > unnecessary vertical scrollbar. At work, I have what amounts to a > 3840x1080 display. At home, I have 1920x1200. So scroll bars appear > when I'm at home because I can only see half of the X width. > Unfortunately, vertical scroll bars are put on. This means I can't see > the full vertical space, even though I actually have 120 more pixels of > monitor at home (it's left blank and grey in full screen mode). That has to do with the viewer's window sizing logic. For me, it happens when I first connect, but then if I maximize the viewer window, the vertical scrollbar goes away. But then it exposes another bug I just noticed whereby the desktop is not offset properly within the window (that bug seems to only occur in Java 6 on my Mac.) Ugh. I'll investigate further. This stuff really seems like a bad game of whack-a-mole sometimes. > Third -- is there a way to stop the viewer from grabbing the Alt > modifier? I use Alt+left mouse click to move windows in the VNC > session, and Alt+right mouse click to resize. Sometimes (not every > time), instead this causes the viewer to start resizing, which is > strange because I'm in full screen mode. I don't understand. Can you provide a more specific reproduction procedure? Our viewer doesn't grab any keys on Mac at all. Keyboard grabbing is only implemented currently in the Java viewer running under X11 (which requires the use of the TurboVNC Helper native library, so for most purposes, the feature is only available when launching the viewer as a standalone application using the vncviewer script, not when using it through JWS or as an applet.) Keyboard grabbing is also implemented in the Windows native viewer (but not in the Java viewer on Windows-- yet.) I just tested, and Alt-drag works fine for me with the Mac viewer. > So far TurboVNC as server has been as good as any that I have tried, but > I do have the three above issues. > > On Tue, Oct 20, 2015 at 12:10 AM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > > <mailto:[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]>> > > <mailto:[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] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
