Re: [PATCH] Paravirt framebuffer backend tools [2/5]

[Steven Smith <sos22-xen@srcf.ucam.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1459 bytes --]

> >>>--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> >>>+++ b/tools/xenfb/keymapping.c	Sat Sep 02 15:19:25 2006 -0400
> >>>@@ -0,0 +1,141 @@
> >>>+#include <stdint.h>
> >>>+#include <gdk/gdkkeysyms.h>
> >>>+#include <linux/input.h>
> >>>+
> >>>+uint32_t gdk_linux_mapping[0x10000] = {
> >>>+	[GDK_a] = KEY_A,
> >>>      
> >>This is kind of ugly.  Is there any chance it could be autogenerated?
> >>Also, where did 0x10000 come from?
> >>
> >>Also, depending on GTK just for the keymap table is a real pain.  Or
> >>is it already required for libvncserver?
> >>    
> >
> >libvncserver requires GTK.  And I don't know that there's really any
> >good way to auto-generate it unfortunately.  I somehow expect that
> >0x10000 came from "it'll be big enough" but Anthony would have to
> >confirm :-)
> That's the biggest that a GDK scan code can currently be.
Do you have a reference for that? Could the table grow in the future?

Steven
(who just spent a whole day tracking down a bug which turned out to be
an undersized lookup table combined with a lack of bounds checking)

> That way, we can use a simple indexed table.
> 
> Regards,
> 
> Anthony Liguori
> 
> >The mappings are unfortunately a bit of a fact of life since we have to
> >convert from what the X layer gets to what the kernel expects.  And the
> >two couldn't be farther from the same.  And then it's even more fun when
> >toolkits get involved.
> >  
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel