From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjA2H-0003zG-S6 for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:49:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjA28-0008B6-2h for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:49:49 -0500 Received: from maverick.spineless.org ([71.174.98.242]:35643 helo=spineless.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjA27-0008Ap-Ti for qemu-devel@nongnu.org; Wed, 20 Nov 2013 10:49:40 -0500 Message-ID: <528CD9FD.2060308@spineless.org> Date: Wed, 20 Nov 2013 10:49:17 -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> In-Reply-To: <1384960445.2005.124.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: Gerd Hoffmann Cc: qemu-devel@nongnu.org On 11/20/2013 10: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. We solve this problem in our UI now. It's not enough to know the offsets. You also need to know all the resolutions - the display window, the guest, and the device coordinate system of the virtual pointing device (we use a PV event ring instead of a USB tablet). If your UI can scale the guest output, that means you need to also store the UI's window geometry in the QemuConsole to get the math right. Incidentally, XenClient will eventually be moving back to relative coordinates from mice. We will handle seamless transitions by having the guest feed the pointer coordinates back down through an emulated hardware cursor channel. The reason for this is that operating systems like Windows 8 implement various types of "pointer friction" that don't work when you send absolute coordinates. We are still working out the latency kinks. > > > 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 > >