Hi All, We had added the patch to support the keymap with PVFB before. When the keymap is specified with vncfb, it converts it as a keyboard of the setting. When the keymap is not specified, it is converted as en-us. Configuration file : keymap="ja" It converts to keycode from keysym on the BackEnd side. The converted keycode is transmitted to the FrontEnd side. Next, the keycode is received on the FrontEnd side of PVFB, and it passes to GuestOS. It is not correctly converted because there is not the conversion processing of keyboard driver for the GuestOS. Therefore, the conversion processing by the keyboard driver is done on the BackEnd side now. However, I think that it should do this with xenkbd who is originally the driver on the FrontEnd side. It will be problem if the HVM domain is working on PVFB in the future. For HVM domain, The keycode that the keyboard driver on guest OS received from qemu-dm is converted. It will convert further in the HVM domain when converting it with PVFB beforehand, and a correct key cannot be input. This patch transplanted the conversion processing of the keyboard driver on the GuestOS side to xenkbd. We are not supporting the keymap for sdl because we do not understand sdl in detail. Signed-off-by: Takanori Kasai <kasai.takanori@jp.fujitsu.com> Signed-off-by: Junko Ichino <ichino.junko@jp.fujitsu.com> Best Regards, -- Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-Jul-02 12:09 UTC
Re: [Xen-devel] [Patch] Fix keymap support for PVFB.
On Mon, Jul 02, 2007 at 07:51:36PM +0900, Kasai Takanori wrote:> However, I think that it should do this with xenkbd who is originally the > driver on the FrontEnd side. > It will be problem if the HVM domain is working on PVFB in the future.I honestly can''t see HVM using the PVFB at any time in the forseeable future unless PVFB is further developed to not suck. ie being able to change the resolution / bpp would be a start for PVFB - something HVM can already do trivially.> For HVM domain, The keycode that the keyboard driver on guest OS received > from > qemu-dm is converted. > It will convert further in the HVM domain when converting it with PVFB > beforehand, and a correct key cannot be input. > > This patch transplanted the conversion processing of the keyboard driver on > the GuestOS side to xenkbd.This change looks very much like it breaks backwards compatability, doesn''t it ? eg If you use an old Dom0 daemon with new kernel you''ll not get any keymap conversion done. If you use a new Dom0 daemon with old kernel, you''ll get keymap conversion done twice. I don''t see any point in doing this change since it makes no difference to the functionality of paravirt guests & there''s no compelling need for PVFB in the HVM guests. 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 Daniel & Markus,> On Mon, Jul 02, 2007 at 07:51:36PM +0900, Kasai Takanori wrote: >> However, I think that it should do this with xenkbd who is originally the >> driver on the FrontEnd side. >> It will be problem if the HVM domain is working on PVFB in the future. > > I honestly can''t see HVM using the PVFB at any time in the forseeable future > unless PVFB is further developed to not suck. ie being able to change the > resolution / bpp would be a start for PVFB - something HVM can already do > trivially.Does it mean not to support making the HVM domain work on PVFB? I thought that it was going to work the HVM domain on PVFB before. Is my recognition wrong?> I don''t see any point in doing this change since it makes no difference to > the functionality of paravirt guests & there''s no compelling need for PVFB > in the HVM guests.If you do not work the HVM domain on PVFB, this change is not significant at all. Thanks, -- Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2007-Jul-03 14:10 UTC
Re: [Xen-devel] [Patch] Fix keymap support for PVFB.
On Tue, Jul 03, 2007 at 05:32:34PM +0900, Kasai Takanori wrote:> Hi Daniel & Markus, > > >On Mon, Jul 02, 2007 at 07:51:36PM +0900, Kasai Takanori wrote: > >>However, I think that it should do this with xenkbd who is originally the > >>driver on the FrontEnd side. > >>It will be problem if the HVM domain is working on PVFB in the future. > > > >I honestly can''t see HVM using the PVFB at any time in the forseeable > >future > >unless PVFB is further developed to not suck. ie being able to change the > >resolution / bpp would be a start for PVFB - something HVM can already do > >trivially. > > Does it mean not to support making the HVM domain work on PVFB?Sure you /could/ do it. I''m just saying there''s no real point in trying to though, since the HVM framebuffer has much more functionality than the paravirt framebuffer. ie why would you want make HVM use a worse framebuffer ? 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 Dan,> Sure you /could/ do it. I''m just saying there''s no real point in trying > to though, since the HVM framebuffer has much more functionality than > the paravirt framebuffer. ie why would you want make HVM use a worse > framebuffer ?Thank you for the reply. I guessed to work the HVM domain in the same platform, the function of PVFB is enhanced. Because my recognition was wrong, this patch is unnecessary. Thanks, -- Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel