Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
I believe I've discovered a problem with the VNC protocol, related to changing the pixel format on the fly. Take a look at this chart: FUR=FramebufferUpdateRequest FU=FramebufferUpdate SPF=SetPixelFormat Client Server -- FUR sent

Re: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Tue, 21 Dec 2004, Peter Estrand wrote: I believe I've discovered a problem with the VNC protocol, related to changing the pixel format on the fly. Take a look at this chart: As I understand it, the same problem exists with the TightVNC 1.2.9 Windows viewer, if you change the pixelformat

RE: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Wed, 22 Dec 2004, James Weatherall wrote: The problem in your diagram is that the server for some reason sends a second unsolicited Framebuffer Update, without waiting for a request from the viewer. Yes, this is a FU from TightVNCs deferred updates. No RFB-compliant server will ever

RE: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Wed, 22 Dec 2004, James Weatherall wrote: From the RFB Protocol Document, Section 2 Display Protocol: The update protocol is demand-driven by the client. That is, an update is only sent from the server to the client in response to an explicit request from the client. Thanks.

RE: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Wed, 22 Dec 2004, James Weatherall wrote: Support for local cursor rendering is not unique to TightVNC, it's a feature provided as standard as part of VNC 4. Yes, but the VNC4 implementation is different. If I understand the code correctly, it takes care not to send unsolicited FUs. For

RE: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Wed, 22 Dec 2004, James Weatherall wrote: It shows that Xvnc from TightVNC 1.2.9 sends a cursor update as soon as it happens, without taking care to put it into the next FU. You wrote: In sprite.c, we have: pPriv-DisplayCursor = pScreen-DisplayCursor; ...

RE: Changing pixelformat on the fly

2004-12-22 Thread Peter Åstrand
On Wed, 22 Dec 2004, James Weatherall wrote: Yes, a fix would be nice, but as I said, we'll need to deal with buggy 1.2.9 servers anyway. So, my plan is to disable pixel formats change on the fly, if the RFB version is = 3.7. Since the bug is only in TightVNC, and since TightVNC

RE: Changing pixelformat on the fly

2004-12-27 Thread Peter Åstrand
On Thu, 23 Dec 2004, James Weatherall wrote: I'm not talking about the Tight encoding, I'm talking about the other Tight protocol messages. The problem is *NOT* local cursor support. Local cursor rendering works fine if implemented as specified in the RFB protocol document. The problem is

RE: Changing pixelformat on the fly

2004-12-27 Thread Peter Åstrand
On Mon, 27 Dec 2004, James Weatherall wrote: OK, sounds like the security type isn't much use. Exactly. It seems you have two options: 1. Use the encoding types of the first update rectangles - if AutoSelect is set then presumably Tight will be the initially preferred encoding, and

RE: Changing pixelformat on the fly

2004-12-28 Thread Peter Åstrand
On Mon, 27 Dec 2004, James Weatherall wrote: I think both these solutions are ugly. Both of these solutions assume that the bug isn't present in most servers (which it isn't) and therefore treat the case of a buged server as an exception. I think it's safe to assume that TightVNC users

Xvnc with RENDER - almost working

2005-02-23 Thread Peter Åstrand
I'm attaching two patches that adds RENDER support to Xvnc in Fedora 3. It works, except that I've found a small glitch when using the menus in OpenOffice: Sometimes, some of the menu choices disappears. See screenshot at http://www.cendio.se/~peter/vnc-render-oo.png. I've verified this

Re: Xvnc with RENDER - almost working

2005-03-10 Thread Peter Åstrand
On Wed, 9 Mar 2005, Alan Hourihane wrote: Have you tried xf4vnc's vnc.so or Xvnc ?? Now I have. Does that work for you as it has RENDER support, and I don't believe seeing troubles with it. Yes, it works. I cannot reproduce the OO problem with this version. I've noticed that your sources

Re: Xvnc with RENDER - almost working

2005-03-10 Thread Peter Åstrand
On Thu, 10 Mar 2005, Alan Hourihane wrote: Have you tried xf4vnc's vnc.so or Xvnc ?? Does that work for you as it has RENDER support, and I don't believe seeing troubles with it. Yes, it works. I cannot reproduce the OO problem with this version. I've noticed that your sources contains

Re: Xvnc with RENDER - almost working

2005-03-16 Thread Peter Åstrand
On Wed, 16 Mar 2005, Tim Waugh wrote: I am using your patch for render support in the Fedora Core development RPM package of vnc, and it works quite well so far. There are display glitches with it though. Occasionally, when switching windows, some horizontal bar-shaped areas are not redrawn

Re: Xvnc with RENDER - almost working

2005-03-31 Thread Peter Åstrand
On Wed, 16 Mar 2005, Tim Waugh wrote: I am using your patch for render support in the Fedora Core development RPM package of vnc, and it works quite well so far. There are display glitches with it though. Occasionally, when switching windows, some horizontal bar-shaped areas are not redrawn

Re: Xvnc with RENDER - almost working

2005-03-31 Thread Peter Åstrand
On Thu, 31 Mar 2005, Tim Waugh wrote: I've been able to reproduce this problem now. For me, it only happens in the GNOME environment, not in KDE. Xvnc gives error messages like: if ((xDst 0) || (yDst 0)) return; Well, that removes the 'striping' effect, but instead just large

Xvnc OpenGL troubles with -depth 16

2005-06-21 Thread Peter Åstrand
I've tried building Xvnc with OpenGL/GLX support. I'm using RealVNC 4.1.1, Xorg 6.8.2 and the Fedora Core 4 RPM sources. I'm using the fb framebuffer; not cfb. By setting BuildGlxExt YES in vnc.def, Xvnc is built with GLX support. With -depth 24, everything is working. With -depth 16, however,

Clipboard fails with non-ascii chars

2005-06-27 Thread Peter Åstrand
The clipboard implementation in the Windows vncviewer does not handle non-ascii characters. This is true for the 4.0 and 4.1.1 version. This is because non-ascii chars are explicitly removed. Why? The patch below restores the vncviewer3 behaviour and solves our problem (cut and paste with

Re: TightVNC, XVnc Solaris 9

2005-07-01 Thread Peter Åstrand
Furthermore, what's the status of OpenGL support in TightVNC's server? The The TightVNC 1.5 development server supports OpenGL, at least if you are using X.Org 6.8.2. I did some enhancements last week which improved things a lot. All glean tests except one passes. The Java3D example

Re: VNC-List digest, Vol 1 #1969 - 21 msgs

2006-12-14 Thread Peter Åstrand
How can I get old versions of realvnc source? All versions since 4.0 are available from the TightVNC Subversion repository, see http://vnc-tight.svn.sourceforge.net/viewvc/vnc-tight/vendor/realvnc/. Regards, --- Peter Cstrand ThinLinc Chief Developer Cendio AB

Re: GLX support

2006-12-14 Thread Peter Åstrand
Everyone seems to be asking about this but I haven't seen a definitive answer so I thought I would try again. So I have the source for vnc 4.1 (and the source for tightvnc 1.2.9, and 1.3.8) and the source for XFree86. I am on an SGI and have libGcore.o libGL.o, libGw.o in /usr/lib. The

Re: pixel format is out of sync, after refreshing and suddenly changing pixel format

2007-12-12 Thread Peter Åstrand
At a glance, this looks like the same problem I had a few years ago. See the thread http://article.gmane.org/gmane.network.vnc.user/18430. (Click on the subject). Best regards, Peter Cstrand On Wed, 12 Dec 2007, Anon Sricharoenchai wrote: Hi, I'm not sure to call this a bug in vncviewer,

Protocol extension for changing desktop name on the fly

2008-01-03 Thread Peter Åstrand
I'd like to be able to change the desktop name on the fly so that a vncconfig -set desktop=something immediately changes the vncviewer window title. Currently, the desktop name (as specified by the -desktop option to Xvnc) remains static during the entire lifespan of the Xvnc process. If you

Re: Protocol extension for changing desktop name on the fly

2008-01-07 Thread Peter Åstrand
I have a working implementation now, using a new pseudo encoding called DesktopName. It's pretty similiar to the existing DesktopSize encoding. However, it seems like RealVNC will not allocate an encoding number for my new encoding. There position was that this should be a TightVNC-specific

RE: Protocol extension for changing desktop name on the fly

2008-01-07 Thread Peter Åstrand
On Mon, 7 Jan 2008, James Weatherall wrote: You may wish to check your email - you were allocated pseudo-encoding number -307 earlier this afternoon. This is excellent news. Thank you for your cooperation. Rgds, --- Peter Cstrand ThinLinc Chief Developer Cendio AB

Re: Protocol extension for changing desktop name on the fly

2008-01-07 Thread Peter Åstrand
On Mon, 7 Jan 2008, Peter Rosin wrote: A client which requests the DesktopName pseudo-encoding is declaring that it is capable of coping with a change of the desktop name. The server changes the desktop name by sending a pseudo-rectangle with the DesktopName pseudo-encoding in an update.

Re: Protocol extension for changing desktop name on the fly

2008-01-13 Thread Peter Åstrand
On Tue, Jan 08, 2008 at 10:20:50AM -, James Weatherall wrote: In practice desktop names are currently ASCII-only, but new standard RFB protocol elements all use UTF-8 for string data. I'd recommend that third-party encodings, etc also use UTF-8 for string data for consistency. So,

Re: Maximum number of displays limit reached

2008-01-23 Thread Peter Åstrand
On Wed, 23 Jan 2008, PARESH MASANI wrote: I came to know that Real VNC supports only 99 sessions per host. and after that it displays error saying no free display number on machine.Could anyone have the same problem or knows how to solve this then please let me know. This limit comes from

Re: VNC compilation against Xorg 1.4

2008-02-01 Thread Peter Åstrand
On Fri, 1 Feb 2008, Adam Tkac wrote: Xvnc source is designed to work with pretty old monolitic XFree source. I've forked vnc free edition about 2 months ago as project 'baracuda'. You will see https://fedorahosted.org/baracuda/ and mercurial repository http://hg.fedorahosted.org/hg/baracuda.

Re: VNC compilation against Xorg 1.4

2008-02-04 Thread Peter Åstrand
On Mon, 4 Feb 2008, Adam Tkac wrote: Xvnc source is designed to work with pretty old monolitic XFree source. I've forked vnc free edition about 2 months ago as project 'baracuda'. You will see https://fedorahosted.org/baracuda/ and mercurial repository

Re: Not able to connect if disaplay number is greater then 99 from vncviewer....

2008-02-18 Thread Peter Åstrand
On Mon, 18 Feb 2008, Corne Beerse wrote: For X11 (unix/linux) based VNC servers, the effective maximum number of connections/sessions is limited tot 64, because the X11 protocol only allows display numbers 0 trough 63. There are even reports of less (up to 32). Do you have any reference? As I

Re: Not able to connect if disaplay number is greater then 99 from vncviewer....

2008-02-18 Thread Peter Åstrand
On Mon, 18 Feb 2008, Corne Beerse wrote: For X11 (unix/linux) based VNC servers, the effective maximum number of connections/sessions is limited tot 64, because the X11 protocol only allows display numbers 0 trough 63. There are even reports of less (up to 32). Do you have any

Re: UTF-8 supports for copy paste

2009-01-20 Thread Peter Åstrand
This was discussed some time ago, when the DesktopName pseudo encoding was added. From http://thread.gmane.org/gmane.network.vnc.user/28362/focus=28392: In practice desktop names are currently ASCII-only, but new standard RFB protocol elements all use UTF-8 for string data. I'd recommend that

Open Letter: Leaving TightVNC, Founding TigerVNC

2009-02-27 Thread Peter Åstrand
The Virtual Network Computing technology is truly great. With millions of users, it has also inspired numerous implementations and projects. The Open Source license encourages sharing of code and ideas and allows the community to make collective progress. Too many different implementations,