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 "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. >> > > I don't see a huge gain from including it into these message. We could > just as well implement the server pixel format hint as another > pseudoencoding. Since it is a strict server-to-client communication, we > don't need to think about allocations in the more limited command space. > >> 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. > > 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 possibility for the > server to adjust to the client's need, so you have to mandate that the > client will use the server's native format.
WMVi is implemented by QEMU, gtk-vnc, ggivnc and more, so it's certainly not just offline rendering. I don't know why QEMU selected WMVi for adding pixfmt notifications, but they did. If you want to get full use out of QEMU you need to implement WMVi. >> 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 ;-) > > I agree that such a hint could be useful. I'm not convinced it needs to > be included in these messages. Besides, a server and client should > implement support for all variants anyway to give good backwards > compatibility. I only suggested it since WMVi is in-use already, and having one superior way to handle desktop changes is always going to be easiest, then the other methods become legacy. You can also focus on implementing each of them separately, and not on how they interact with each other. Sure, for ultimate support, a client *should* handle a server switching between DesktopSize and ExtendedDesktopSize, but both you and I know that a server which has a client supporting both is very unlikely to switch between them. It will go with ExtendedDesktopSize and be done with it. But if the server also sees WMVi support there are more than one way to send changes (WMVi first or WMVi last), and it then becomes harder to verify that a client behaves correctly in all cases, since the server you have available might not behave similar to the one next door and which you have not tested against. Adding pixel format change support in the ExtendedDesktopSize will end all that - there will be a simple path and all sane servers will follow it. Less headaches for everybody. >> 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? > > Strings are not machine parsable, nor translatable (unless you mandate > exactly what they should say, at which point you might as well use a > code for them). And yet the protocol is already full of strings, so you have to deal with that already. But if you dislike strings so much, what was wrong with the machine readable proposal? Just because the server has a way to report back something that should work doesn't mean it has to do much work to do so, a lazy server-side implementation can send back the currently active config and be done with it. > When it comes to this specific problem, the current protocol suggestion > should already handle it: > > "The x-min, y-min, x-max, and y-max indicates server imposed limits of > the framebuffer. The client can use this information to indicate to > the user when resizing (using SetDesktopSize) is possible." Ah, right. Bad example... So, take some other example: there is some limit (for whatever stupid reason) on the server so that it supports maximum 17 screens. Or it might not support overlapping screens. Or all screens have to be the same size. Use your imagination... >> 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). >> > > Ah, sorry. The intent was to have 0 be roughly "server side change" and > include the non-i FBUR. That meaning got lost in some revision. > > How about this replacement text: > > 0 - The screen layout was changed via non-RFB means on the server. For > example the server may have provided means for server-side applications > to manipulate the screen layout. This code is also used when the client > sends a non-incremental FrameBufferUpdateRequest to learn the server's > current state. Works fine for me. Thanks! 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
