From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj9Tr-0005Mt-2g for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:14:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj9Tl-0005d8-3O for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:14:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj9Tk-0005d0-Pt for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:14:09 -0500 Message-ID: <1384960445.2005.124.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 20 Nov 2013 16:14:05 +0100 In-Reply-To: <528CC80B.7080601@spineless.org> References: <1384848690.16718.139.camel@nilsson.home.kraxel.org> <1384935158.2005.34.camel@nilsson.home.kraxel.org> <528CC80B.7080601@spineless.org> 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Baboval Cc: qemu-devel@nongnu.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