From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42264)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Vj2u1-0006M8-7E
	for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:12:55 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Vj2tv-0006LY-3J
	for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:12:49 -0500
Received: from mx1.redhat.com ([209.132.183.28]:32805)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1Vj2tu-0006LS-Rf
	for qemu-devel@nongnu.org; Wed, 20 Nov 2013 03:12:43 -0500
Message-ID: <1384935158.2005.34.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Wed, 20 Nov 2013 09:12:38 +0100
In-Reply-To: <CAPM=9tx08mf08OR2dETiSQwcy4ze35iTAP=e50aETf+eZ9xThQ@mail.gmail.com>
References: <CAPM=9tz1K3xx3c4Hr2yDuL+ucX2CKnD_jbp-xtUuVzUpd3hrTA@mail.gmail.com>
	<1384848690.16718.139.camel@nilsson.home.kraxel.org>
	<CAPM=9tx08mf08OR2dETiSQwcy4ze35iTAP=e50aETf+eZ9xThQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] console muti-head some more design input
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Dave Airlie <airlied@gmail.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

  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.

The functions used to notify qemu about mouse + keyboard events should
get an additional parameter to indicate the source of the event.  I
think we can use a QemuConsole here.

Then teach the input layer about seats, where a seat is a group of input
devices (kbd, mouse, tablet) and a group of QemuConsoles.  With x+y for
each QemuConsole.  The input layer will do the event routing:  Translate
coordinates, send to the correct device.

I think initially we just can handle all existing QemuConsole and input
devices implicitly as "seat 0".  Stick x+y into QemuConsole for now, and
have the input layer get it from there.  At some point in the future we
might want move this to a QemuSeat when we actually go multiseat.

Bottom line: please do the coordinates math in input.c not sdl2.c so we
don't run into roadblocks in the future.

cheers,
  Gerd