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 ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
