Re: [gtk-vnc-devel] Supporting VMware VNC extensions in gtk-vnc



Hi Anthony,

On Wed Jan 02 11:42, Anthony Liguori wrote:
> Ramesh Dharan wrote:
> >We will be adding support for appropriate server<->client message 
> >negotiation
> >but this isn't in any shipping products yet. Dustin Byford (who also reads
> >this list) is heading all the VNC protocol development work these days and
> >he's probably a better contact person than me. I know Dustin has the
> >negotiation fixes on his plate to tackle in the near term; I believe he 
> >also
> >has a better protocol document available.
> 
> Well in the absence of proper negotation, I'd still like to hack 
> something up.  Can you give me a quick description of what the format of 
> the client messages are?

Yes, here it is:

Message type '127' is a "VMWMessage" packet that we use to multiplex the
pointer and keyboard messages.  The header of that packet looks like
this:

VMWMessageHeader
   uint8  id    (always 127)
   uint8  vmwid (VMWKeyEvent:0, VMWPointerEvent:1)
   uint16 len   (length of the entire packet)

The key event looks like this:

VMWKeyEvent
   VMWMessageHeader header
   uint16           vscancode
   uint8            down      (bool)
   uint8            _padding

A 'vscancode' is mostly the PC scancode, but is 16 bits wide so we can
represent the keys that use escaped scancodes (like right-alt) with a
single event.  For example, right-alt is the scancode sequence 'e0 38'
and the vscancode for that key is:

   VSCAN_ESCAPE(0x100)|SCAN_ALT(0x38) -> 0x138

The bool 'down' controls the make/break bit in the scancode (0x80).

The 'fake shift' scancodes are handled in our keyboard emulation, so you
don't need to send them.  The 'Pause' key is special, and you should
send a VSCAN_PAUSE(0x100).  Other than that, it should be fairly
straightforward.


The pointer event looks like this:

VMWPointerEvent
   VNCVMWMessageHeader header;
   int32               x    (absolute:0-65535)
   int32               y    (absolute:0-65535)
   int32               dx 
   int32               dy 
   int16               dz   (wheel, send +/-1 for up/down)
   int16               flags 

Where 'flags' is bit vector representing the pressed buttons:
   button0 = 0x01
   button1 = 0x02
   button2 = 0x04
   button3 = 0x08
   grab    = 0x10
   ungrab  = 0x20

The 'grab' and 'ungrab' bits are somewhat special.  If 'grab' is set, it
starts a chain reaction that may warp the cursor to wherever the guest
expects it to be.  If 'ungrab' is set, it basically causes the guest to
flush its cut-text buffer.


I hope that's descriptive enough to be helpful.  Let me know if you have
any questions.  As Ramesh points out, I'll be working on a way to
negotiate client->server message capabilities reasonably soon.  With
that, I hope to have more formal documentation as well.

Thanks,

                --Dustin




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]