From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjIOT-0006Ex-N0 for qemu-devel@nongnu.org; Wed, 20 Nov 2013 19:45:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjIOS-00080k-0Z for qemu-devel@nongnu.org; Wed, 20 Nov 2013 19:45:17 -0500 Received: from mail-la0-x22b.google.com ([2a00:1450:4010:c03::22b]:45304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjIOR-00080Y-Ob for qemu-devel@nongnu.org; Wed, 20 Nov 2013 19:45:15 -0500 Received: by mail-la0-f43.google.com with SMTP id n7so8127183lam.30 for ; Wed, 20 Nov 2013 16:45:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1384960445.2005.124.camel@nilsson.home.kraxel.org> References: <1384848690.16718.139.camel@nilsson.home.kraxel.org> <1384935158.2005.34.camel@nilsson.home.kraxel.org> <528CC80B.7080601@spineless.org> <1384960445.2005.124.camel@nilsson.home.kraxel.org> Date: Thu, 21 Nov 2013 10:45:14 +1000 Message-ID: From: Dave Airlie Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] console muti-head some more design input List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: John Baboval , "qemu-devel@nongnu.org" On Thu, Nov 21, 2013 at 1:14 AM, Gerd Hoffmann wrote: > 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. This is a nice dream, except you'll find the guest won't deal with it very well, and you'll have all kinds of guest scenarios to link up that touchscreen a talks to monitor a etc. Dave.