yourselves there instead as I'll convert this list to
read only soon.
I'm also looking for volunteer admins for this. I'd like to not be the
only one with admin rights. Please contact me directly if you feel up
for the task.
Rgds
--
Pierre Ossman Software Development
Cen
I was unable to get in touch with Adam, so I have commit the patch more
or less as-is.
Regards
--
Pierre Ossman Software Development
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköpinghttp://facebook.com/ThinLinc
Phone
ck using any other client than their own.
There is a standardised encryption called VeNCrypt though that many of
the other VNC implementations support. So try one of those servers
instead and you get a bit more choice in clients.
Rgds
--
Pierre Ossman Software Development
Cendio AB
gards, Adam
This thing has lingered for way too long. Better we commit this version
and do improvements later than have nothing at all.
Adam, do you think you could clean up the SASL section and reformat the
patch with a commit message and signed off line?
Rgds
--
Pierre Ossman Softwar
oudvnc/
Was upstream UltraVNC not interested in these improvements?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
A: Because it messes up the order in which people norm
Allows clients and servers to handshake for the continuous updates
extension without having to use the tight authentication method.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 4793
This documents the fence messages that can be used to synchronise
other messages, and to measure network and processing delays between
the client and server.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst
On Thu, 27 Oct 2011 16:53:11 +0200
Pierre Ossman wrote:
> Originally developed in the TightVNC project and currently tied into
> their extension handshake mechanism. Should be possible to extend and
> use more generally though.
>
> Signed-off-by: Pierre Ossman
Committed.
--
On Thu, 27 Oct 2011 17:25:51 +0200
Pierre Ossman wrote:
> Signed-off-by: Pierre Ossman
> ---
Committed.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
A: Beca
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 4741)
+++ rfbproto.rst(working copy)
@@ -788,7 +788,7 @@
-232"``TGHT``" "``POINTPOS``" Pointer Posit
On Tue, 4 Oct 2011 14:11:00 +0200
Pierre Ossman wrote:
> (Cross-posting to both tigervnc-devel and rfbproto as this is a general
> protocol issue, but tigervnc will be the playground for testing it)
>
> Hi,
>
> I'm looking at making VNC/RFB work better over high laten
Originally developed in the TightVNC project and currently tied into
their extension handshake mechanism. Should be possible to extend and
use more generally though.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
No objections, so I'm committing this.
On Tue, 24 May 2011 13:31:22 +0200
Pierre Ossman wrote:
> As RFB vertical wheel events are based on X11's way of representing
> these as buttons 4 and 5, it's only natural to extend button 6 and 7 to
> represent horizontal wheel e
unpleasant over many links. Things are still very much up in the
air, but I've written down my thoughts so far and I'd appreciate any
input you could give on it. You can find my notes here:
https://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations
Rg
most certainly is. I was thinking about clarifications in the core
protocol specification (e.g. the dangers of switching pixel format)
though, not extensions. Those are in most cases probably better
described in separate RFC:s.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Tec
NC specification which we know has issues).
Unfortunately we didn't get any attention, and it now seems we have an
RFC which lacks a lot of important clarifications. :/
Anyone up for starting a new RFC with our improvements? :)
Rgds
--
Pierre OssmanOpenSource-based Thin Cli
``U8`` array*username-string*
Given the history of RFB, you should probably be explicit with the
encoding used here (UTF-8 if there is no massive reason for something
else).
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +4
As RFB vertical wheel events are based on X11's way of representing
these as buttons 4 and 5, it's only natural to extend button 6 and 7 to
represent horizontal wheel events. This behaviour is what is seen on
modern X servers.
Signed-off-by: Pierre Ossman
---
Index: rf
ent
feedback either. :/
What I can do for you though, is to get documentation for this into the
specification here. That might get your encoding some attention at
least. If you have a formal description I can have a look at it and get
it committed.
Rgds
--
Pierre OssmanOpenSource-base
On Tue, 20 Jul 2010 10:31:09 +0200
Adam Tkac wrote:
>
> Next revision of VeNCrypt spec is attached.
>
Any chance of getting this documentation effort restarted/finished?
Would be nice to have things finalised as this is a popular
extension. :)
Rgds
--
Pierre OssmanO
ank you for this patch. Sorry about overlooking it until now. It's
been committed to the repo.
One clarification I'm curious about though; what should clients do if
they don't know how to map a key to a XT scan code for a certain key?
Picking something at random is probably not
sure any of them are subscribed to this
list though.
I'm wondering why the integration into an existing encoding though?
This extra layer of tight encodings on top of the normal encodings is
just extra overhead and is not something that we should be promoting
going forward.
Rgd
On Thu, 08 Oct 2009 20:02:14 +0200
Peter Rosin wrote:
> Hi!
>
> Tristan Richardson said he was going to update the Internet
> Draft with this clarification of the Hextile encoding in
> a private response to a direct question from me.
>
> Cheers,
> Peter
This too.
On Thu, 08 Oct 2009 19:49:44 +0200
Peter Rosin wrote:
> Hi!
>
> Adding a few new protocol numbers (MD5 hash and TurboVNC pseudo-encodings).
>
> Cheers,
> Peter
Also applied.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer
On Thu, 08 Oct 2009 19:40:39 +0200
Peter Rosin wrote:
> Hi!
>
> Found a minor whitespace glitch.
>
Applied.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://ww
===
-Where *r* is floor((*runLength* - 1) / 255).
+Where *r* is div(*runLength* - 1, 255).
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
gs,
but should be handled like opaque, 8 byte blobs (or so I'm
assuming). Perhaps this should be clarified?
- The GII stuff doesn't mention anything about encodings for its
strings. If it's undefined then we should refer to the new encoding
chapter.
Rgds
--
Pierre Oss
Steer things towards UTF-8, whilst also adding a notice that
historically there has been a lot of different encodings in use.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 3887
user interface. It should be obvious in that
case that the string has been modified, e.g. by appending a notice to
the string.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
On Mon, 29 Jun 2009 22:37:18 +0200
Peter Rosin wrote:
> Den 2009-06-29 11:16 skrev Pierre Ossman:
> > IMO it's better to have a strong "must" as all strings really need to
> > have a defined encoding, but keep the historical note to warn against
> > the
We haven't seen anything of what Real thinks about this change. Wez
expressed some desire to use UTF-8 in that older thread at lease.
Wez, what's your take on this discussion?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone:
On Fri, 26 Jun 2009 21:15:40 +0200
Peter Rosin wrote:
> Den 2009-06-25 16:26 skrev Pierre Ossman:
> > Incompatible is a term that will have to be used loosly here. There is
> > no compatibility here today as everyone is doing different things, so I
> > don't see this mo
re how their version will affect anything. Given the history,
you can never be sure that this field will display correctly when using
anything other than ASCII.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB
Steer things towards UTF-8, whilst also adding a notice that
historically there has been a lot of different encodings in use.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 3856
other
> thread. So, I'm shortcutting the discussion on the
> bigger problem with this updated patch...
>
Committed, thanks.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb:
On Wed, 17 Jun 2009 13:18:37 +0200
Peter Rosin wrote:
> Den 2009-06-17 11:46 skrev Pierre Ossman:
> > I'd kill for git-am though :/
>
> So, why didn't you guys move to git when you forked tiger-vnc? tsk tsk :-)
>
We had to consider the elderly who had just man
t
> docs...
>
Very nice work, I've committed all of it. I'd kill for git-am though :/
PS. you cannot have a blank line between the definition term and the
description. Please have a look at the pdf output before you send the
patches.
Rgds
--
Pierre OssmanOpenSource-b
that I suspect that the tight levels have been
> experimented with a lot so that you get a good tradeoff in most
> situations.
You'd think. Unfortunately that's not the case, so we changed the
levels in Tiger to something that made more sense from a compression
ratio
ntioned.
And do we want to make this a generic extension? Perhaps call it "Lossy
Quality Level..." instead?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://
On Tue, 16 Jun 2009 16:24:07 +0200
Peter Rosin wrote:
> Den 2009-06-16 14:00 skrev Pierre Ossman:
> > And do we want to make this a generic extension? Perhaps call it "Lossy
> > Quality Level..." instead?
>
> I don't think we should rename it, but the
forgotten?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
-
See the `LastRect Pseudo-encoding`_ for an extension to this message.
>
I completely missed that. :)
You might want to expand on that paragraph though and mention that
LastRect means that the rect count might be something other than that
stated.
Rgds
--
Pierre OssmanOpenSource-bas
ression may be used
> +only when bits-per-pixel value is either 16 or 32, not 8.
Again, is this a hard requirement?
> +
> +.. [NOTE4] The width of any Tight-encoded rectangle cannot exceed
> +2048 pixels. If a rectangle is wider, it must be split into several
> +rectangles
that it is going to send 65535 rectangles,
> +but it then stops with a *LastRect* instead of sending all of them.
> +There is no further data associated with the pseudo-rectangle.
> +
Isn't it required to state 65535 rectangles?
And we might want to make a note of this in the Frameb
t be a hint to the server, not a
requirement. Since we do not specify exactly what the levels mean, I
don't see how it can be anything other than a hint.
Either way, I think these things should be mentioned.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Develop
handle
Tight's allocations. I'd rather have multiple lines with "Reserved for
TightVNC" than change the layout of the entire table.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB
On Thu, 11 Jun 2009 10:38:45 +0200
Peter Rosin wrote:
> Den 2009-06-04 13:34 skrev Pierre Ossman:
> > 3. Unix client
> >
> > Passes the string unmodified to XSetName(). Looking at the xlib
> > reference documentation, this uses "Host Portable Character Encoding&
the version string and the
error messages. I see no need to upgrade either of those to UTF-8.
I don't support dropping connections on malformed UTF-8. There is no
problem determining where the string ends, so there is no reason to
terminate the connection.
Rgds
--
Pierre Ossman
On Thu, 11 Jun 2009 10:07:01 +0200
Peter Rosin wrote:
>
> Hi Pierre,
>
> Sorry for the delay, I was on vacation...
>
> That works for me (if you lose the trailing newline in rsttool :-)
>
Will do. ;)
Rgds
--
Pierre OssmanOpenSource-based Thin Client Techno
Just for fun, I had a quick look at the clipboard handling. The
situation is better there with the Unix side handling things correctly.
Windows however is broken and assumes that the local system uses a
superset of 8859-1.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
On Fri, 29 May 2009 10:51:14 +0200
Pierre Ossman wrote:
>
> Has anyone done a survey of how implementations treat this extension
> and the name field in the server init? If there are no existing
> implementations that prevent it, then I'd like to specify UTF-8 for at
>
On Mon, 1 Jun 2009 14:30:55 +0200
Pierre Ossman wrote:
> On Mon, 01 Jun 2009 13:17:17 +0200
> Peter Rosin wrote:
>
> >
> > Those are spelled rst2newlatex.py and rst2html.py on my system.
> > What are their canonical names?
> >
>
> Upstream uses the
tion to specify the handling so
> > that it doesn't break anything existing.
>
> In the attached patch, I have attempted to address version numbering
> (see the server message description).
>
Looks very nice. I've applied the patch.
Rgds
--
Pierre OssmanOpen
d be
handled. Since it's just you and Peter Rosin who have implemented this
extension, I'd say you're in a best position to specify the handling so
that it doesn't break anything existing.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer
On Mon, 01 Jun 2009 13:17:17 +0200
Peter Rosin wrote:
>
> Those are spelled rst2newlatex.py and rst2html.py on my system.
> What are their canonical names?
>
Upstream uses the .py suffix. Annoying...
I guess we need to do something clever here.
Rgds
--
Pierre Ossman
Targets for generating a PDF and a HTML page.
Signed-off-by: Pierre Ossman
---
Index: Makefile
===
--- Makefile(revision 0)
+++ Makefile(revision 0)
@@ -0,0 +1,14 @@
+all: rfbproto.pdf rfbproto.html
+
+.SUFFIXES : .rst .pdf
ek.
>
> If you want whitespace nits in a special commit there is
> also an extra line at the end of the document that may (or
> should, depending on your mood) be removed...
>
Consider it gone.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Devel
h allows shutdown, reboot and reset of virtual
> +machines running on Citrix XenServer.
Does this page add anything to the protocol definition? We don't have
official reference implementations for anything else, so I'm sceptical
about adding one here.
Rgds
--
Pierre Ossman
;
Apparently the same as the rest of us as nobody else noticed it
either. ;)
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
ts and then it's not 100%
> safe to issue a change in pixfmt.
>
> Have I missed something obvious?
>
Sounds about right. But as you point out, the behaviour of an empty FUR
is a bit unknown.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Develop
from
+after the framebuffer resize had occurred on the server.
+
The semantics defined here retain compatibility with both of two older
implementations.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB
is sequence?
>
> It was in the interaction between QEMU and the emulated guest OS' key
> handling
>
I see. Some might consider it a feature that the guest only sees the
"real" key events.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System
On Fri, 29 May 2009 12:19:17 +0200
Peter Rosin wrote:
> Den 2009-05-29 11:00 skrev Pierre Ossman:
> >
> > Looks good to me. Perhaps we should add quotes to the capability
> > strings though so there is no confusion with types? This is how it's
> > done for the ve
On Thu, 28 May 2009 21:58:27 +0200
Peter Rosin wrote:
> Signed-off-by: Peter Rosin
>
> Cheers,
> Peter
Applied.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://ww
capability
strings though so there is no confusion with types? This is how it's
done for the version handshake.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb
iginal thread
really didn't come to a decent conclusion.
Has anyone done a survey of how implementations treat this extension
and the name field in the server init? If there are no existing
implementations that prevent it, then I'd like to specify UTF-8 for at
least the exte
quot;?
>
It's a lot more generic, so yes. Although I don't think that it would
be a problem to loose the connect to the XVP acronym and avoid this
convoluted backronym. I don't think people will be that confused by
different names in RealVNC's and our spec. :)
Rgds
--
Pierre
On Thu, 28 May 2009 17:00:56 +0100
"Daniel P. Berrange" wrote:
> On Mon, May 11, 2009 at 01:59:51PM +0200, Pierre Ossman wrote:
> > This thread seems to have died off.
> >
> > Daniel, do you feel that your concerns have been addressed, or do we
> > need mo
On Mon, 11 May 2009 13:59:51 +0200
Pierre Ossman wrote:
> This thread seems to have died off.
>
> Daniel, do you feel that your concerns have been addressed, or do we
> need more discussion?
>
*ping*
--
Pierre OssmanOpenSource-based Thin Client Technology
S
On Thu, 28 May 2009 15:55:02 +0200
Peter Rosin wrote:
> Den 2009-05-11 13:35 skrev Pierre Ossman:
> > Why is there both a numerical code, and a string pair used to identify
> > the extension? It seems a bit redundant.
>
> Once upon a time I asked about related things on t
On Thu, 28 May 2009 15:05:11 +0200
Peter Rosin wrote:
> Also add some introductory text to each chapter involving gii.
>
> Signed-off-by: Peter Rosin
>
Looks ok to me. Applied.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephon
O.
So my vote is "Virtual Machine Control ..." so that it's clear what
this extension does even from just the name.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio A
On Thu, 28 May 2009 14:12:18 +0200
Peter Rosin wrote:
> Den 2009-05-28 13:58 skrev Pierre Ossman:
> >
> > That was the scenario I was thinking of, yes. How about this addition
> > to SetPixelFormat:
> >
> > Note that a client must not have an outstanding
>
me to a somewhat decent description on some wiki? That
should be fairly easy to clean up and merge.
>
> Let's commit the dang thing and worry about WMVi later...
>
Will do. :)
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Teleph
On Thu, 28 May 2009 14:04:34 +0100
"Daniel P. Berrange" wrote:
> On Thu, May 28, 2009 at 01:54:20PM +0200, Pierre Ossman wrote:
> >
> > I belive the problem is that WMVi is fundamentally broken. RFB is all
> > about putting complexity at the server and lett
On Thu, 28 May 2009 14:09:45 +0200
Peter Rosin wrote:
> Hi Pierre,
>
> Den 2009-05-28 13:34 skrev Pierre Ossman:
> > The implementation of the DesktopSize (also called NewFBSize)
> > pseudo-encoding differs a bit between VNC families. This tries to
> > document a
I was thinking of, yes. How about this addition
to SetPixelFormat:
Note that a client must not have an outstanding
*FramebufferUpdateRequest* when it sends *SetPixelFormat* as it would
be impossible to determine if the next *FramebufferUpdate* is using the
new or the previous pixel format.
Rgds
On Tue, 19 May 2009 15:45:54 +0200
Peter Rosin wrote:
> Den 2009-05-15 12:20 skrev Pierre Ossman:
> > Although I didn't incorporate you changes in this extension, I have
> > been thinking about them and I think they should be added, but as
> > separate extensions. A
The implementation of the DesktopSize (also called NewFBSize)
pseudo-encoding differs a bit between VNC families. This tries to
document a behaviour that works in the majority of the implementations.
Signed-off-by: Pierre Ossman
---
This version tries to give some background to the problem, and
On Mon, 4 May 2009 13:50:34 +0200
Pierre Ossman wrote:
This extension adds multi-head support to RFB, and allows the client to
request framebuffer and screen layout changes on the server.
Signed-off-by: Pierre Ossman
---
This version includes the restriction that a server may not send both a
On Thu, 14 May 2009 15:56:35 +0200
Peter Rosin wrote:
> Den 2009-05-11 13:27 skrev Pierre Ossman:
> >
> > That sounds a bit like "this look like crap, but pff, what do I
> > care?" :)
>
> Well, that's stretching it, but exactly one person has commen
It seems we agree that implementations should be done in a way that
supports everything, we just need to agree on a wording that conveys
that. :)
On Thu, 14 May 2009 15:04:27 +0200
Peter Rosin wrote:
> Den 2009-05-11 13:24 skrev Pierre Ossman:
> >
> > That was not my intention.
This thread seems to have died off.
Daniel, do you feel that your concerns have been addressed, or do we
need more discussion?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http
There are some corner cases in the framebuffer update system that need
to be explicitly mentioned.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 3809)
+++ rfbproto.rst(working
+-305``GGI_`` ``GII_`` `gii (General Input Interface)
> +Pseudo-encoding`_
> +=== ===== ===== ===
Nit-picking, but code was defined as U32, not S32. :)
Rgds
--
Pierre OssmanO
On Wed, 06 May 2009 12:25:12 +0200
Peter Rosin wrote:
> Den 2009-05-04 13:50 skrev Pierre Ossman:
> > This extension adds multi-head support to RFB, and allows the client to
> > request framebuffer and screen layout changes on the server.
> >
> > Signed-off-by: P
d the FB that I've also dropped the
cursor data.
> (and I further think you should disallow sending DesktopSize
> rects to a client that supports both DesktopSize and ExDesktopSize,
> allowing both will just add complications without any gain).
I figur
On Fri, 08 May 2009 13:41:56 +0200
Peter Rosin wrote:
> Describe the zlibhex encoding in terms of the hextile encoding.
>
> Signed-off-by: Peter Rosin
>
> (I'm not all satisfied with the double^Wtripple reference to zlib...)
>
> Cheers,
> Peter
&g
h.
>
> Signed-off-by: Peter Rosin
>
Also applied.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Des
le from the original
document in an effort to be as identical as possible. We're probably
better off using a named reference.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.c
On Fri, 08 May 2009 10:31:55 +0200
Peter Rosin wrote:
> Describe the CoRRE encoding in terms of the RRE encoding.
>
> Signed-off-by: Peter Rosin
>
> Cheers,
> Peter
Applied.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telep
ce to get an HTML-ized version of the spec (automatically?)
> published on the website based off RST source
>
I've managed to get this up and running now through a Python CGI
script. Check the web page for URI.
(Someone might want to make a nice CSS for it though ;))
Rgds
--
Pierre Ossm
On Wed, 06 May 2009 10:23:55 +0200
Peter Rosin wrote:
> It is official according to:
> http://realvnc.com/pipermail/vnc-list/2008-December/059463.html
>
> I don't know why it's not in the official spec yet though.
>
> Signed-off-by: Peter Rosin
> ---
Also a
ce to get an HTML-ized version of the spec (automatically?)
> published on the website based off RST source
>
I'd consider having it automatic to be more or less a requirement.
Otherwise we'd have different versions saying different things.
Does anyone know if you can add triggers fo
is project to a
sensible VCS in the future. ;)
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description
On Mon, 4 May 2009 13:44:28 +0200
Pierre Ossman wrote:
> On Thu, 30 Apr 2009 15:53:42 +0200
> Peter Rosin wrote:
>
> > Document the General Input Interface (gii) extension.
> >
> > Signed-off-by: Peter Rosin
>
> Looks good. So if noone objects, I'd like
On Mon, 04 May 2009 16:09:24 +0200
Peter Rosin wrote:
> Den 2009-05-04 13:49 skrev Pierre Ossman:
> > +The server changes the desktop size by sending a pseudo-rectangle with
> > +the *DesktopSize* pseudo-encoding. The update containing the
> > +pseudo-rectangle must not c
This extension adds multi-head support to RFB, and allows the client to
request framebuffer and screen layout changes on the server.
Signed-off-by: Pierre Ossman
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB
The implementation of the DesktopSize (also called NewFBSize)
pseudo-encoding differs a bit between VNC families. This tries to
document a behaviour that works in the majority of the implementations.
Signed-off-by: Pierre Ossman
--
Pierre OssmanOpenSource-based Thin Client
e of U16 -> EU16 changes...
>
> Here's another update and sorry for the noise.
>
> Cheers,
> Peter
>
> ChangeLog:
> Document the General Input Interface (gii) extension.
>
> Signed-off-by: Peter Rosin
Looks good. So if noone objects, I'd like to commit
1 - 100 of 108 matches
Mail list logo