qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
@ 2008-08-23 23:27 Anthony Liguori
  2008-08-27 10:02 ` Alexander Graf
  0 siblings, 1 reply; 6+ messages in thread
From: Anthony Liguori @ 2008-08-23 23:27 UTC (permalink / raw)
  To: qemu-devel

Revision: 5076
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5076
Author:   aliguori
Date:     2008-08-23 23:27:37 +0000 (Sat, 23 Aug 2008)

Log Message:
-----------
VNC: Support for ExtendedKeyEvent client message

This patch adds support for the ExtendedKeyEvent client message.  This message
allows a client to send raw scan codes directly to the server.  If the client
and server are using the same keymap, then it's unnecessary to use the '-k'
option with QEMU when this extension is supported.

This is extension is currently only implemented by gtk-vnc based clients
(gvncviewer, virt-manager, vinagre, etc.).

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Modified Paths:
--------------
    trunk/vnc.c

Modified: trunk/vnc.c
===================================================================
--- trunk/vnc.c	2008-08-23 17:22:19 UTC (rev 5075)
+++ trunk/vnc.c	2008-08-23 23:27:37 UTC (rev 5076)
@@ -939,12 +939,8 @@
     kbd_put_keycode(keysym2scancode(vs->kbd_layout, keysym) | 0x80);
 }
 
-static void do_key_event(VncState *vs, int down, uint32_t sym)
+static void do_key_event(VncState *vs, int down, int keycode, int sym)
 {
-    int keycode;
-
-    keycode = keysym2scancode(vs->kbd_layout, sym & 0xFFFF);
-
     /* QEMU console switch */
     switch(keycode) {
     case 0x2a:                          /* Left Shift */
@@ -1046,11 +1042,25 @@
 
 static void key_event(VncState *vs, int down, uint32_t sym)
 {
+    int keycode;
+
     if (sym >= 'A' && sym <= 'Z' && is_graphic_console())
 	sym = sym - 'A' + 'a';
-    do_key_event(vs, down, sym);
+
+    keycode = keysym2scancode(vs->kbd_layout, sym & 0xFFFF);
+    do_key_event(vs, down, keycode, sym);
 }
 
+static void ext_key_event(VncState *vs, int down,
+                          uint32_t sym, uint16_t keycode)
+{
+    /* if the user specifies a keyboard layout, always use it */
+    if (keyboard_layout)
+        key_event(vs, down, sym);
+    else
+        do_key_event(vs, down, keycode, sym);
+}
+
 static void framebuffer_update_request(VncState *vs, int incremental,
 				       int x_position, int y_position,
 				       int w, int h)
@@ -1078,6 +1088,15 @@
     }
 }
 
+static void send_ext_key_event_ack(VncState *vs)
+{
+    vnc_write_u8(vs, 0);
+    vnc_write_u8(vs, 0);
+    vnc_write_u16(vs, 1);
+    vnc_framebuffer_update(vs, 0, 0, vs->ds->width, vs->ds->height, -258);
+    vnc_flush(vs);
+}
+
 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:
+            if (len == 2)
+                return 12;
+
+            ext_key_event(vs, read_u16(data, 2),
+                          read_u32(data, 4), read_u32(data, 8));
+            break;
+        default:
+            printf("Msg: %d\n", read_u16(data, 0));
+            vnc_client_error(vs);
+            break;
+        }
+        break;
     default:
 	printf("Msg: %d\n", data[0]);
 	vnc_client_error(vs);
@@ -1974,10 +2014,11 @@
 
     vs->ds = ds;
 
-    if (!keyboard_layout)
-	keyboard_layout = "en-us";
+    if (keyboard_layout)
+        vs->kbd_layout = init_keyboard_layout(keyboard_layout);
+    else
+        vs->kbd_layout = init_keyboard_layout("en-us");
 
-    vs->kbd_layout = init_keyboard_layout(keyboard_layout);
     if (!vs->kbd_layout)
 	exit(1);
 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
  2008-08-23 23:27 [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message Anthony Liguori
@ 2008-08-27 10:02 ` Alexander Graf
  2008-08-27 10:31   ` Daniel P. Berrange
  2008-08-28 20:32   ` Anthony Liguori
  0 siblings, 2 replies; 6+ messages in thread
From: Alexander Graf @ 2008-08-27 10:02 UTC (permalink / raw)
  To: qemu-devel


On Aug 24, 2008, at 1:27 AM, Anthony Liguori wrote:

> Revision: 5076
>          http://svn.sv.gnu.org/viewvc/? 
> view=rev&root=qemu&revision=5076
> Author:   aliguori
> Date:     2008-08-23 23:27:37 +0000 (Sat, 23 Aug 2008)
>
> Log Message:
> -----------
> VNC: Support for ExtendedKeyEvent client message
>
> This patch adds support for the ExtendedKeyEvent client message.   
> This message
> allows a client to send raw scan codes directly to the server.  If  
> the client
> and server are using the same keymap, then it's unnecessary to use  
> the '-k'
> option with QEMU when this extension is supported.
>
> This is extension is currently only implemented by gtk-vnc based  
> clients
> (gvncviewer, virt-manager, vinagre, etc.).
>
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> Modified Paths:
> --------------
>    trunk/vnc.c

[...snip...]


> 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).
The other one implements PNG compression for Tight.

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

[...snip...]

Thanks,

Alex

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
  2008-08-27 10:02 ` Alexander Graf
@ 2008-08-27 10:31   ` Daniel P. Berrange
  2008-08-28 20:32   ` Anthony Liguori
  1 sibling, 0 replies; 6+ messages in thread
From: Daniel P. Berrange @ 2008-08-27 10:31 UTC (permalink / raw)
  To: qemu-devel

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 :|

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
  2008-08-27 10:02 ` Alexander Graf
  2008-08-27 10:31   ` Daniel P. Berrange
@ 2008-08-28 20:32   ` Anthony Liguori
  2008-08-28 20:44     ` Christian Brunschen
  1 sibling, 1 reply; 6+ messages in thread
From: Anthony Liguori @ 2008-08-28 20:32 UTC (permalink / raw)
  To: Alexander Graf; +Cc: qemu-devel

Alexander Graf wrote:
>
> On Aug 24, 2008, at 1:27 AM, Anthony Liguori wrote:
>
> 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).

There's no need.  Simply do the conversion from Java keysyms => PC scan 
code using the same conversion routines that QEMU use within your Java 
client.

> The other one implements PNG compression for Tight.

I doubt you'll see a benefit from this.  PNG compression is paletted and 
compressed (just like GIF).  Tight already supports paletting and 
compression (using zlib).  Algorithmically, you're not going to get any 
benefit.

The reason tight supports jpeg compression is that jpeg is a lossy 
compression algorithm.  This is why jpeg compression can do better than 
the normal Tight algorithm (although you lose quality).

Regards,

Anthony Liguori

> I'd really love to have both of them standardized, but where do I need 
> to apply for an identifier ID?
>
> [...snip...]
>
> Thanks,
>
> Alex

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
  2008-08-28 20:32   ` Anthony Liguori
@ 2008-08-28 20:44     ` Christian Brunschen
  2008-08-28 21:47       ` Anthony Liguori
  0 siblings, 1 reply; 6+ messages in thread
From: Christian Brunschen @ 2008-08-28 20:44 UTC (permalink / raw)
  To: qemu-devel; +Cc: Alexander Graf


On 28 Aug 2008, at 21:32, Anthony Liguori wrote:

> Alexander Graf wrote:
>>
>> On Aug 24, 2008, at 1:27 AM, Anthony Liguori wrote:
>>
>> 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).
>
> There's no need.  Simply do the conversion from Java keysyms => PC  
> scan code using the same conversion routines that QEMU use within  
> your Java client.
>
>> The other one implements PNG compression for Tight.
>
> I doubt you'll see a benefit from this.  PNG compression is paletted  
> and compressed (just like GIF).

PNG does more than that. PNG supports full colour (up to 16 bits per  
colour component) including a full alpha channel, and has various  
filters that are applied to the image data to improve compression. Not  
to mention PNG is much more than GIF.

>  Tight already supports paletting and compression (using zlib).   
> Algorithmically, you're not going to get any benefit.

The PNG filters do improve compression over raw zlib compression of  
the pixels.

> The reason tight supports jpeg compression is that jpeg is a lossy  
> compression algorithm.  This is why jpeg compression can do better  
> than the normal Tight algorithm (although you lose quality).

As an aside - is the Tight protocol documented somewhere? In actual  
documentation rather than source code, I mean?

> Regards,

Best wishes,

> Anthony Liguori

// Christian Brunschen


>
>
>> I'd really love to have both of them standardized, but where do I  
>> need to apply for an identifier ID?
>>
>> [...snip...]
>>
>> Thanks,
>>
>> Alex
>
>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message
  2008-08-28 20:44     ` Christian Brunschen
@ 2008-08-28 21:47       ` Anthony Liguori
  0 siblings, 0 replies; 6+ messages in thread
From: Anthony Liguori @ 2008-08-28 21:47 UTC (permalink / raw)
  To: qemu-devel; +Cc: Alexander Graf

Christian Brunschen wrote:
>
>>
>> I doubt you'll see a benefit from this.  PNG compression is paletted 
>> and compressed (just like GIF).
>
> PNG does more than that. PNG supports full colour (up to 16 bits per 
> colour component) including a full alpha channel, and has various 
> filters that are applied to the image data to improve compression. Not 
> to mention PNG is much more than GIF.

Tight also has various filters to improve the compression.  The VNC 
protocol won't support 16-bit color components or an alpha channel so 
this isn't an advantage.

> As an aside - is the Tight protocol documented somewhere? In actual 
> documentation rather than source code, I mean?

Just the source code.  Although there's a big comment block that 
describes it as well as the rest of the VNC protocol docs do.

Regards,

Anthony Liguori

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-08-28 21:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-23 23:27 [Qemu-devel] [5076] VNC: Support for ExtendedKeyEvent client message Anthony Liguori
2008-08-27 10:02 ` Alexander Graf
2008-08-27 10:31   ` Daniel P. Berrange
2008-08-28 20:32   ` Anthony Liguori
2008-08-28 20:44     ` Christian Brunschen
2008-08-28 21:47       ` Anthony Liguori

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).