On Sun, 26 Apr 2009 18:47:43 +0200
Peter Rosin wrote:
> Den 2009-04-24 11:00 skrev Pierre Ossman:
> > I feel a bit like every option results in ugly complexity somewhere. :/
> >
> > The best option would be if we could extend the init sequence, but I'm
> > not sure that's feasible.
>
> If you c
Den 2009-04-24 11:00 skrev Pierre Ossman:
> I feel a bit like every option results in ugly complexity somewhere. :/
>
> The best option would be if we could extend the init sequence, but I'm
> not sure that's feasible.
If you can live with a dependency on the tight security type, you're all
set.
On Fri, 24 Apr 2009 09:41:35 +0200
Peter Rosin wrote:
> Den 2009-04-23 10:45 skrev Pierre Ossman:
> > As I see it, there are three options here:
> >
> > 1. Keep the text as it is, making non-incr. a bit odd in that
> >it will never give you any data directly.
> > 2. Only send the
Den 2009-04-23 10:45 skrev Pierre Ossman:
> On Wed, 22 Apr 2009 17:43:00 +0200 Peter Rosin wrote:
>> Den 2009-04-22 16:34 skrev Pierre Ossman:
>>> In case someone has already started looking at implementing this,
>>> here's another update.
>>>
>>> Changed:
>>>
>>> - Require that the ExtendedDeskto
On Thu, 23 Apr 2009 14:25:52 +0200
Pierre Ossman wrote:
> On Wed, 22 Apr 2009 16:34:51 +0200
> Pierre Ossman wrote:
>
> > - Clarify DesktopSize behaviour based on a survey of the major VNC
> >implementations.
>
> Thinking more about this, I now believe that the RealVNC
> implementation of
On Wed, 22 Apr 2009 16:34:51 +0200
Pierre Ossman wrote:
> - Clarify DesktopSize behaviour based on a survey of the major VNC
>implementations.
Thinking more about this, I now believe that the RealVNC
implementation of DesktopSize is broken and incompatible with the
earlier implementations l
On Wed, 22 Apr 2009 17:43:00 +0200
Peter Rosin wrote:
> Den 2009-04-22 16:34 skrev Pierre Ossman:
> > In case someone has already started looking at implementing this,
> > here's another update.
> >
> > Changed:
> >
> > - Require that the ExtendedDesktopSize is sent without any data
> >upd
Den 2009-04-22 16:34 skrev Pierre Ossman:
> In case someone has already started looking at implementing this,
> here's another update.
>
> Changed:
>
> - Require that the ExtendedDesktopSize is sent without any data
>updates.
I think it would be useful to explicitely state somewhere that a
In case someone has already started looking at implementing this,
here's another update.
Changed:
- Official numbers allocated.
- Some minor clarifications for when both DesktopSize and
ExtendedDesktopSize are used, for replies to SetDesktopSize and for
the flags.
- Require that the Ex
This is a new version of the new screen update protocol, based on
feedback in the previous round.
Basic changes:
- Removal of sizing hints. This is a big problem, and better suited by
a separate pseudoencoding that can send all sorts of information,
including enumerations of valid sizes.
On Tue, 17 Mar 2009 11:30:51 +0100
Pierre Ossman wrote:
>
> How do local equivalents behave? How does Windows or RandR respond to
> an invalid change request? I haven't seen much more than "sod off" in
> the way of helpfulness from those systems either. The only addition
> might be that they can
On Mon, 16 Mar 2009 20:55:45 +0100
Peter Rosin wrote:
>
> However, I still think 16 bits to be too little to deliver a useful
> error response for something as complex as this and I wish you a happy
> time telling users to read the manual of the server they are connecting
> to when the client ge
Den 2009-03-13 13:01 skrev Pierre Ossman:
> Hi,
>
> We've been working on client initiated screen size changes and need to
> extend the protocol to do that.
>
> In order to minimise the number of extensions, we'd also like to
> accommodate multi-head configurations with this new protocol.
>
> So
Den 2009-03-16 18:15 skrev Pierre Ossman:
> On Mon, 16 Mar 2009 16:54:20 +0100
> Peter Rosin wrote:
>
>> Den 2009-03-16 15:00 skrev Pierre Ossman:
>>> Annoying. Do they also rely on putting the conversion requirements on
>>> the client?
>> Yes. If a client claims support for WMVi, it has to suppor
Den 2009-03-16 11:45 skrev Pierre Ossman:
> On Mon, 16 Mar 2009 10:44:07 +0100
> Peter Rosin wrote:
>
>> Hi Pierre!
>>
>> There is also the WMVi pseudo-encoding (0x574d5669, or "WMVi" in FourCC)
>> to consider. A problem with this new proposal is that *both* WMVi and
>> this multihead scheme are "
Den 2009-03-16 15:00 skrev Pierre Ossman:
> On Mon, 16 Mar 2009 13:29:38 +0100
> Peter Rosin wrote:
>
>> Den 2009-03-16 11:45 skrev Pierre Ossman:
>>> That would be very against the RFB mentality, yes. But the wiki entry
>>> you pointed to suggests that these encodings are just used for
>>> "offli
On Mon, 16 Mar 2009 16:54:20 +0100
Peter Rosin wrote:
> Den 2009-03-16 15:00 skrev Pierre Ossman:
> >
> > Annoying. Do they also rely on putting the conversion requirements on
> > the client?
>
> Yes. If a client claims support for WMVi, it has to support all pixfmts
> (or disconnect on recepti
On Mon, 16 Mar 2009 13:29:38 +0100
Peter Rosin wrote:
> Den 2009-03-16 11:45 skrev Pierre Ossman:
> >
> > That would be very against the RFB mentality, yes. But the wiki entry
> > you pointed to suggests that these encodings are just used for
> > "offline" rendering. At that point there is no po
On Mon, 16 Mar 2009 10:44:07 +0100
Peter Rosin wrote:
>
> Hi Pierre!
>
> There is also the WMVi pseudo-encoding (0x574d5669, or "WMVi" in FourCC)
> to consider. A problem with this new proposal is that *both* WMVi and
> this multihead scheme are "better than" the DesktopSize pseudo-encoding.
>
On Fri, 13 Mar 2009 11:37:18 -0500
DRC wrote:
> While we're asking about protocol extensions, do we want to bring up
> adding the TurboVNC extensions as well? These extensions are a superset
> of the existing vnc-tight extensions, so I'm not sure if the RealVNC
> list would even care.
>
We nee
While we're asking about protocol extensions, do we want to bring up
adding the TurboVNC extensions as well? These extensions are a superset
of the existing vnc-tight extensions, so I'm not sure if the RealVNC
list would even care.
Pierre Ossman wrote:
> Hi,
>
> We've been working on client init
Hi,
We've been working on client initiated screen size changes and need to
extend the protocol to do that.
In order to minimise the number of extensions, we'd also like to
accommodate multi-head configurations with this new protocol.
So we'd like your feedback on the protocol, and allocation of
22 matches
Mail list logo
