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 we'd like your feedback on the protocol, and allocation of one new
client to server message and one pseudo encoding.
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.
But the multihead scheme doesn't do the stuff that WMVi does (i.e.
handle server side pixel format changes). I fear that appempts to
implement support for both WMVi and this proposal will lead to undesired
complexity.
So, I'm asking for a way to incorporate server side pixel format changes
in this proposal so that it can superseed both WMVi and DesktopSize.
That said, there is one thing that I don't like about WMVi, and that is
the fact that the server changes the "wire" pixel format without a chance
for the client to say no. I would not mind at all if that was revised,
should a pixel format changes be added to this proposal, so that the
server instead simply informed that its preferred pixel format has
changed. The client would then be in full control of what pixel formats
it needs to support, and my feeling is that this is more in line with
the spirit of the RFB protocol.
Even if it wouldn't add needless complexity if the server were to send
a WMVi rect for some changes and a ExDesktopSize rect for some other
changes and perhaps two rects for some classes of changes, I still think
there is value in an "advisory" notification that the server has changed
its preferred pixel format, and this seems like a good opportunity to
sneak that into the RFB protocol ;-)
Here's a description of WMVi:
http://wiki.multimedia.cx/index.php?title=VMware_Video
And lastly, some comments on details in the proposal:
There is no way for the server to tell a client how it can change its
SetDesktopSize message so that it gets something that is ok for the
server. If e.g. the server has some resource limit that prevents it from
making framebuffers wider than 2048 pixels (just an example, the example
has no bearing on any particular HW), then the server has no way to
indicate to the client that it must keep below that limit. One way to
solve that would be for the server to fill in the ExtendedDesktopSize
rect with values that may work better when y-position is non-zero,
instead of simply echoing the current state (which the client should
already know). But perhaps that would be too complex. My main point is
that it's very limitied to only have 16 bits (the y-position) to
describe a problem. Perhaps an error string?
The x position of the pseudo-rect indicates the "reason for the change",
and an ExtendedDesktopSize pseudo-rect should also be sent in response
to non-incremental FrameBufferUpdateRequests. I'm missing "non-i FBUR"
as a reason in the enumeration (even if that isn't a /change/ as such).
Cheers,
Peter
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
