On Mon, 16 Mar 2009 13:29:38 +0100 Peter Rosin <p...@lysator.liu.se> 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 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. > Annoying. Do they also rely on putting the conversion requirements on the client? > > > > 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. > I'm not sure I see the complexity. If a server wants to support all three methods, it can send all three rects. The only requirement that must hold is that the information in the different versions do not conflict. Admitted, having WMVi for just sending hints about the server's native pixel format can be a bit heavy. But I think it would be better replaced by a pseudoencoding that does only just that. Including that information here just makes the screen geometry handling seem more complex. (In a perfect world I'd have framebuffer size and virtual screen setup be completely separate as well, but that would mean that we would need two client-to-server commands and that would be wasteful given the limited space of command codes.) > > > > 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. It's just the authentication as far as I can see. And that something in the existing protocol is bad is hardly an argument for making additions equally bad. > 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. The idea isn't fundamentally bad, it's just that describing restrictions is a can of worms and I don't think its a good idea to add features that you don't have a plan as to how they should be used. > > 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... Indeed, but describing such limitations can be very difficult. How do you describe the non-overlapping requirement for example? I don't see the method of requesting one thing and potentially getting something completely different back as a decent solution. In most cases it will just be plain confusing. Could you describe how the client could suitably react to such a response? Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
