From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlg2F-0006fb-0y for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:24:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vlg27-0000FA-1q for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:24:10 -0500 Received: from maverick.spineless.org ([71.174.98.242]:36984 helo=spineless.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlg26-0000F4-TE for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:24:02 -0500 Received: from hackintosh.local ([192.168.2.122]) by spineless.org with esmtp (Exim 4.72) (envelope-from ) id 1Vlg26-0003Jd-7s for qemu-devel@nongnu.org; Wed, 27 Nov 2013 09:24:02 -0500 Message-ID: <52960076.2020102@spineless.org> Date: Wed, 27 Nov 2013 09:23:50 -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> <528CC80B.7080601@spineless.org> <1384960445.2005.124.camel@nilsson.home.kraxel.org> <1385109669.3681.32.camel@nilsson.home.kraxel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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/26/2013 11:29 PM, Dave Airlie wrote: > On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann wrote: >> Hi, >> >>>> 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. >> Ok, scratch the idea then. >> >> I don't have personal experience with this, >> no touch capable displays here. > Hmm I think we get to unscratch this idea, > > After looking into this a bit more I think we probably do need > something outside the gpu to handle this. > > The problem is that there are two scenarios for a GPU multi-head, > > a) one resource - two outputs, the second output has an offset to > scanout into the resource > b) two resources - two outputs, both outputs have a 0,0 into their > respective resources. > > So the GPU doesn't have this information in all cases on what the > input device configuration should be, > Neither do we have anyway in the guests to specify this relationship > at the driver level. There is a third, likely option: c) one resource - two outputs, the second output's scanout offset isn't the same as the logical offset from the perspective of the input device There are two possible solutions to this, both of which I have added interfaces for. (I really should hurry up and send out patches....) The individual logical display offsets can be provided by the UI, and pushed into the guest, or the guest driver can push the offsets down. So if the UI provides absolute coordinates normalized to the individual displays, and the offsets are stored in the QemuConsole, then the input layer can do the math as Gerd suggested. It just requires one additional coordinate set transformation. In XenClient, we use both interfaces, so the user can set the display offsets from wherever they care to. The in-guest side is relatively easy to implement in Linux guests that run X. It's more complicated in Windows, since the display driver isn't actually told about the offsets, so there needs to be an additional user-level service running to inform it of changes. > > So I think we probably do need treat multi-head windows as separate > input devices, and/or have > an agent in the guest to do the right thing by configuring multiple > input devices to map to multiple outputs. This is essentially correct, except that only the UI needs to treat it as separate input devices. The rest of the stack should be OK as one input device. > > I suppose spice must do something like this already, maybe they can > tell me more. > > Dave. >