[RFC] keymap support for PVFB

[RFC] keymap support for PVFB

[Junko Ichino]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

Hi all,

My name is Junko Ichino.


Currently, Paravirtualized frame buffer is supporting only US keymap.

I'm trying to make a patch to support several keymaps 
for Paravirtualized frame buffer, which uses QEMU's keymap.

But, some special keys cannot be input in Japanese keymap.
For example, backslash and underscore.
I'm investigating this problem now. 
Where is the problem?


Thanks,
-
Junko Ichino


[-- Attachment #2: pvfb-keymap.patch --]
[-- Type: application/octet-stream, Size: 6615 bytes --]

# HG changeset patch
# User ichino.junko@jp.fujitsu.com
# Node ID d5f18d970be9bc0bb4d4c308f41bb32902babb2d
# Parent  367f0c6efe2178e26ba0194ca795ff098e22a80b
keymap support for vncfb

Signed-off-by: Junko Ichino <ichino.junko@jp.fujitsu.com>
Signed-off-by: Takanori Kasai <Kasai.Takanori@jp.fujitsu.com>
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>

diff -r 367f0c6efe21 -r d5f18d970be9 tools/xenfb/Makefile
--- a/tools/xenfb/Makefile	Sat Dec 23 21:32:05 2006 +0000
+++ b/tools/xenfb/Makefile	Thu Dec 28 11:27:14 2006 +0900
@@ -1,7 +1,7 @@ XEN_ROOT=../..
 XEN_ROOT=../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -I$(XEN_LIBXC) -I$(XEN_XENSTORE) -I$(XEN_ROOT)/linux-2.6-xen-sparse/include
+CFLAGS += -I$(XEN_LIBXC) -I$(XEN_XENSTORE) -I$(XEN_ROOT)/linux-2.6-xen-sparse/include -I$(XEN_ROOT)/tools/ioemu
 LDFLAGS += -L$(XEN_LIBXC) -L$(XEN_XENSTORE)
 
 INSTALL         = install
diff -r 367f0c6efe21 -r d5f18d970be9 tools/xenfb/vncfb.c
--- a/tools/xenfb/vncfb.c	Sat Dec 23 21:32:05 2006 +0000
+++ b/tools/xenfb/vncfb.c	Thu Dec 28 11:27:14 2006 +0900
@@ -11,142 +11,13 @@
 #include <xs.h>
 #include "xenfb.h"
 
-static int xk2linux[0x10000] = {
-	[XK_a] = KEY_A,
-	[XK_b] = KEY_B,
-	[XK_c] = KEY_C,
-	[XK_d] = KEY_D,
-	[XK_e] = KEY_E,
-	[XK_f] = KEY_F,
-	[XK_g] = KEY_G,
-	[XK_h] = KEY_H,
-	[XK_i] = KEY_I,
-	[XK_j] = KEY_J,
-	[XK_k] = KEY_K,
-	[XK_l] = KEY_L,
-	[XK_m] = KEY_M,
-	[XK_n] = KEY_N,
-	[XK_o] = KEY_O,
-	[XK_p] = KEY_P,
-	[XK_q] = KEY_Q,
-	[XK_r] = KEY_R,
-	[XK_s] = KEY_S,
-	[XK_t] = KEY_T,
-	[XK_u] = KEY_U,
-	[XK_v] = KEY_V,
-	[XK_w] = KEY_W,
-	[XK_x] = KEY_X,
-	[XK_y] = KEY_Y,
-	[XK_z] = KEY_Z,
-	[XK_A] = KEY_A,
-	[XK_B] = KEY_B,
-	[XK_C] = KEY_C,
-	[XK_D] = KEY_D,
-	[XK_E] = KEY_E,
-	[XK_F] = KEY_F,
-	[XK_G] = KEY_G,
-	[XK_H] = KEY_H,
-	[XK_I] = KEY_I,
-	[XK_J] = KEY_J,
-	[XK_K] = KEY_K,
-	[XK_L] = KEY_L,
-	[XK_M] = KEY_M,
-	[XK_N] = KEY_N,
-	[XK_O] = KEY_O,
-	[XK_P] = KEY_P,
-	[XK_Q] = KEY_Q,
-	[XK_R] = KEY_R,
-	[XK_S] = KEY_S,
-	[XK_T] = KEY_T,
-	[XK_U] = KEY_U,
-	[XK_V] = KEY_V,
-	[XK_W] = KEY_W,
-	[XK_X] = KEY_X,
-	[XK_Y] = KEY_Y,
-	[XK_Z] = KEY_Z,
-	[XK_0] = KEY_0,
-	[XK_1] = KEY_1,
-	[XK_2] = KEY_2,
-	[XK_3] = KEY_3,
-	[XK_4] = KEY_4,
-	[XK_5] = KEY_5,
-	[XK_6] = KEY_6,
-	[XK_7] = KEY_7,
-	[XK_8] = KEY_8,
-	[XK_9] = KEY_9,
-	[XK_Return] = KEY_ENTER,
-	[XK_BackSpace] = KEY_BACKSPACE,
-	[XK_Tab] = KEY_TAB,
-	[XK_Pause] = KEY_PAUSE,
-	[XK_Delete] = KEY_DELETE,
-	[XK_slash] = KEY_SLASH,
-	[XK_minus] = KEY_MINUS,
-	[XK_equal] = KEY_EQUAL,
-	[XK_Escape] = KEY_ESC,
-	[XK_braceleft] = KEY_LEFTBRACE,
-	[XK_braceright] = KEY_RIGHTBRACE,
-	[XK_bracketleft] = KEY_LEFTMETA,
-	[XK_bracketright] = KEY_RIGHTMETA,
-	[XK_Control_L] = KEY_LEFTCTRL,
-	[XK_Control_R] = KEY_RIGHTCTRL,
-	[XK_Shift_L] = KEY_LEFTSHIFT,
-	[XK_Shift_R] = KEY_RIGHTSHIFT,
-	[XK_Alt_L] = KEY_LEFTALT,
-	[XK_Alt_R] = KEY_RIGHTALT,
-	[XK_semicolon] = KEY_SEMICOLON, 
-	[XK_apostrophe] = KEY_APOSTROPHE,
-	[XK_grave] = KEY_GRAVE,
-	[XK_backslash] = KEY_BACKSLASH,
-	[XK_comma] = KEY_COMMA,
-	[XK_period] = KEY_DOT,
-	[XK_space] = KEY_SPACE,
-	[XK_Caps_Lock] = KEY_CAPSLOCK,
-	[XK_Num_Lock] = KEY_NUMLOCK,
-	[XK_Scroll_Lock] = KEY_SCROLLLOCK,
-	[XK_Sys_Req] = KEY_SYSRQ,
-	[XK_Linefeed] = KEY_LINEFEED,
-	[XK_Home] = KEY_HOME,
-	[XK_Pause] = KEY_PAUSE,
-	[XK_F1] = KEY_F1,
-	[XK_F2] = KEY_F2,
-	[XK_F3] = KEY_F3,
-	[XK_F4] = KEY_F4,
-	[XK_F5] = KEY_F5,
-	[XK_F6] = KEY_F6,
-	[XK_F7] = KEY_F7,
-	[XK_F8] = KEY_F8,
-	[XK_F9] = KEY_F9,
-	[XK_F10] = KEY_F10,
-	[XK_F11] = KEY_F11,
-	[XK_F12] = KEY_F12,
-	[XK_Up] = KEY_UP,
-	[XK_Page_Up] = KEY_PAGEUP,
-	[XK_Left] = KEY_LEFT,
-	[XK_Right] = KEY_RIGHT,
-	[XK_End] = KEY_END,
-	[XK_Down] = KEY_DOWN,
-	[XK_Page_Down] = KEY_PAGEDOWN,
-	[XK_Insert] = KEY_INSERT, 
-	[XK_colon] = KEY_SEMICOLON,
-	[XK_quotedbl] = KEY_APOSTROPHE,
-	[XK_less] = KEY_COMMA,
-	[XK_greater] = KEY_DOT,
-	[XK_question] = KEY_SLASH,
-	[XK_bar] = KEY_BACKSLASH,
-	[XK_asciitilde] = KEY_GRAVE,
-	[XK_exclam] = KEY_1,
-	[XK_at] = KEY_2,
-	[XK_numbersign] = KEY_3,
-	[XK_dollar] = KEY_4,
-	[XK_percent] = KEY_5,
-	[XK_asciicircum] = KEY_6,
-	[XK_ampersand] = KEY_7,
-	[XK_asterisk] = KEY_8,
-	[XK_parenleft] = KEY_9,
-	[XK_parenright] = KEY_0,
-	[XK_underscore] = KEY_MINUS,
-	[XK_plus] = KEY_EQUAL,
-};
+#define qemu_mallocz(size) calloc(1, (size))
+#include "config-host.h"
+static const char *bios_dir = CONFIG_QEMU_SHAREDIR;
+#include "vnc_keysym.h"
+#include "keymaps.c"
+
+static void *kbd_layout;
 
 static int btnmap[] = {
 	BTN_LEFT, BTN_MIDDLE, BTN_RIGHT, BTN_FORWARD, BTN_BACK
@@ -165,13 +36,16 @@ static void on_kbd_event(rfbBool down, r
 	 */
 	rfbScreenInfoPtr server = cl->screen;
 	struct xenfb *xenfb = server->screenData;
-	if (keycode >= sizeof(xk2linux) / sizeof(*xk2linux))
+
+	if( keycode >= 'A' && keycode <= 'Z' )
+		keycode += 'a' - 'A';
+
+	int scancode = keysym2scancode(kbd_layout, keycode);
+	if (scancode == 0)
 		return;
-	if (xk2linux[keycode] == 0)
-		return;
-	if (xenfb_send_key(xenfb, down, xk2linux[keycode]) < 0)
+	if (xenfb_send_key(xenfb, down, scancode) < 0)
 		fprintf(stderr, "Key %d %s lost (%s)\n",
-			xk2linux[keycode], down ? "down" : "up",
+			scancode, down ? "down" : "up",
 			strerror(errno));
 }
 
@@ -305,6 +179,7 @@ static struct option options[] = {
 	{ "title", 1, NULL, 't' },
 	{ "unused", 0, NULL, 'u' },
 	{ "listen", 1, NULL, 'l' },
+	{ "keymap", 1, NULL, 'k' },
 	{ NULL }
 };
 
@@ -318,6 +193,7 @@ int main(int argc, char **argv)
 	int domid = -1, port = -1;
 	char *title = NULL;
 	char *listen = NULL;
+	char *keymap = NULL;
 	bool unused = false;
 	int opt;
 	struct xenfb *xenfb;
@@ -331,7 +207,7 @@ int main(int argc, char **argv)
 
 	vncpasswd[0] = '\0';
 
-	while ((opt = getopt_long(argc, argv, "d:p:t:u", options,
+	while ((opt = getopt_long(argc, argv, "d:p:t:uk:", options,
 				  NULL)) != -1) {
 		switch (opt) {
                 case 'd':
@@ -359,6 +235,9 @@ int main(int argc, char **argv)
                 case 'l':
 			listen = strdup(optarg);
 			break;
+                case 'k':
+			keymap = strdup(optarg);
+			break;
 		case '?':
 			exit(1);
                 }
@@ -378,7 +257,12 @@ int main(int argc, char **argv)
 		fprintf(stderr, "Invalid port specified\n");
 		exit(1);
         }
-            
+
+	if (keymap == NULL){
+		keymap = "en-us";
+	}
+	kbd_layout = init_keyboard_layout(keymap);
+
 	fake_argv[2] = portstr;
 
         if (title != NULL)

[-- Attachment #3: tools-build.patch --]
[-- Type: application/octet-stream, Size: 1588 bytes --]

# HG changeset patch
# User kasai.takanori@jp.fujitsu.com
# Node ID fd6dad0fefc84cdb5e4390f204a80cf5c3be7bcb
# Parent  d5f18d970be9bc0bb4d4c308f41bb32902babb2d
The build order change for keyboard selection of pvfb

Signed-off-by: Takanori Kasai <Kasai.Takanori@jp.fujitsu.com>
Signed-off-by: Junko Ichino <ichino.junko@jp.fujitsu.com>
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>

diff -r d5f18d970be9 -r fd6dad0fefc8 tools/Makefile
--- a/tools/Makefile	Thu Dec 28 11:27:14 2006 +0900
+++ b/tools/Makefile	Thu Dec 28 11:31:05 2006 +0900
@@ -19,8 +19,9 @@ SUBDIRS-y += libaio
 SUBDIRS-y += libaio
 SUBDIRS-y += blktap
 SUBDIRS-y += libfsimage
-SUBDIRS-$(XENFB_TOOLS) += xenfb
 SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen
+
+POST_SUBDIRS-$(XENFB_TOOLS) += xenfb
 
 # These don't cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
@@ -34,6 +35,9 @@ all: check
 		$(MAKE) -C $$subdir $@; \
 	done
 	$(MAKE) ioemu
+	@set -e; for subdir in $(POST_SUBDIRS-y); do \
+		$(MAKE) -C $$subdir $@; \
+	done
 
 .PHONY: install
 install: check
@@ -41,6 +45,9 @@ install: check
 		$(MAKE) -C $$subdir $@; \
 	done
 	$(MAKE) ioemuinstall
+	@set -e; for subdir in $(POST_SUBDIRS-y); do \
+		$(MAKE) -C $$subdir $@; \
+	done
 	$(INSTALL_DIR) -p $(DESTDIR)/var/xen/dump
 	$(INSTALL_DIR) -p $(DESTDIR)/var/log/xen
 
@@ -50,6 +57,9 @@ clean: check_clean
 		$(MAKE) -C $$subdir $@; \
 	done
 	$(MAKE) ioemuclean
+	@set -e; for subdir in $(POST_SUBDIRS-y); do \
+		$(MAKE) -C $$subdir $@; \
+	done
 
 .PHONY: distclean
 distclean: clean

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

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

Re: [RFC] keymap support for PVFB

[Ewan Mellor]

On Thu, Dec 28, 2006 at 01:11:29PM +0900, Junko Ichino wrote:

> Hi all,
> 
> My name is Junko Ichino.
> 
> 
> Currently, Paravirtualized frame buffer is supporting only US keymap.
> 
> I'm trying to make a patch to support several keymaps 
> for Paravirtualized frame buffer, which uses QEMU's keymap.
> 
> But, some special keys cannot be input in Japanese keymap.
> For example, backslash and underscore.
> I'm investigating this problem now. 
> Where is the problem?

This patch to xen-unstable was committed on Nov 8, and was said to fix
Japanese backslash etc, by adding those keys to the keymap:

# HG changeset patch
# User kasai.takanori@jp.fujitsu.com
# Date 1162978686 0
# Node ID ea1ffa51b4121d36cffdc90276378a6ed334c2cc
# Parent  edd592c823a520d4072a95ac39beb2012c05321e
Add the Japanese keymap for VNC Server.

Signed-off-by: Takanori Kasai < kasai.takanori@jp.fujitsu.com >

diff -r edd592c823a5 -r ea1ffa51b412 tools/ioemu/keymaps/ja
--- a/tools/ioemu/keymaps/ja    Thu Nov 02 23:05:24 2006 +0000
+++ b/tools/ioemu/keymaps/ja    Wed Nov 08 09:38:06 2006 +0000
@@ -102,3 +102,6 @@ Henkan_Mode 0x79
 Henkan_Mode 0x79
 Katakana 0x70
 Muhenkan 0x7b
+Henkan_Mode_Real 0x79
+Henkan_Mode_Ultra 0x79
+backslash_ja 0x73
diff -r edd592c823a5 -r ea1ffa51b412 tools/ioemu/vnc_keysym.h
--- a/tools/ioemu/vnc_keysym.h  Thu Nov 02 23:05:24 2006 +0000
+++ b/tools/ioemu/vnc_keysym.h  Wed Nov 08 09:38:06 2006 +0000
@@ -271,5 +271,15 @@ static name2keysym_t name2keysym[]={
 {"Num_Lock", 0xff7f},    /* XK_Num_Lock */
 {"Pause", 0xff13},       /* XK_Pause */
 {"Escape", 0xff1b},      /* XK_Escape */
+
+    /* localized keys */
+{"BackApostrophe", 0xff21},
+{"Muhenkan", 0xff22},
+{"Katakana", 0xff25},
+{"Zenkaku_Hankaku", 0xff29},
+{"Henkan_Mode_Real", 0xff23},
+{"Henkan_Mode_Ultra", 0xff3e},
+{"backslash_ja", 0xffa5},
+
 {0,0},
 };


Are you using this patch?

Ewan.

Re: [RFC] keymap support for PVFB

[Kasai Takanori]

Hi Ewan,

> This patch to xen-unstable was committed on Nov 8, and was said to fix
> Japanese backslash etc, by adding those keys to the keymap:
>
> Are you using this patch?

When testing, we are using this patch. 

Conversion uses the function of qemu-dm. 
The result of conversion has been passed to the PVFB. 

However, some special keys cannot be input in Japanese keymap.
Are other conversions necessary before it passes it to PVFB?

Thanks,

--
Takanori Kasai

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Ewan,

Thank you for your reply.


The patch committed on Nov 8 is the one for qemu-dm. 

Paravirtualized frame buffer is not supporting Japanese keymap.
I'm trying to make a patch for Paravirtualized frame buffer. 


Thanks,
-
Junko Ichino


----- Original Message ----- 
From: "Ewan Mellor" <ewan@xensource.com>
To: "Junko Ichino" <ichino.junko@jp.fujitsu.com>
Cc: <Xen-devel@lists.xensource.com>
Sent: Friday, December 29, 2006 1:02 AM
Subject: Re: [Xen-devel] [RFC] keymap support for PVFB


> On Thu, Dec 28, 2006 at 01:11:29PM +0900, Junko Ichino wrote:
> 
>> Hi all,
>> 
>> My name is Junko Ichino.
>> 
>> 
>> Currently, Paravirtualized frame buffer is supporting only US keymap.
>> 
>> I'm trying to make a patch to support several keymaps 
>> for Paravirtualized frame buffer, which uses QEMU's keymap.
>> 
>> But, some special keys cannot be input in Japanese keymap.
>> For example, backslash and underscore.
>> I'm investigating this problem now. 
>> Where is the problem?
> 
> This patch to xen-unstable was committed on Nov 8, and was said to fix
> Japanese backslash etc, by adding those keys to the keymap:
> 
> # HG changeset patch
> # User kasai.takanori@jp.fujitsu.com
> # Date 1162978686 0
> # Node ID ea1ffa51b4121d36cffdc90276378a6ed334c2cc
> # Parent  edd592c823a520d4072a95ac39beb2012c05321e
> Add the Japanese keymap for VNC Server.
> 
> Signed-off-by: Takanori Kasai < kasai.takanori@jp.fujitsu.com >
> 
> diff -r edd592c823a5 -r ea1ffa51b412 tools/ioemu/keymaps/ja
> --- a/tools/ioemu/keymaps/ja    Thu Nov 02 23:05:24 2006 +0000
> +++ b/tools/ioemu/keymaps/ja    Wed Nov 08 09:38:06 2006 +0000
> @@ -102,3 +102,6 @@ Henkan_Mode 0x79
> Henkan_Mode 0x79
> Katakana 0x70
> Muhenkan 0x7b
> +Henkan_Mode_Real 0x79
> +Henkan_Mode_Ultra 0x79
> +backslash_ja 0x73
> diff -r edd592c823a5 -r ea1ffa51b412 tools/ioemu/vnc_keysym.h
> --- a/tools/ioemu/vnc_keysym.h  Thu Nov 02 23:05:24 2006 +0000
> +++ b/tools/ioemu/vnc_keysym.h  Wed Nov 08 09:38:06 2006 +0000
> @@ -271,5 +271,15 @@ static name2keysym_t name2keysym[]={
> {"Num_Lock", 0xff7f},    /* XK_Num_Lock */
> {"Pause", 0xff13},       /* XK_Pause */
> {"Escape", 0xff1b},      /* XK_Escape */
> +
> +    /* localized keys */
> +{"BackApostrophe", 0xff21},
> +{"Muhenkan", 0xff22},
> +{"Katakana", 0xff25},
> +{"Zenkaku_Hankaku", 0xff29},
> +{"Henkan_Mode_Real", 0xff23},
> +{"Henkan_Mode_Ultra", 0xff3e},
> +{"backslash_ja", 0xffa5},
> +
> {0,0},
> };
> 
> 
> Are you using this patch?
> 
> Ewan.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

"Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:

> Hi all,
>
> My name is Junko Ichino.
>
>
> Currently, Paravirtualized frame buffer is supporting only US keymap.
>
> I'm trying to make a patch to support several keymaps for
> Paravirtualized frame buffer, which uses QEMU's keymap.

Cool.

In the longer run, I'd like to replace LibVNCServer by code from QEMU
alltogether.  In the short run, working keymaps are quite welcome.

> But, some special keys cannot be input in Japanese keymap.
> For example, backslash and underscore.
> I'm investigating this problem now. Where is the problem?

I don't have such a keyboard.  Can you provide details?  `Doesn't
work' isn't helpful.  What exactly happens?  For each key that doesn't
work, what's the scan code and X keysymbol (find out with xev)?

Error checking is missing: -k nonexistant dumps core.

Re: [RFC] keymap support for PVFB

[Gerd Hoffmann]

  Hi,

> In the longer run, I'd like to replace LibVNCServer by code from QEMU
> alltogether.  In the short run, working keymaps are quite welcome.

Hmm, so this works by telling the vnc server side which keymap the
client is using I guess?

I've tried to tackle the same issue by hacking the vnc client side to
send us keysyms no matter what the local keyboard mapping is.  So I can
have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
nevertheless and passes the correct scancodes to the guest OS.

Problem with that is that I don't have keysyms to send for keys which
are not present on a us keyboard.  That affects the 102th/105th key on
i18n keyboards ("<>|" key on a german keyboard), and I think japanese
keyboards have a few more keys which are just dead ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

Gerd Hoffmann <kraxel@suse.de> writes:

>   Hi,
>
>> In the longer run, I'd like to replace LibVNCServer by code from QEMU
>> alltogether.  In the short run, working keymaps are quite welcome.
>
> Hmm, so this works by telling the vnc server side which keymap the
> client is using I guess?

Exactly.  Not ideal, but better than nothing.

> I've tried to tackle the same issue by hacking the vnc client side to
> send us keysyms no matter what the local keyboard mapping is.  So I can
> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
> nevertheless and passes the correct scancodes to the guest OS.

You mean scan codes, don't you?  Key symbols are the XK_a and so
forth.

Passing scan codes in addition to key symbols makes sense.  sdlfb
works that way; it gets both from SDL, then maps the scan code to the
vkbd protocol's key encoding (Linux input layer key codes).

Would you mind sharing your code when it's ready?

> Problem with that is that I don't have keysyms to send for keys which
> are not present on a us keyboard.  That affects the 102th/105th key on
> i18n keyboards ("<>|" key on a german keyboard), and I think japanese
> keyboards have a few more keys which are just dead ...

sdlfb.c maps 105 keys.

For additional keys, have a user of the keyboard in question find the
scan code with xev.

Re: [RFC] keymap support for PVFB

[Gerd Hoffmann]

  Hi,

>> I've tried to tackle the same issue by hacking the vnc client side to
>> send us keysyms no matter what the local keyboard mapping is.  So I can
>> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
>> nevertheless and passes the correct scancodes to the guest OS.
> 
> You mean scan codes, don't you?  Key symbols are the XK_a and so
> forth.

No, keysyms.  This is what the vnc protocol uses, so there is no way
around that, unfortunaly.  It takes the X11 keycodes and translates
these to us keymap keysyms using a buildin table, then sends them.  So
for the server side (from vnc protocol view, i.e. qemu-dm or vnc-fb) it
looks like a vnc client with us keyboard.

> Passing scan codes in addition to key symbols makes sense.

Does the vnc protocol allow that?  I don't think so :-(

> Would you mind sharing your code when it's ready?

http://www.suse.de/~kraxel/xen/, the vnc client in the "xenwatch" package.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

Gerd Hoffmann <kraxel@suse.de> writes:

>   Hi,
>
>>> I've tried to tackle the same issue by hacking the vnc client side to
>>> send us keysyms no matter what the local keyboard mapping is.  So I can
>>> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
>>> nevertheless and passes the correct scancodes to the guest OS.
>> 
>> You mean scan codes, don't you?  Key symbols are the XK_a and so
>> forth.
>
> No, keysyms.  This is what the vnc protocol uses, so there is no way
> around that, unfortunaly.  It takes the X11 keycodes and translates
> these to us keymap keysyms using a buildin table, then sends them.  So
> for the server side (from vnc protocol view, i.e. qemu-dm or vnc-fb) it
> looks like a vnc client with us keyboard.
>
>> Passing scan codes in addition to key symbols makes sense.
>
> Does the vnc protocol allow that?  I don't think so :-(

Broken as designed...

Your hack has the advantage that you don't configure the client keymap
into the server, and therefore don't have to kick the server whenever
the client keymap changes.  But when your client receives a funky key
that ordinary US keyboards don't have, you don't have the key symbol
for it.

Hmm, can we make one up then?  I mean it's a hack to begin with, why
not put another hack on top of it?  As long as every key gets its own
key symbol, and the made-up ones don't screw up servers that don't
know of this hack...

>> Would you mind sharing your code when it's ready?
>
> http://www.suse.de/~kraxel/xen/, the vnc client in the "xenwatch" package.

Thanks.

Re: [RFC] keymap support for PVFB

[Gerd Hoffmann]

Markus Armbruster wrote:

>>> Passing scan codes in addition to key symbols makes sense.
>> Does the vnc protocol allow that?  I don't think so :-(
> 
> Broken as designed...
> 
> Your hack has the advantage that you don't configure the client keymap
> into the server, and therefore don't have to kick the server whenever
> the client keymap changes.

Yep.  You can even connect two clients with different local keymaps and
it still works ;)

> But when your client receives a funky key
> that ordinary US keyboards don't have, you don't have the key symbol
> for it.

That is exactly the drawback ...

> Hmm, can we make one up then?  I mean it's a hack to begin with, why
> not put another hack on top of it?  As long as every key gets its own
> key symbol, and the made-up ones don't screw up servers that don't
> know of this hack...

We can try that.  For the 102th/105th key on i18n keyboards we likely
have to create something.  For the extra keys the japanese keyboards
have we maybe can simply send the existing keysyms for these keys
(assuming the scancodes for these keys are unique, i.e. used on japanese
keyboards only).

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: [RFC] keymap support for PVFB

[Daniel P. Berrange]

On Fri, Jan 12, 2007 at 09:15:21AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >> I've tried to tackle the same issue by hacking the vnc client side to
> >> send us keysyms no matter what the local keyboard mapping is.  So I can
> >> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
> >> nevertheless and passes the correct scancodes to the guest OS.
> > 
> > You mean scan codes, don't you?  Key symbols are the XK_a and so
> > forth.
> 
> No, keysyms.  This is what the vnc protocol uses, so there is no way
> around that, unfortunaly.  It takes the X11 keycodes and translates
> these to us keymap keysyms using a buildin table, then sends them.  So
> for the server side (from vnc protocol view, i.e. qemu-dm or vnc-fb) it
> looks like a vnc client with us keyboard.
> 
> > Passing scan codes in addition to key symbols makes sense.
> 
> Does the vnc protocol allow that?  I don't think so :-(

No, but there's no reason we couldn't come up with an extension. Anthony
has already done similar to allow passing of relative mouse co-ords instead
of absolute co-ords. Extensions are opt-in, so unless the client has support
they'd carry on with normal keysyms, but a client that understood the new
extension could switch to scan codes. The important thing is talking to
upstream VNC mailing lists about any proposed extension to get buy-in so
some of the popular clients implement it. As far as i'm concerned, I'm more
than happy to extend the virt-manager  VNC client if it could enable better
internationalized keyboard handling.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Markus,

Thank you for your reply.

The key that doesn't work is \, | , _ , arrow (UP, DOWN, LEFT, and RIGHT),
Hankaku/Zenkaku , Muhenkan , Katakana/Hiragana and so on.
(When you do not know about Hankaku/Zenkaku etc., please question the 
Japanese
who is in near.)

When I looked at atkbd.c, it seemed to change scancode again.
I put in the same conversion immediately after changing into scancode
from keysym by PVFB.
However, it failed.

I investigate this problem continuously.

Thanks,
-----
Junko Ichino


----- Original Message ----- 
From: "Markus Armbruster" <armbru@redhat.com>
To: "Junko Ichino" <ichino.junko@jp.fujitsu.com>
Cc: <Xen-devel@lists.xensource.com>
Sent: Thursday, January 11, 2007 5:18 AM
Subject: Re: [Xen-devel] [RFC] keymap support for PVFB


> "Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:
>
>> Hi all,
>>
>> My name is Junko Ichino.
>>
>>
>> Currently, Paravirtualized frame buffer is supporting only US keymap.
>>
>> I'm trying to make a patch to support several keymaps for
>> Paravirtualized frame buffer, which uses QEMU's keymap.
>
> Cool.
>
> In the longer run, I'd like to replace LibVNCServer by code from QEMU
> alltogether.  In the short run, working keymaps are quite welcome.
>
>> But, some special keys cannot be input in Japanese keymap.
>> For example, backslash and underscore.
>> I'm investigating this problem now. Where is the problem?
>
> I don't have such a keyboard.  Can you provide details?  `Doesn't
> work' isn't helpful.  What exactly happens?  For each key that doesn't
> work, what's the scan code and X keysymbol (find out with xev)?
>
> Error checking is missing: -k nonexistant dumps core.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel 

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

"Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:

> Hi Markus,
>
> Thank you for your reply.
>
> The key that doesn't work is \, | , _ , arrow (UP, DOWN, LEFT, and RIGHT),
> Hankaku/Zenkaku , Muhenkan , Katakana/Hiragana and so on.
> (When you do not know about Hankaku/Zenkaku etc., please question the
> Japanese
> who is in near.)
>
> When I looked at atkbd.c, it seemed to change scancode again.
> I put in the same conversion immediately after changing into scancode
> from keysym by PVFB.
> However, it failed.
>
> I investigate this problem continuously.

How can we help?

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Markus,

I checked that the result of conversion had passed PVFB and gone out of
fbflont.
I think that the conversion by the OS side will go wrong.

If you know how it will pass from guest OS to guest OS's X,
please give me some comments.

When I input "\",  following message a display each modules

PVFB:
keycode 92(0x5C) -> scancode 115

xev:
keycode 176   keysym 0x0, NoSymbol


Thanks,
-
Junko Ichino


----- Original Message ----- 
From: "Markus Armbruster" <armbru@redhat.com>
To: "Junko Ichino" <ichino.junko@jp.fujitsu.com>
Cc: <Xen-devel@lists.xensource.com>
Sent: Friday, January 12, 2007 2:54 AM
Subject: Re: [Xen-devel] [RFC] keymap support for PVFB


> "Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:
>
>> Hi Markus,
>>
>> Thank you for your reply.
>>
>> The key that doesn't work is \, | , _ , arrow (UP, DOWN, LEFT, and 
>> RIGHT),
>> Hankaku/Zenkaku , Muhenkan , Katakana/Hiragana and so on.
>> (When you do not know about Hankaku/Zenkaku etc., please question the
>> Japanese
>> who is in near.)
>>
>> When I looked at atkbd.c, it seemed to change scancode again.
>> I put in the same conversion immediately after changing into scancode
>> from keysym by PVFB.
>> However, it failed.
>>
>> I investigate this problem continuously.
>
> How can we help?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel 

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

"Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:

> Hi Markus,
>
> I checked that the result of conversion had passed PVFB and gone out of
> fbflont.
> I think that the conversion by the OS side will go wrong.
>
> If you know how it will pass from guest OS to guest OS's X,
> please give me some comments.
>
> When I input "\",  following message a display each modules
>
> PVFB:
> keycode 92(0x5C) -> scancode 115
>
> xev:
> keycode 176   keysym 0x0, NoSymbol

Let's make sure I got the facts right:

Your vncfb backend receives key symbol 92 (XK_backslash) from your VNC
viewer.

Your vncfb translates that to Linux input layer key code 115.

Is that what happens?

Key code 115 is KEY_VOLUMEUP.  That's wrong.  You want 43
(KEY_BACKSLASH) instead.  Bug in your translation table?

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Markus,

PVFB does the same conversion (keysym->scancode) as qemu-dm. 
Conversion is correctly done in qemu-dm of original, 
and "\" is displayed on the screen. 

When keysym was 92,  I handed 43 compulsorily to scancode.
The result is as follows. 

 PVFB:
 keycode 92(0x5C) -> scancode 43

 xev:
 keycode 51    keysym 0x5d, bracketright


Thanks,
-
Junko Ichino


----- Original Message ----- 
From: "Markus Armbruster" <armbru@redhat.com>
To: "Junko Ichino" <ichino.junko@jp.fujitsu.com>
Cc: <Xen-devel@lists.xensource.com>
Sent: Wednesday, January 17, 2007 4:48 PM
Subject: Re: [Xen-devel] [RFC] keymap support for PVFB


> "Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:
> 
>> Hi Markus,
>>
>> I checked that the result of conversion had passed PVFB and gone out of
>> fbflont.
>> I think that the conversion by the OS side will go wrong.
>>
>> If you know how it will pass from guest OS to guest OS's X,
>> please give me some comments.
>>
>> When I input "\",  following message a display each modules
>>
>> PVFB:
>> keycode 92(0x5C) -> scancode 115
>>
>> xev:
>> keycode 176   keysym 0x0, NoSymbol
> 
> Let's make sure I got the facts right:
> 
> Your vncfb backend receives key symbol 92 (XK_backslash) from your VNC
> viewer.
> 
> Your vncfb translates that to Linux input layer key code 115.
> 
> Is that what happens?
> 
> Key code 115 is KEY_VOLUMEUP.  That's wrong.  You want 43
> (KEY_BACKSLASH) instead.  Bug in your translation table?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

"Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:

> Hi Markus,
>
> PVFB does the same conversion (keysym->scancode) as
> qemu-dm. Conversion is correctly done in qemu-dm of original, and "\"
> is displayed on the screen.
>
> When keysym was 92,  I handed 43 compulsorily to scancode.
> The result is as follows.
>
> PVFB:
> keycode 92(0x5C) -> scancode 43
>
> xev:
> keycode 51    keysym 0x5d, bracketright

Do you have the same keymap configured in the guest and on the machine
running the viewer?

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Markus,

> Do you have the same keymap configured in the guest and on the machine
> running the viewer?

Yes,
I am setting both keymap to "jp106". 


Thanks,
-
Junko Ichino

Re: [RFC] keymap support for PVFB

[Kasai Takanori]

HI Markus,

>> I checked that the result of conversion had passed PVFB and gone out of
>> fbflont.
>> I think that the conversion by the OS side will go wrong.
>>
>> If you know how it will pass from guest OS to guest OS's X,
>> please give me some comments.
>>
>> When I input "\",  following message a display each modules
>>
>> PVFB:
>> keycode 92(0x5C) -> scancode 115
>>
>> xev:
>> keycode 176   keysym 0x0, NoSymbol

The conversion result of scancode is the same as qemu-dm. 
Because qemu-dm function is used. 

However, '/' character can be input on HVM domain. 
Of course, keyboard setting of the HVM domain is jp106.
Therefore, it is thought that it converts it by the driver on GuestOS. 

Is similar conversion necessary there?

Please tell us if you understand the part that has been converted. 

Thanks,

--
Takanori Kasai

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

Let's get the facts, all the facts, and nothing but the facts :)

For the keystroke in question:

1. On the same machine and X display that you use to run the VNC
   viewer: use xev to figure out key symbol and scan code.

2. Instrument the vncfb backend to display the key symbol received by
   on_kbd_event() and the Linux input layer key code passed to the
   frontend.

3. Instrument the frontend to display the key symbol received from the
   backend and stuffed into the input layer (input_handler() in
   xenkbd.c).

4. In the guest, with the X display on the PVFB: use xev to figure out
   key symbol and scan code.

Do you need help with any of that?

Re: [RFC] keymap support for PVFB

[Junko Ichino]

Hi Markus,


> 1. On the same machine and X display that you use to run the VNC
>   viewer: use xev to figure out key symbol and scan code.
> 
> 2. Instrument the vncfb backend to display the key symbol received by
>   on_kbd_event() and the Linux input layer key code passed to the
>   frontend.
> 
> 3. Instrument the frontend to display the key symbol received from the
>   backend and stuffed into the input layer (input_handler() in
>   xenkbd.c).
> 
> 4. In the guest, with the X display on the PVFB: use xev to figure out
>   key symbol and scan code.

I tested. 
The result is as follows. 
("\" When inputting it. )


 1.               2.                 3.                   4.
 keycode/keysym   keycode/scancode   event->key.keycode   keycode/keysym

   133 / 0x5c      92(0x5c)/ 115            115             176 /  0x0
   211 / 0x5c


I thought that conversion was something necessary again. 
Then, I saw atkbd.c again. 
When I saw atkbd.c before, I thought that I used only atkbd_set2_keycode. 
However, not only atkbd_set2_keycode but atkbd_unxlate_table was used 
in practice.

Then, I put the same conversion in vncfb.c. 
I was able to input "\". 

Thanks,
-
Junko Ichino

Re: [RFC] keymap support for PVFB

[Markus Armbruster]

"Junko Ichino" <ichino.junko@jp.fujitsu.com> writes:

[...]
> I thought that conversion was something necessary again. Then, I saw
> atkbd.c again. When I saw atkbd.c before, I thought that I used only
> atkbd_set2_keycode. However, not only atkbd_set2_keycode but
> atkbd_unxlate_table was used in practice.
>
> Then, I put the same conversion in vncfb.c. I was able to input "\".

Does that mean you got it working?


> Thanks,
> -
> Junko Ichino

My pleasure :)

Re: [RFC] keymap support for PVFB

[Bruce Rogers]

Correct me if I'm wrong, but I thought the default *was* to use relative
mouse coordinates.  And can you point me to Anthony's work?

- Thanks

>>> "Daniel P. Berrange" <berrange@redhat.com> 01/12/07 5:16 AM >>>
On Fri, Jan 12, 2007 at 09:15:21AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> >> I've tried to tackle the same issue by hacking the vnc client side to
> >> send us keysyms no matter what the local keyboard mapping is.  So I can
> >> have any keyboard map loaded on the host, qemu-dm/vncfb sees us keysyms
> >> nevertheless and passes the correct scancodes to the guest OS.
> > 
> > You mean scan codes, don't you?  Key symbols are the XK_a and so
> > forth.
> 
> No, keysyms.  This is what the vnc protocol uses, so there is no way
> around that, unfortunaly.  It takes the X11 keycodes and translates
> these to us keymap keysyms using a buildin table, then sends them.  So
> for the server side (from vnc protocol view, i.e. qemu-dm or vnc-fb) it
> looks like a vnc client with us keyboard.
> 
> > Passing scan codes in addition to key symbols makes sense.
> 
> Does the vnc protocol allow that?  I don't think so :-(

No, but there's no reason we couldn't come up with an extension. Anthony
has already done similar to allow passing of relative mouse co-ords instead
of absolute co-ords. Extensions are opt-in, so unless the client has support
they'd carry on with normal keysyms, but a client that understood the new
extension could switch to scan codes. The important thing is talking to
upstream VNC mailing lists about any proposed extension to get buy-in so
some of the popular clients implement it. As far as i'm concerned, I'm more
than happy to extend the virt-manager  VNC client if it could enable better
internationalized keyboard handling.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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

Re: [RFC] keymap support for PVFB

[Daniel P. Berrange]

On Fri, Jan 12, 2007 at 05:35:27AM -0700, Bruce Rogers wrote:
> Correct me if I'm wrong, but I thought the default *was* to use relative
> mouse coordinates.  And can you point me to Anthony's work?

Nope, the default for the VNC protocol is absolute mouse events.

http://tocm.wikidot.com/pointertypechange

http://lists.gnu.org/archive/html/qemu-devel/2007-01/msg00063.html

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|