From: Gerd Hoffmann <kraxel@redhat.com>
To: John Baboval <baboval@spineless.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] console muti-head some more design input
Date: Wed, 20 Nov 2013 16:14:05 +0100 [thread overview]
Message-ID: <1384960445.2005.124.camel@nilsson.home.kraxel.org> (raw)
In-Reply-To: <528CC80B.7080601@spineless.org>
On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote:
> On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> I think you are only considering output here, for input we definitely
> >> need some idea of screen layout, and this needs to be stored
> >> somewhere.
> > Oh yea, input. That needs quite some work for multihead / multiseat.
> >
> > I think we should *not* try to hack that into the ui. We should extend
> > the input layer instead.
>
> This would be a contrast to how a real system works.
No. We have to solve problem here which doesn't exist on real hardware
in the first place.
> IMO, the UI is the
> appropriate place for this sort of thing. A basic UI is going to be
> sending relative events anyway.
>
> I think a "seat" should be a UI construct as well.
A seat on real hardware is a group of input (kbd, mouse, tablet, ...)
and output (display, speakers, ....) devices.
In qemu the displays are represented by QemuConsoles. So to model real
hardware we should put the QemuConsoles and input devices for a seat
into a group.
The ui displays some QemuConsole. If we tag input events with the
QemuConsole the input layer can figure the correct input device which
should receive the event according to the seat grouping.
With absolute pointer events the whole thing becomes a bit more tricky
as we have to map input from multiple displays (QemuConsoles) to a
single absolute pointing device (usb tablet). This is what Dave wants
the screen layout for. I still think the input layer is the place to do
this transformation.
While thinking about this: A completely different approach to tackle
this would be to implement touchscreen emulation. So we don't have a
single usb-tablet, but multiple (one per display) touch input devices.
Then we can simply route absolute input events from this display as-is
to that touch device and be done with it. No need to deal with
coordinate transformations in qemu, the guest will deal with it.
cheers,
Gerd
next prev parent reply other threads:[~2013-11-20 15:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 6:24 [Qemu-devel] console muti-head some more design input Dave Airlie
2013-11-19 8:11 ` Gerd Hoffmann
2013-11-20 2:59 ` Dave Airlie
2013-11-20 4:06 ` John Baboval
2013-11-20 5:17 ` Dave Airlie
2013-11-20 5:18 ` Dave Airlie
2013-11-20 8:12 ` Gerd Hoffmann
2013-11-20 14:32 ` John Baboval
2013-11-20 15:14 ` Gerd Hoffmann [this message]
2013-11-20 15:49 ` John Baboval
2013-11-22 8:36 ` Gerd Hoffmann
2013-11-21 0:45 ` Dave Airlie
2013-11-22 8:41 ` Gerd Hoffmann
2013-11-27 4:29 ` Dave Airlie
2013-11-27 7:11 ` Gerd Hoffmann
2013-11-27 14:23 ` John Baboval
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=1384960445.2005.124.camel@nilsson.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=baboval@spineless.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).