qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
Date: Wed, 27 Aug 2008 11:31:36 +0100
User-agent: Mutt/1.4.1i

On Wed, Aug 27, 2008 at 12:02:11PM +0200, Alexander Graf wrote:
> On Aug 24, 2008, at 1:27 AM, Anthony Liguori wrote:
> >static void set_encodings(VncState *vs, int32_t *encodings, size_t  
> >n_encodings)
> >{
> >    int i;
> >@@ -1105,6 +1124,9 @@
> >     case -257:
> >         vs->has_pointer_type_change = 1;
> >         break;
> >+        case -258:
> >+            send_ext_key_event_ack(vs);
> >+            break;
> >     default:
> >         break;
> >     }
> >@@ -1256,6 +1278,24 @@
> >
> >     client_cut_text(vs, read_u32(data, 4), data + 8);
> >     break;
> >+    case 255:
> >+        if (len == 1)
> >+            return 2;
> >+
> >+        switch (read_u8(data, 1)) {
> >+        case 0:
> 
> How do you standardize VNC protocol extensions? I've been wondering  
> about this for quite a while as I've got two VNC patches in my queue  
> myself.
> The first one allows the client to send a keyboard layout (so the -k  
> option could be changed dynamically, mostly because the Java client  
> can't find symcodes).

This is a straightforward new encoding type

> The other one implements PNG compression for Tight.

In this case you're proposing additions to someone else's existing
defined encoding. I don't believe there's a formal process for
doing that, and I don't think Tight even has the ability to negotiate
further sub-encodings, so you might be out of luck on that score.

> I'd really love to have both of them standardized, but where do I need  
> to apply for an identifier ID?

You can request a encoding to be allocated at vnc-list

  http://www.realvnc.com/mailman/listinfo/vnc-list

For it to be any use, you then need to convince at least one server
impl, and one client impl to actually support your new encoding.
Obviously the server side in this case is the QEMU developers...

Anthony and myself are the developers of the GTK-VNC client, so
were merely have to agree with ourselves for the client end, and
make sure its plays nicely with the QEMU end.

The GTK-VNC client is used in Vinagre, virt-viewer, virt-manager
and oVirt. If you wan to propose extensions for the client, we
have a public mailing list & source repo:

  http://sourceforge.net/projects/gtk-vnc

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]