[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] extending qemu-dm



the synergy incompatibilities were largely package related, due to requirements for a different application that we were supposed to deploy.  I'll try the ioperm patches next chance I have.

On Tue, Jan 3, 2012 at 5:40 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
On Tue, Jan 03, 2012 at 03:45:17PM -0500, John Sherwood wrote:
> On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@xxxxxxxxxx> wrote:
>
> > On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > > Hello,
> > >
> > > I'm working on a project and trying to pass through a PS/2 mouse +
> > keyboard
> > > to a hardware VM.  I've played with numerous things (including the
> > obvious,
> > > using USB), but after finding no alternative, it seems like the best way
> > to
> > > approach this would be to modify qemu-dm to pipe through data from
> > > /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and
> > then
> > > using this version of qemu-dm only for this special case).
> >
> > That is certainly one way. But you would have an interesting problem that
> > whatever
> > you type on your physical keyboard would appear in the guest _and_ in the
> > domain 0.
> >
>
> yeah, I actually tested it and it was quite amusing to watch the keyboard
> and mouse move on the monitor and in VNC.
>
>
> >
> > >
> > > I've been looking through the 4.1.0 source, specifically in
> > > tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> > > pass key codes from /dev/input through the kbd_put_keycode function.
> >  From
> > > what I can tell, I'd probably want to split off a thread to do this
> > > somewhere in main() in vl.c.  I was hoping that I could get some
> > > confirmation about whether I'm looking in the right places and/or
> > > suggestions about how to cleanly implement this.  Odds are I won't be
> > able
> > > to go the whole 9 yards and implement configuration options for xm or
> > > command line switches for qemu-dm, but I would suspect that someone,
> > > somewhere, someday will also want this kind of ability.  If it's already
> > > possible to pass through PS/2 devices without getting nuts in QEMU,
> > that's
> > > cool too :)
> >
> > Can't do that. The PS/2 is one of those legacy beasts that depends on
> > ioports.
> > But now that I think of it, maybe you can. In the guest config you can
> > specify
> > the ioports that you want to pass in. I hadn't tried to do this for the
> > keyboard
> > ports but maybe that will work for you?
> >
> >
> I tried forwarding the ioports (off the top of my head, I remember trying
> 60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
> despite adding the requisite ioports config as per the docs.  I theorized I
> was leaving off some config for the kernel, but didn't find anything.  I
> agree that it certainly seems like this should work, and if you could
> elaborate on anything I could have goofed on, that would certainly be great
> (and hopefully, useful for anyone else who might try this in the future)

I think you might be missing the ioperm patches. The are in devel/ioperm
on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

>
>
> > Or could you use synergy?
> >
>
> I actually did try synergy, but I couldn't get it to work due to
> requirements for the OSes that were being run.

Huh? What OS is that? Anyhow another thought that occured to me is
what Virtual Computer or Xen Client Project do.. which is something
I don't really know what they do but their demo showed the user hitting
'Alt-Tab' on switching between domains on the laptop screen. The keyboard
is certainly PS/2 so I wonder how they "injected" the keyboard in the guest.
It might be curious to look at their patches: http://xen.org/products/xci_source.html



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.