All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <theubaz@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: extending qemu-dm
Date: Tue, 3 Jan 2012 15:24:01 -0500	[thread overview]
Message-ID: <20120103202401.GB17472@phenom.dumpdata.com> (raw)
In-Reply-To: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>

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.

> 
> 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?

Or could you use synergy?

  reply	other threads:[~2012-01-03 20:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 20:26 extending qemu-dm John Sherwood
2012-01-03 20:24 ` Konrad Rzeszutek Wilk [this message]
2012-01-03 20:45   ` John Sherwood
2012-01-03 22:40     ` Konrad Rzeszutek Wilk
2012-01-04  1:16       ` John Sherwood
2012-01-04 14:25         ` Konrad Rzeszutek Wilk
2012-01-09 10:27           ` Jean Guyader
2012-01-10 12:01             ` Dietmar Hahn
2012-01-09 12:29     ` Samuel Thibault
2012-01-09 16:36       ` John Sherwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120103202401.GB17472@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=theubaz@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.