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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"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
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"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
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"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, NoSymbolLet''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
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"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, bracketrightDo you have the same keymap configured in the guest and on the machine running the viewer? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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, NoSymbolThe 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"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 IchinoMy pleasure :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel