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
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
20 matches
Mail list logo
