Summary of changes: * Use xenbus_device API. Some xm configuration magic is still missing, see below. * Negotiate features through Xen Store. * Key identification Discussed at length on this list. I fixed sdlfb to use scan codes (assumes standard AT or PS/2 keyboard). vncfb is not fixable. See comments in the code. * Drop XENKBD_TYPE_BUTTON in favour of XENKBD_TYPE_KEY. Simpler, and gets rid of the three button limit. * Support shadow translate mode guests (untested). * Absolute mouse pointer (optional feature) * Fix event delivery and receipt notification. * Use __s32 for coordinates instead of __u16 and __s16 for pixel coordinates, to match linux/input.h, which uses int. * Don''t drop the first pointer event on the floor in vncfb. * Backends diagnose lost kbd events. * Some renames to make xenkbd and xenfb drivers more similar. Sorry for the extra diffs, but the inconsistencies were just too confusing. Known issues: * What to do when backend closes the connection? I guess we want to keep the frontend running, ready for another connection. This works already, but in a rather hackish and limited way. * What to do when the frontend closes the connection? Make backend exit? * What happens when multiple backends connect to the same frontend? Chaos, most likely. * Resume not implemented. * xm configuration magic doesn''t know the new devices, yet. I''m ignorant of how this magic works, perhaps somebody can lend me a hand with it. Workaround: - Convert /etc/xen/FOO into FOO.sxp with xm create -n. Make sure to delete the junk at the beginning of the output. - Add (device (vfb ())) (device (vkbd ()) and change kernel and ramdisk to point to suitable copies. - xm create -F FOO.sxp. * A couple of FIXMEs are still left in the code. Future work: * Investigate ditching LibVNCServer. * Use grant tables when they become capable of mapping the framebuffer. * Support multiple framebuffers. * Dynamic screen resolution. * Support other keyboards. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> Discussed at length on this list. I fixed sdlfb to use scan codes > (assumes standard AT or PS/2 keyboard). vncfb is not fixable. See > comments in the code.I''ve hacked up my own vnc client (using gtk and libvncserver). That one has a cmd line switch to send us keyboard keysyms no matter what the local keymap is (using a builtin keycode -> keysym table). It isn''t perfect, but it is the best solution I''ve found for vnc so far. I have at least a sane US keyboard within the guests. Loading keymaps within the guest works too and gives the expected results, except that keys not available on a US keyboard don''t work (i.e. the 105th key on int''l keyboards). No idea how to tackle that one :-( It''s part of the xenwatch package. Source is available from http://dl.bytesex.org/cvs-snapshots/, the opensuse buildservice has ready-to-go packages for at http://software.opensuse.org/download/home:/kraxel/ cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Nov 10, 2006 at 09:53:44AM +0100, Markus Armbruster wrote:> To: xen-devel@lists.xensource.com > From: Markus Armbruster <armbru@redhat.com> > Date: Fri, 10 Nov 2006 09:53:44 +0100 > Subject: [Xen-devel] [PATCH 0/2] PV framebufferThese patches look a lot better than the last batch which were posted; thank you for doing this work. It''s turned out to be a bit more than I think anybody was really expecting. I''ve got a few comments on the patches themselves, but most of them are fairly simple and easily addressed. I''ll send them in separate emails.> Known issues: > > * What to do when backend closes the connection? I guess we want to > keep the frontend running, ready for another connection. This works > already, but in a rather hackish and limited way.The current scheme, as I read it, is just to have the backend ignore the fact that it''s resuming from an existing connection and pull the required settings out of xenbus and the shared memory area? That''s not actually a bad way of doing things, since it doesn''t require much cooperation from the frontend, which''ll be handy for things like migration and suspend/resume. You''ll have problems if the set of supported features changes between the two backends, but that shouldn''t require too much effort to fix.> * What to do when the frontend closes the connection? Make backend > exit?Your choices, as far as I can see, are: -- Make the backend exit. -- Make the backend sit and wait for the frontend to reconnect. You''ll probably want to arrange for the backend to go to state InitWait here, so that the new frontend can reconnect easily, and you''ll obviously want to unmap all of the frontend-supplied pages. I''m not sure why the frontend would ever disconnect except when the guest is shutting down, so I''m not sure which approach is best here.> * What happens when multiple backends connect to the same frontend? > Chaos, most likely.Yep. You could put some kind of lock in xenbus if you care about this, but it''d cause problems if you want to be able to reconnect after a backend crashes.> * xm configuration magic doesn''t know the new devices, yet. I''m > ignorant of how this magic works, perhaps somebody can lend me a > hand with it.How about something like this: diff -r f70b56aab8a2 tools/python/xen/xm/create.py --- a/tools/python/xen/xm/create.py Thu Nov 02 13:20:32 2006 +0000 +++ b/tools/python/xen/xm/create.py Fri Nov 03 16:48:34 2006 +0000 @@ -277,6 +277,11 @@ gopts.var(''usbport'', val=''PATH'', use="""Add a physical USB port to a domain, as specified by the path to that port. This option may be repeated to add more than one port.""") +gopts.var(''vfb'', val="foo", + fn=append_value, + default=[], + use="""Do stuff""") + gopts.var(''vif'', val="mac=MAC,bridge=BRIDGE,ip=IPADDR,script=SCRIPT,backend=DOM,vifname=NAME", fn=append_value, default=[], use="""Add a network interface with the given MAC address and bridge. @@ -544,6 +549,9 @@ def configure_usb(config_devs, vals): config_usb = [''usbport'', [''path'', path]] config_devs.append([''device'', config_usb]) +def configure_vfbs(config_devs, vals): + for path in vals.vfb: + config_devs.append([''device'', [''vfb'', []]]) def configure_security(config, vals): """Create the config for ACM security labels. @@ -717,6 +724,7 @@ def make_config(vals): configure_vifs(config_devs, vals) configure_usb(config_devs, vals) configure_vtpm(config_devs, vals) + configure_vfbs(config_devs, vals) configure_security(config, vals) config += config_devs You''ll need to do something similar for vkbds as well. If you need additional parameters in the SXP, add them in configure_vfbs. It might be an idea to automatically create the vkbd when you create the vfb SXP, since it doesn''t make a great deal of sense to have one without the other, but I''ll leave that up to you. Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Smith <sos22-xen@srcf.ucam.org> writes:> On Fri, Nov 10, 2006 at 09:53:44AM +0100, Markus Armbruster wrote: >> To: xen-devel@lists.xensource.com >> From: Markus Armbruster <armbru@redhat.com> >> Date: Fri, 10 Nov 2006 09:53:44 +0100 >> Subject: [Xen-devel] [PATCH 0/2] PV framebuffer > > These patches look a lot better than the last batch which were posted; > thank you for doing this work. It''s turned out to be a bit more than > I think anybody was really expecting.Least of all me :)> I''ve got a few comments on the patches themselves, but most of them > are fairly simple and easily addressed. I''ll send them in separate > emails. > >> Known issues: >> >> * What to do when backend closes the connection? I guess we want to >> keep the frontend running, ready for another connection. This works >> already, but in a rather hackish and limited way. > The current scheme, as I read it, is just to have the backend ignore > the fact that it''s resuming from an existing connection and pull the > required settings out of xenbus and the shared memory area? That''sCorrect.> not actually a bad way of doing things, since it doesn''t require much > cooperation from the frontend, which''ll be handy for things like > migration and suspend/resume. > > You''ll have problems if the set of supported features changes between > the two backends, but that shouldn''t require too much effort to fix. > >> * What to do when the frontend closes the connection? Make backend >> exit? > Your choices, as far as I can see, are: > > -- Make the backend exit. > > -- Make the backend sit and wait for the frontend to reconnect. > You''ll probably want to arrange for the backend to go to state > InitWait here, so that the new frontend can reconnect easily, > and you''ll obviously want to unmap all of the frontend-supplied > pages. > > I''m not sure why the frontend would ever disconnect except when the > guest is shutting down, so I''m not sure which approach is best here.I figure the situation will become clearer to me when I implement resume.>> * What happens when multiple backends connect to the same frontend? >> Chaos, most likely. > Yep. You could put some kind of lock in xenbus if you care about > this, but it''d cause problems if you want to be able to reconnect > after a backend crashes.Need to detect and delete stale locks. I''d like to have robust behavior here eventually, but don''t think we need it right away.>> * xm configuration magic doesn''t know the new devices, yet. I''m >> ignorant of how this magic works, perhaps somebody can lend me a >> hand with it. > How about something like this:[...]> You''ll need to do something similar for vkbds as well. If you need > additional parameters in the SXP, add them in configure_vfbs. It > might be an idea to automatically create the vkbd when you create the > vfb SXP, since it doesn''t make a great deal of sense to have one > without the other, but I''ll leave that up to you.I''ll give this a try, many thanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello, Markus I want to test PV patch but current patch does not work. (as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct) Could you give me a working version patch? Thanks Atsushi SAKAI>Summary of changes: > >* Use xenbus_device API. > > Some xm configuration magic is still missing, see below. > >* Negotiate features through Xen Store. > >* Key identification > > Discussed at length on this list. I fixed sdlfb to use scan codes > (assumes standard AT or PS/2 keyboard). vncfb is not fixable. See > comments in the code. > >* Drop XENKBD_TYPE_BUTTON in favour of XENKBD_TYPE_KEY. Simpler, and > gets rid of the three button limit. > >* Support shadow translate mode guests (untested). > >* Absolute mouse pointer (optional feature) > >* Fix event delivery and receipt notification. > >* Use __s32 for coordinates instead of __u16 and __s16 for pixel > coordinates, to match linux/input.h, which uses int. > >* Don''t drop the first pointer event on the floor in vncfb. > >* Backends diagnose lost kbd events. > >* Some renames to make xenkbd and xenfb drivers more similar. Sorry > for the extra diffs, but the inconsistencies were just too > confusing. > >Known issues: > >* What to do when backend closes the connection? I guess we want to > keep the frontend running, ready for another connection. This works > already, but in a rather hackish and limited way. > >* What to do when the frontend closes the connection? Make backend > exit? > >* What happens when multiple backends connect to the same frontend? > Chaos, most likely. > >* Resume not implemented. > >* xm configuration magic doesn''t know the new devices, yet. I''m > ignorant of how this magic works, perhaps somebody can lend me a > hand with it. > > Workaround: > > - Convert /etc/xen/FOO into FOO.sxp with xm create -n. Make sure to > delete the junk at the beginning of the output. > > - Add > (device (vfb ())) > (device (vkbd ()) > and change kernel and ramdisk to point to suitable copies. > > - xm create -F FOO.sxp. > >* A couple of FIXMEs are still left in the code. > >Future work: > >* Investigate ditching LibVNCServer. > >* Use grant tables when they become capable of mapping the > framebuffer. > >* Support multiple framebuffers. > >* Dynamic screen resolution. > >* Support other keyboards. > >_______________________________________________ >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
Atsushi SAKAI <sakaia@jp.fujitsu.com> writes:> Hello, Markus > > I want to test PV patch but current patch does not work. > (as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct) > Could you give me a working version patch? > > Thanks > Atsushi SAKAIMy frontend patch is relative to the Linux tree, not the Xen tree, and not the *sparse* Linux tree within the Xen tree. The guardians of the source tree assure me they greatly benefit from having a sparse tree there. Good for them[*]! I don''t. It''s a pain in the neck for me. By refusing to touch the sparse tree, I shift a good part of my pain to those who enjoy the benefits. I consider that fair. To try my patch, let Xen create an ordinary source tree, then patch that. I do test that it applies there before submitting. If you''d rather sparsify it, perhaps a knowledgeable user of the sparse tree can help you. [*] No irony intended, honest, officer. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Markus your code location of xenfb.h is in linux-2.6.16.29-xen/include/xen/interface/io/xenfb.h it is wrong position. It should be located in xen/include/public/io please see mkbuildtree@linux-sparce and see your linux-2.6.16.29-xen/include/xen/interface/io with "ls -l" these file is linked from xen/include/public/io Thanks Atsushi SAKAI>Atsushi SAKAI <sakaia@jp.fujitsu.com> writes: > >> Hello, Markus >> >> I want to test PV patch but current patch does not work. >> (as Steven Smith suggested, for example xenfb.h xenkbd.h location is not correct) >> Could you give me a working version patch? >> >> Thanks >> Atsushi SAKAI > >My frontend patch is relative to the Linux tree, not the Xen tree, and >not the *sparse* Linux tree within the Xen tree. > >The guardians of the source tree assure me they greatly benefit from >having a sparse tree there. Good for them[*]! I don''t. It''s a pain >in the neck for me. By refusing to touch the sparse tree, I shift a >good part of my pain to those who enjoy the benefits. I consider that >fair. > >To try my patch, let Xen create an ordinary source tree, then patch >that. I do test that it applies there before submitting. > >If you''d rather sparsify it, perhaps a knowledgeable user of the >sparse tree can help you. > >[*] No irony intended, honest, officer. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Atsushi SAKAI <sakaia@jp.fujitsu.com> writes:> Hi, Markus > > your code location of xenfb.h is in > linux-2.6.16.29-xen/include/xen/interface/io/xenfb.h > it is wrong position. > > It should be located in > xen/include/public/ioIf my patch were relative to the Xen source tree, you''d be right. It isn''t. There is no xen directory in a Linux source tree. Yes, that means you can''t apply my patch directly to your Xen source tree. Sorry about that. I explained my reasons. [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Next iteration. If there''s anything left in the way of getting this merged, please let me know right away. Changes since last time: * Minor cleanup of how Xen console detects presence of framebuffer. * Fix config XEN_KEYBOARD dependencies. * Fix misuse of __devexit. * Fix crash when kthread_run() fails. * Work around xenbus race condition. * Get rid of xenstore key console/use_graphics. * Supply missing patch to mm/memory.c * Fix typo in XendDevices.py * xm configuration magic for xenfb and xenkbd devices. * vncfb listens on 127.0.0.1 instead of 0.0.0.0 by default. * backends put error node into xenstore. * Move write of hotplug-status to the correct place. * Make backend reconnect even when status is Closing or Closed. Diffs since last time follow in separate messages. Not in this patch, but coming soon: make xend start the backend automatically. For now, you need to start it manually, like this: # sdlfb -d $(xm domid parafat) You also have to put the following lines into /etc/xen/DOMNAME: vfb = ''yes'' vkbd = ''yes'' The framebuffer remains inactive without them. That means behavior of existing domains should not be affected, which is nice. If you do put them in, xend will wait for you to start the backend before it unpauses the domain. It would be nice if it just went along, and connecting a backend later just worked, but that''s left for another day. One last thing to consider: I''m not entirely happy with source file names and locations. It''s now or never for renames. Peeves: * Frontend source usually lives in drivers/xen/<WHAT>front. xenfb and xenkbd are exceptions. Rename to fbfront and kbdfront? Same for the .c files. This would also fix the minor annoyance of having the same file name in frontend and backend. * Given how closely related xenfb and xenkbd are, I''m not fond of having them in separate directories. Move kbd into the fb directory? Anything else? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi all, The keymap is being written in these patches. However, the keymap seems to be 101 keyboard layout. Therefore, other keyboard layouts cannot be used. I think that the mechanism that keyboard layout is selected like qemu-dm is necessary. How do you think about it? Thanks, Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:> Hi all, > > The keymap is being written in these patches.Are you talking about sdlfb or vncfb?> However, the keymap seems to be 101 keyboard layout. > Therefore, other keyboard layouts cannot be used.sdlfb works with scancodes and its mapping to Linux input layer keycodes assumes a standard AT or PS/2 keyboard. vncfb can''t work with scancodes, because LibVNCServer doesn''t provide them. It has to work with key symbols instead. This can''t work in general, see the source code for why. Its mapping to Linux keycodes assumes you''re using the usual US keymap.> I think that the mechanism that keyboard layout is selected like > qemu-dm is necessary. > How do you think about it?Nobody coded it yet. It would sure be useful. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, Nov 21, 2006 at 06:50:30AM +0100, Markus Armbruster wrote:> "Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes: > > > Hi all, > > > > The keymap is being written in these patches. > > Are you talking about sdlfb or vncfb? > > > However, the keymap seems to be 101 keyboard layout. > > Therefore, other keyboard layouts cannot be used. > > sdlfb works with scancodes and its mapping to Linux input layer > keycodes assumes a standard AT or PS/2 keyboard. > > vncfb can''t work with scancodes, because LibVNCServer doesn''t provide > them. It has to work with key symbols instead. This can''t work in > general, see the source code for why. Its mapping to Linux keycodes > assumes you''re using the usual US keymap. > > > I think that the mechanism that keyboard layout is selected like > > qemu-dm is necessary. > > How do you think about it? > > Nobody coded it yet. It would sure be useful.I think you could steal the keymaps from QEMU, and the parsing and translation code. That would be good, because we would have only one set of keymaps to maintain. That translation between VNC''s X11 keysyms and the appropriate scancode has been all written once (for QEMU''s VNC frontend), so it would be good if you could take advantage of that. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Steven, Your sketch for the xm configuration magic was quite helpful. Perhaps you can lend me a hand with resume as well. xm restore fails (xend.log appended) because the xenfb backend can''t be connected. Obviously, I need to start the backend somewhere on restore, just like I start it on xm create (patch appended). Where? How? [2006-11-21 18:21:21 xend 3303] ERROR (XendDomain:268) Restore failed Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line 263, in d omain_restore_fd return XendCheckpoint.restore(self, fd) File "/usr/lib/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 165, in restore dominfo.waitForDevices() # Wait for backends to set up File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1596, in waitForDevices self.waitForDevices_(c) File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1090, in waitForDevices_ return self.getDeviceController(deviceClass).waitForDevices() File "/usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", line 145, in waitForDevices return map(self.waitForDevice, self.deviceIDs()) File "/usr/lib/python2.4/site-packages/xen/xend/server/DevController.py", line 155, in waitForDevice raise VmError("Device %s (%s) could not be connected. " VmError: Device 0 (vkbd) could not be connected. Hotplug scripts not working. diff -r 73ef90055339 tools/python/xen/xend/image.py --- a/tools/python/xen/xend/image.py Thu Nov 16 18:29:06 2006 +0000 +++ b/tools/python/xen/xend/image.py Fri Nov 17 16:06:23 2006 +0100 @@ -23,6 +23,7 @@ import signal import signal import xen.lowlevel.xc +import xen.util.auxbin from xen.xend import sxp from xen.xend.XendError import VmError, XendError from xen.xend.XendLogging import log @@ -209,6 +210,81 @@ class LinuxImageHandler(ImageHandler): cmdline = self.cmdline, ramdisk = self.ramdisk, features = self.vm.getFeatures()) + + def configure(self, imageConfig, deviceConfig): + ImageHandler.configure(self, imageConfig, deviceConfig) + + self.pid = 0 + log.info("configuring linux guest") + + # set up the graphics bits. + # FIXME: this is much like what we do for HVM, should it be + # for all image types now? + self.display = sxp.child_value(imageConfig, ''display'') + self.xauthority = sxp.child_value(imageConfig, ''xauthority'') + self.vncconsole = sxp.child_value(imageConfig, ''vncconsole'') + vncpasswd = sxp.child_value(imageConfig, ''vncpasswd'') + if not(vncpasswd is None): + imageConfig.remove([''vncpasswd'', vncpasswd]) + self.vncpasswd = vncpasswd + + self.vnc = sxp.child_value(imageConfig, ''vnc'') + self.sdl = sxp.child_value(imageConfig, ''sdl'') + if self.vnc: + self.vncdisplay = int(sxp.child_value(imageConfig, ''vncdisplay'', + self.vm.getDomid())) + self.vncunused = sxp.child_value(imageConfig, ''vncunused'') + self.vnclisten = sxp.child_value(imageConfig, ''vnclisten'') + if not(self.vnclisten): + self.vnclisten = xen.xend.XendRoot.instance().get_vnclisten_address() + + def createDeviceModel(self): + if self.pid: + return + # Execute device model (for us, it''s just the fb frontend) + if not self.vnc and not self.sdl: + return + + if self.vnc: + args = [xen.util.auxbin.pathTo("xen-vncfb")] + if self.vncunused: + args += [''--unused''] + elif self.vncdisplay: + args += [ "--vncport", "%d" %(5900 + self.vncdisplay,) ] + if self.vnclisten: + args += [ "--listen", self.vnclisten ] + + # password check + if self.vncpasswd is None: + # get password from xend-config(if password omitted, None) + self.vncpasswd = xen.xend.XendRoot.instance().get_vncpasswd_default() + + if self.vncpasswd is None: + raise VmError(''vncpasswd is not setup in the guest config or xend-config.'') + if self.vncpasswd != '''': + self.vm.storeVm("vncpasswd", self.vncpasswd) + log.info("vncpassword set to ''%s''", self.vncpasswd) + + elif self.sdl: + args = [xen.util.auxbin.pathTo("xen-sdlfb")] + args = args + [ "--domid", "%d" % self.vm.getDomid(), + "--title", self.vm.info[''name''] ] + + env = dict(os.environ) + if self.display: + env[''DISPLAY''] = self.display + if self.xauthority: + env[''XAUTHORITY''] = self.xauthority + log.info("spawning video: %s", args) + self.pid = os.spawnve(os.P_NOWAIT, args[0], args, env) + log.info("device model pid: %d", self.pid) + + def destroy(self): + if not self.pid: + return + os.kill(self.pid, signal.SIGKILL) + os.waitpid(self.pid, 0) + self.pid = 0 class PPC_LinuxImageHandler(LinuxImageHandler): _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Markus and Ewan, I confirmed it with paraVM image made by virt-manager on RHEL5β2. The keyboard used for the input is Japanese keyboard.(jp106) The key input as follows is input by mistake. @ -> 2 : -> ; '' (shift+7) -> " = -> + I think that it cannot use except for 101 keyboard. Do you think that you should support other keyboards? It cannot be at least used with a Japanese keyboard. Thanks, Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:> Hi Markus and Ewan, > > I confirmed it with paraVM image made by virt-manager on RHEL5β2. The > keyboard used for the input is Japanese keyboard.(jp106) The key input > as follows is input by mistake. > > @ -> 2 > : -> ; > '' (shift+7) -> " > = -> + > > I think that it cannot use except for 101 keyboard.VNC or SDL? vncfb is expected to behave strangely unless you use the US keymap. sdlfb is expected to behave strangely unless you have a PS/2 keyboard. Your 106er should qualify, although the extra five keys may or may not work. Note that you need to configure the keymap in the guest.> Do you think that you should support other keyboards?Certainly.> It cannot be at least used with a Japanese keyboard. > > Thanks, > Takanori Kasai_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Next iteration. If there''s anything left in the way of getting this > merged, please let me know right away.I hit a couple of problems when testing this: 1) It breaks existing configurations. Changing the xencons default from xencons=tty to xencons=xvc means that any existing configurations with gettys etc. set up on /dev/tty1 rather than /dev/xvc0 will no longer work. That really isn''t an option. 2) The mouse pointer displayed by X or gpm and the pointer as sent by the client often get out of sync. It looks like X is getting relative mouse movement messages rather than absolute. The backend is definitely generating absolute position messages, so I''m not sure what''s going on there. It''s possible I''ve just messed up the configuration inside the domain. 3) The backend doesn''t do the shutdown protocol correctly. This leads to xenbus_dev_shutdown: device/vkbd/0 timeout closing device messages on the console when you try and shut the domain down. These are more irritants than actual problems, but it''d be good to get them fixed. I''m kind of bogged down with other stuff at the moment, so I''m not going to be able to look at the patches in detail until next week, but I figure that should be enough to keep you busy for a little while. :) Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Smith <sos22-xen@srcf.ucam.org> writes:>> Next iteration. If there''s anything left in the way of getting this >> merged, please let me know right away. > I hit a couple of problems when testing this: > > 1) It breaks existing configurations. Changing the xencons default > from xencons=tty to xencons=xvc means that any existing > configurations with gettys etc. set up on /dev/tty1 rather than > /dev/xvc0 will no longer work. That really isn''t an option.Done.> 2) The mouse pointer displayed by X or gpm and the pointer as sent by > the client often get out of sync. It looks like X is getting > relative mouse movement messages rather than absolute. The backend > is definitely generating absolute position messages, so I''m not > sure what''s going on there. It''s possible I''ve just messed up the > configuration inside the domain.What pointer device did you use? Almost all use relative modes, including tablets.> 3) The backend doesn''t do the shutdown protocol correctly. This leads > to > > xenbus_dev_shutdown: device/vkbd/0 timeout closing device > > messages on the console when you try and shut the domain down. > These are more irritants than actual problems, but it''d be good to > get them fixed.Sure. I''d prefer to finish resume first. Still trying to figure out why xm restore doesn''t restart the backend.> I''m kind of bogged down with other stuff at the moment, so I''m not > going to be able to look at the patches in detail until next week, but > I figure that should be enough to keep you busy for a little while. :)Sigh... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Markus and Ewan,>> I confirmed it with paraVM image made by virt-manager on RHEL5β2. The >> keyboard used for the input is Japanese keyboard.(jp106) The key input >> as follows is input by mistake. >> >> @ -> 2 >> : -> ; >> '' (shift+7) -> " >> = -> + >> >> I think that it cannot use except for 101 keyboard. > > VNC or SDL? > > vncfb is expected to behave strangely unless you use the US keymap.Sorry, I was not answering your question. I am talking about vncfb. The function to select keyboard layout is provided in qemu-dm. I contributed the patch to select keyboard layout from configuration file the other day.>I think you could steal the keymaps from QEMU, and the parsing and translation >code. That would be good, because we would have only one set of keymaps to >maintain. That translation between VNC''s X11 keysyms and the appropriate >scancode has been all written once (for QEMU''s VNC frontend), so it would be >good if you could take advantage of that.It is necessary to transplant the function that convert between VNC''s X11 keysyms and the appropriate scancode from qemu-dm. Should I do it? Thanks Takanori Kasai _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Next iteration. If there''s anything left in the way of getting this merged, please let me know right away. Changes since last time: * Leave xen console defaulting to /dev/tty1. * Start backend automatically. * Fix kernel thread to call try_to_freeze(). * Recreate the image sub-object in XendDomainInfo.py on resume. * Implement frontend resume methods; xm save and restore work now. * Implement orderly backend shutdown. To activate the framebuffer, you have to put the following lines into /etc/xen/DOMNAME: vfb = ''yes'' vkbd = ''yes'' and either sdl = 1 or vnc = 1 One last thing to consider: I''m not entirely happy with source file names and locations. It''s now or never for renames. Peeves: * Frontend source usually lives in drivers/xen/<WHAT>front. xenfb and xenkbd are exceptions. Rename to fbfront and kbdfront? Same for the .c files. This would also fix the minor annoyance of having the same file name in frontend and backend. * Given how closely related xenfb and xenkbd are, I''m not fond of having them in separate directories. Move kbd into the fb directory? Anything else? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Markus Armbruster <armbru@redhat.com> writes:> Next iteration. If there''s anything left in the way of getting this > merged, please let me know right away. > > Changes since last time: > > * Leave xen console defaulting to /dev/tty1. > > * Start backend automatically. > > * Fix kernel thread to call try_to_freeze(). > > * Recreate the image sub-object in XendDomainInfo.py on resume. > > * Implement frontend resume methods; xm save and restore work now. > > * Implement orderly backend shutdown.Forgot to mention: * Fix shadow mode guest support based on a patch from Atsushi SAKAI. [...] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Kasai Takanori" <kasai.takanori@jp.fujitsu.com> writes:> Hi Markus and Ewan, > >>> I confirmed it with paraVM image made by virt-manager on RHEL5β2. The >>> keyboard used for the input is Japanese keyboard.(jp106) The key input >>> as follows is input by mistake. >>> >>> @ -> 2 >>> : -> ; >>> '' (shift+7) -> " >>> = -> + >>> >>> I think that it cannot use except for 101 keyboard. >> >> VNC or SDL? >> >> vncfb is expected to behave strangely unless you use the US keymap. > > Sorry, I was not answering your question. > I am talking about vncfb. > > The function to select keyboard layout is provided in qemu-dm. > I contributed the patch to select keyboard layout from configuration > file the other day. > > >>I think you could steal the keymaps from QEMU, and the parsing and translation >>code. That would be good, because we would have only one set of keymaps to >>maintain. That translation between VNC''s X11 keysyms and the appropriate >>scancode has been all written once (for QEMU''s VNC frontend), so it would be >>good if you could take advantage of that. > > It is necessary to transplant the function that convert > between VNC''s X11 keysyms and the appropriate scancode from qemu-dm. > > Should I do it?I take free, working, maintainable code any day :) I''d love to see LibVNCServer replaced by the QEMU VNC code alltogether. I haven''t found the time to look into this myself. Perhaps that would be an even better use of your time. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Next iteration. If there''s anything left in the way of getting this > merged, please let me know right away. > > Changes since last time: > > * Leave xen console defaulting to /dev/tty1. > > * Start backend automatically.I''m not entirely happy with the way this is done; I''d much rather the device controller started the backend than the image controller. I can probably fix this up more easily than you.> * Fix kernel thread to call try_to_freeze(). > > * Recreate the image sub-object in XendDomainInfo.py on resume.Why did you do this? I can''t see that it has anything to do with the pvfb work, and everything seems to still work when I get rid of this part of the patch.> To activate the framebuffer, you have to put the following lines into > /etc/xen/DOMNAME: > > vfb = ''yes'' > vkbd = ''yes'' > > and either > > sdl = 1 > > or > > vnc = 1I''m not entirely happy about this configuration syntax: -- It''s redundant: you can''t specify a vfb without a vkbd or vice-versa, or the domain won''t start, so we might as well get rid of the vkbd="yes" business -- It doesn''t give any way of specifying parameters to the backend -- The configuration for a single device ends up split into several different items. It also depends on stuff outside the usual (device) sections in the SXP, which is kind of nasty. -- It potentially conflicts with the way emulated vga is specified in hvm guests. e.g. you can''t specify that emulated vga should be exported over vnc while the pv framebuffer should be sdl. Whether you''d ever want to do this is another matter, but it''d be nice if we didn''t rule it out for reasons as trivial as a bad configuration file design. -- It won''t extend to supporting multiple pvfbs -- It doesn''t look much like the syntax for configuring other devices. I''d prefer something more like this: vfbs = [ ''type=sdl,listen=127.0.0.1'' ] Again, I can probably fix this up more easily than you, if you don''t object.> One last thing to consider: I''m not entirely happy with source file > names and locations. It''s now or never for renames. Peeves: > > * Frontend source usually lives in drivers/xen/<WHAT>front. xenfb and > xenkbd are exceptions. Rename to fbfront and kbdfront? Same for > the .c files. This would also fix the minor annoyance of having the > same file name in frontend and backend. > > * Given how closely related xenfb and xenkbd are, I''m not fond of > having them in separate directories. Move kbd into the fb > directory?If it were my patch, I''d put everything in drivers/xen/fbfront, but it doesn''t really make a great deal of difference. Apart from that, I''m happy with this. If you send me a patch which applies cleanly to xen-unstable and is signed-off-by the right people, I''ll check it in and fix the things I mentioned myself. Steven. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Steven Smith <sos22-xen@srcf.ucam.org> writes:>> Next iteration. If there''s anything left in the way of getting this >> merged, please let me know right away. >> >> Changes since last time: >> >> * Leave xen console defaulting to /dev/tty1. >> >> * Start backend automatically. > I''m not entirely happy with the way this is done; I''d much rather the > device controller started the backend than the image controller. I > can probably fix this up more easily than you.No problem.>> * Fix kernel thread to call try_to_freeze(). >> >> * Recreate the image sub-object in XendDomainInfo.py on resume. > Why did you do this? I can''t see that it has anything to do with the > pvfb work, and everything seems to still work when I get rid of this > part of the patch.Without it, the framebuffer doesn''t survive a save/restore. There may well be a better way to restart the backend on restore.>> To activate the framebuffer, you have to put the following lines into >> /etc/xen/DOMNAME: >> >> vfb = ''yes'' >> vkbd = ''yes'' >> >> and either >> >> sdl = 1 >> >> or >> >> vnc = 1 > I''m not entirely happy about this configuration syntax: > > -- It''s redundant: you can''t specify a vfb without a vkbd or > vice-versa, or the domain won''t start, so we might as well get rid > of the vkbd="yes" businessAbsolutely. It was just the simplest conceivable way to get the thing to work.> -- It doesn''t give any way of specifying parameters to the backend > -- The configuration for a single device ends up split into several > different items. It also depends on stuff outside the usual > (device) sections in the SXP, which is kind of nasty. > -- It potentially conflicts with the way emulated vga is specified in > hvm guests. e.g. you can''t specify that emulated vga should be > exported over vnc while the pv framebuffer should be sdl. Whether > you''d ever want to do this is another matter, but it''d be nice if > we didn''t rule it out for reasons as trivial as a bad configuration > file design. > -- It won''t extend to supporting multiple pvfbs > -- It doesn''t look much like the syntax for configuring other devices. > > I''d prefer something more like this: > > vfbs = [ ''type=sdl,listen=127.0.0.1'' ] > > Again, I can probably fix this up more easily than you, if you don''t > object.Not at all.>> One last thing to consider: I''m not entirely happy with source file >> names and locations. It''s now or never for renames. Peeves: >> >> * Frontend source usually lives in drivers/xen/<WHAT>front. xenfb and >> xenkbd are exceptions. Rename to fbfront and kbdfront? Same for >> the .c files. This would also fix the minor annoyance of having the >> same file name in frontend and backend. >> >> * Given how closely related xenfb and xenkbd are, I''m not fond of >> having them in separate directories. Move kbd into the fb >> directory? > If it were my patch, I''d put everything in drivers/xen/fbfront, but it > doesn''t really make a great deal of difference. > > Apart from that, I''m happy with this. If you send me a patch which > applies cleanly to xen-unstable and is signed-off-by the right people, > I''ll check it in and fix the things I mentioned myself.Deal! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel