From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj8qC-0001ST-BM for qemu-devel@nongnu.org; Wed, 20 Nov 2013 09:33:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj8q5-0001Vd-1z for qemu-devel@nongnu.org; Wed, 20 Nov 2013 09:33:16 -0500 Received: from maverick.spineless.org ([71.174.98.242]:34519 helo=spineless.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj8q4-0001VD-Tx for qemu-devel@nongnu.org; Wed, 20 Nov 2013 09:33:08 -0500 Received: from [216.57.91.130] (helo=[10.204.240.225]) by spineless.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Vj8py-0002UG-6N for qemu-devel@nongnu.org; Wed, 20 Nov 2013 09:33:02 -0500 Message-ID: <528CC80B.7080601@spineless.org> Date: Wed, 20 Nov 2013 09:32:43 -0500 From: John Baboval MIME-Version: 1.0 References: <1384848690.16718.139.camel@nilsson.home.kraxel.org> <1384935158.2005.34.camel@nilsson.home.kraxel.org> In-Reply-To: <1384935158.2005.34.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] console muti-head some more design input List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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. 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. > 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 > > > >