> [EMAIL PROTECTED] wrote: > > This extension is documented at > > http://tocm.wikidot.com/pointertypechange > > VMware has a very similar extension for their remote console. I > believe > that Ramesh Dharan (whom I've CCed) at some point implemented it in one > or more open source clients. Perhaps some coordination here is > possible?
Yeah I played implemented support for VMware's relative pointer extension, as well as our "grab" metaphor, and some other stuff, on top of the RealVNC 4.1.1 codebase. I unfortunately never got the patch cleaned up enough for submitting back to RealVNC however... I have a work-in-progress document that defines our extensions but it's not really ready for public consumption yet. I'm not sure of the context here, but I assume QEMU is using VNC as the wire protocol for displaying framebuffer contents remotely? Are you writing a new VNC client from scratch or building on one of the existing GPL'ed clients? The main limitations we've run into with using the VNC protocol for VM interaction are: (1) no support for keyboard scancodes (VNC uses higher level symbolic keys which aren't necessarily 1:1 mappable back to their scancode equivalents in all the scenarios we care about) (2) no relative mouse support (3) no alpha cursor support (4) no dynamic pixel depth/bpp change support (5) No notion of multiplexing displays on a single port. (6) No client->server message negotiation. I implemented new client->server messages for the (1) and (2), and server->client pseudorectangle extensions for (3) and (4). We deal with (5) in a different way; our display multiplexing is handled at a higher level. We ignored (6) since our clients currently only talk to our servers. Looking at the linked site, it looks like you folks have already identified and are planning to deal with (2), possibly (5) (via some games with the display name?) and (6). I'd be particularly interested to hear more about plans for how to address (5), it would be great if off-the-shelf/3rd-party clients could talk to multiple VMs running on a host without needing to know and use a separate the port for each VM. Our remote consoles/clients are heavily tied to our products and there aren't any real plans to divest them or make them more generally useful in the near future. However, that's likely to change someday, and anyway I'd be happy to provide feedback on, and implement support for these extensions so that e.g. a QEMU client could talk to a VMware instance, and in general get standardization to the point where it's possible to build a single remote client that could talk to the various VM implementations (QEMU, Xen, VMware, etc.). -- Ramesh
